<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/fs/udf/super.c, branch v6.12.80</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.12.80</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.12.80'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2025-08-20T16:30:20+00:00</updated>
<entry>
<title>udf: Verify partition map count</title>
<updated>2025-08-20T16:30:20+00:00</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2025-07-11T17:01:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=699b30248309a8607bdd48bd9f0869a978d10d0c'/>
<id>urn:sha1:699b30248309a8607bdd48bd9f0869a978d10d0c</id>
<content type='text'>
[ Upstream commit 1a11201668e8635602577dcf06f2e96c591d8819 ]

Verify that number of partition maps isn't insanely high which can lead
to large allocation in udf_sb_alloc_partition_maps(). All partition maps
have to fit in the LVD which is in a single block.

Reported-by: syzbot+478f2c1a6f0f447a46bb@syzkaller.appspotmail.com
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>udf: refactor udf_next_aext() to handle error</title>
<updated>2024-10-02T12:10:50+00:00</updated>
<author>
<name>Zhao Mengmeng</name>
<email>zhaomengmeng@kylinos.cn</email>
</author>
<published>2024-10-01T11:54:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b405c1e58b73981da0f8df03b00666b22b9397ae'/>
<id>urn:sha1:b405c1e58b73981da0f8df03b00666b22b9397ae</id>
<content type='text'>
Since udf_current_aext() has error handling, udf_next_aext() should have
error handling too. Besides, when too many indirect extents found in one
inode, return -EFSCORRUPTED; when reading block failed, return -EIO.

Signed-off-by: Zhao Mengmeng &lt;zhaomengmeng@kylinos.cn&gt;
Suggested-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Link: https://patch.msgid.link/20241001115425.266556-3-zhaomzhao@126.com
</content>
</entry>
<entry>
<title>udf: Avoid excessive partition lengths</title>
<updated>2024-06-26T10:54:11+00:00</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2024-06-20T10:52:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ebbe26fd54a9621994bc16b14f2ba8f84c089693'/>
<id>urn:sha1:ebbe26fd54a9621994bc16b14f2ba8f84c089693</id>
<content type='text'>
Avoid mounting filesystems where the partition would overflow the
32-bits used for block number. Also refuse to mount filesystems where
the partition length is so large we cannot safely index bits in a
block bitmap.

Link: https://patch.msgid.link/20240620130403.14731-1-jack@suse.cz
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</content>
</entry>
<entry>
<title>udf: Avoid using corrupted block bitmap buffer</title>
<updated>2024-06-26T10:54:08+00:00</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2024-06-17T15:41:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a90d4471146de21745980cba51ce88e7926bcc4f'/>
<id>urn:sha1:a90d4471146de21745980cba51ce88e7926bcc4f</id>
<content type='text'>
When the filesystem block bitmap is corrupted, we detect the corruption
while loading the bitmap and fail the allocation with error. However the
next allocation from the same bitmap will notice the bitmap buffer is
already loaded and tries to allocate from the bitmap with mixed results
(depending on the exact nature of the bitmap corruption). Fix the
problem by using BH_verified bit to indicate whether the bitmap is valid
or not.

Reported-by: syzbot+5f682cd029581f9edfd1@syzkaller.appspotmail.com
CC: stable@vger.kernel.org
Link: https://patch.msgid.link/20240617154201.29512-2-jack@suse.cz
Fixes: 1e0d4adf17e7 ("udf: Check consistency of Space Bitmap Descriptor")
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</content>
</entry>
<entry>
<title>udf: replace deprecated strncpy/strcpy with strscpy</title>
<updated>2024-04-02T13:23:47+00:00</updated>
<author>
<name>Justin Stitt</name>
<email>justinstitt@google.com</email>
</author>
<published>2024-04-01T20:01:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=94755a00a4e79236d4bfa6dc671a339828fb38ce'/>
<id>urn:sha1:94755a00a4e79236d4bfa6dc671a339828fb38ce</id>
<content type='text'>
strncpy() is deprecated for use on NUL-terminated destination strings
[1] and as such we should prefer more robust and less ambiguous string
interfaces. Also replace an instance of strcpy() which is also
deprecated.

s_volume_ident is a NUL-terminated string which is evident from its
usage in udf_debug:
|	udf_debug("volIdent[] = '%s'\n", UDF_SB(sb)-&gt;s_volume_ident);

s_volume_ident should also be NUL-padded as it is copied out to
userspace:
|	if (copy_to_user((char __user *)arg,
|				UDF_SB(inode-&gt;i_sb)-&gt;s_volume_ident, 32))
|		return -EFAULT;

Considering the above, a suitable replacement is `strscpy_pad` [2] due
to the fact that it guarantees both NUL-termination and NUL-padding on
the destination buffer.

To simplify the code, let's use the new 2-argument version of
strscpy_pad() introduced in Commit e6584c3964f2f ("string: Allow
2-argument strscpy()"). Also zero-allocate @outstr so we can safely use
a non-@ret length argument. This is just in case udf_dstrCS0toChar()
doesn't include the NUL-byte in its return length, we won't truncate
@outstr or write garbage bytes either.

Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2]
Link: https://github.com/KSPP/linux/issues/90
Cc: linux-hardening@vger.kernel.org
Signed-off-by: Justin Stitt &lt;justinstitt@google.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Message-Id: &lt;20240401-strncpy-fs-udf-super-c-v1-1-80cddab7a281@google.com&gt;
</content>
</entry>
<entry>
<title>udf: Remove second semicolon</title>
<updated>2024-03-25T19:12:10+00:00</updated>
<author>
<name>Colin Ian King</name>
<email>colin.i.king@gmail.com</email>
</author>
<published>2024-03-15T09:19:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8777446a3f2dd6dab0859e4aedef6e0240955fdb'/>
<id>urn:sha1:8777446a3f2dd6dab0859e4aedef6e0240955fdb</id>
<content type='text'>
There is a statement with two semicolons. Remove the second one, it
is redundant.

Signed-off-by: Colin Ian King &lt;colin.i.king@gmail.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Message-Id: &lt;20240315091949.2430585-1-colin.i.king@gmail.com&gt;
</content>
</entry>
<entry>
<title>udf: remove SLAB_MEM_SPREAD flag usage</title>
<updated>2024-03-05T14:16:15+00:00</updated>
<author>
<name>Chengming Zhou</name>
<email>zhouchengming@bytedance.com</email>
</author>
<published>2024-02-24T13:52:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a78e41a67bef099ca3ffee78c7eda8d43b693f27'/>
<id>urn:sha1:a78e41a67bef099ca3ffee78c7eda8d43b693f27</id>
<content type='text'>
The SLAB_MEM_SPREAD flag is already a no-op after removal of SLAB
allocator and in [1] it was fully deprecated. Remove its usage so we can
delete it from slab. No functional change.

Signed-off-by: Chengming Zhou &lt;zhouchengming@bytedance.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Link: https://lore.kernel.org/all/20240223-slab-cleanup-flags-v2-1-02f1753e8303@suse.cz/
Message-Id: &lt;20240224135229.830356-1-chengming.zhou@linux.dev&gt;
</content>
</entry>
<entry>
<title>udf: convert to new mount API</title>
<updated>2024-02-21T12:55:30+00:00</updated>
<author>
<name>Eric Sandeen</name>
<email>sandeen@redhat.com</email>
</author>
<published>2024-02-20T21:44:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c4e89cc674ac36743f9c28db8c1b565039e9e08b'/>
<id>urn:sha1:c4e89cc674ac36743f9c28db8c1b565039e9e08b</id>
<content type='text'>
Convert the UDF filesystem to the new mount API.

UDF is slightly unique in that it always preserves prior mount
options across a remount, so that's handled by udf_init_options().

Signed-off-by: Eric Sandeen &lt;sandeen@redhat.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Message-Id: &lt;fcb3faf3-e2df-450c-b37a-11000c274585@redhat.com&gt;
</content>
</entry>
<entry>
<title>udf: convert novrs to an option flag</title>
<updated>2024-02-21T12:55:30+00:00</updated>
<author>
<name>Eric Sandeen</name>
<email>sandeen@redhat.com</email>
</author>
<published>2024-02-20T21:43:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7a8e72c16e734f2ccdfe8d86bcd2e176aa5e978a'/>
<id>urn:sha1:7a8e72c16e734f2ccdfe8d86bcd2e176aa5e978a</id>
<content type='text'>
There's no reason to treat novers specially, convert it
to a flag in uopt-&gt;flags like other flag options.

Signed-off-by: Eric Sandeen &lt;sandeen@redhat.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Message-Id: &lt;b5d53492-b99a-4b3c-82c0-581df9a9e384@redhat.com&gt;
</content>
</entry>
<entry>
<title>udf: Avoid invalid LVID used on mount</title>
<updated>2024-02-05T15:51:59+00:00</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2024-02-05T15:24:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c8f1140cb82dc843e72697dc6f8c7ee1acce5d28'/>
<id>urn:sha1:c8f1140cb82dc843e72697dc6f8c7ee1acce5d28</id>
<content type='text'>
udf_load_logicalvolint() loads logical volume integrity descriptors.
Since there can be multiple blocks with LVIDs, we verify the contents of
only the last (prevailing) LVID found. However if we fail to load the
last LVID (either due to IO error or because it's checksum fails to
match), we never perform the verification of validity of the LVID we are
going to use. If such LVID contains invalid data, we can hit
out-of-bounds access or similar issues. Fix the problem by verifying
each LVID we are potentially going to accept.

Reported-by: Robert Morris &lt;rtm@csail.mit.edu&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</content>
</entry>
</feed>
