<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/fs/udf/super.c, branch v6.6.141</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.141</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.141'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-05-17T15:13:49+00:00</updated>
<entry>
<title>udf: fix partition descriptor append bookkeeping</title>
<updated>2026-05-17T15:13:49+00:00</updated>
<author>
<name>Seohyeon Maeng</name>
<email>bioloidgp@gmail.com</email>
</author>
<published>2026-05-08T20:04:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=058b451b1039f056d1362c4fec2229e522366ab0'/>
<id>urn:sha1:058b451b1039f056d1362c4fec2229e522366ab0</id>
<content type='text'>
[ Upstream commit 08841b06fa64d8edbd1a21ca6e613420c90cc4b8 ]

Mounting a crafted UDF image with repeated partition descriptors can
trigger a heap out-of-bounds write in part_descs_loc[].

handle_partition_descriptor() deduplicates entries by partition number,
but appended slots never record partnum. As a result duplicate
Partition Descriptors are appended repeatedly and num_part_descs keeps
growing.

Once the table is full, the growth path still sizes the allocation from
partnum even though inserts are indexed by num_part_descs. If partnum is
already aligned to PART_DESC_ALLOC_STEP, ALIGN(partnum, step) can keep
the old capacity and the next append writes past the end of the table.

Store partnum in the appended slot and size growth from the next append
count so deduplication and capacity tracking follow the same model.

Fixes: ee4af50ca94f ("udf: Fix mounting of Win7 created UDF filesystems")
Cc: stable@vger.kernel.org
Signed-off-by: Seohyeon Maeng &lt;bioloidgp@gmail.com&gt;
Link: https://patch.msgid.link/20260310081652.21220-1-bioloidgp@gmail.com
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
[ replaced kzalloc_objs() helper with equivalent kcalloc() ]
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>udf: Verify partition map count</title>
<updated>2025-08-28T14:28:15+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=5a1e1ab8379639315535d5d77d70bc9af114c2f8'/>
<id>urn:sha1:5a1e1ab8379639315535d5d77d70bc9af114c2f8</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-11-01T00:58:27+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=5fc8da4d326d88c12924996b2bec85a194fe27f9'/>
<id>urn:sha1:5fc8da4d326d88c12924996b2bec85a194fe27f9</id>
<content type='text'>
[ Upstream commit b405c1e58b73981da0f8df03b00666b22b9397ae ]

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
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>udf: Avoid excessive partition lengths</title>
<updated>2024-09-12T09:11:30+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=a56330761950cb83de1dfb348479f20c56c95f90'/>
<id>urn:sha1:a56330761950cb83de1dfb348479f20c56c95f90</id>
<content type='text'>
[ Upstream commit ebbe26fd54a9621994bc16b14f2ba8f84c089693 ]

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;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>udf: Avoid using corrupted block bitmap buffer</title>
<updated>2024-08-03T06:54:17+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=57053b3bcf3403b80db6f65aba284d7dfe7326af'/>
<id>urn:sha1:57053b3bcf3403b80db6f65aba284d7dfe7326af</id>
<content type='text'>
commit a90d4471146de21745980cba51ce88e7926bcc4f upstream.

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;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>fs: udf: Replace GPL 2.0 boilerplate license notice with SPDX identifier</title>
<updated>2023-05-30T13:39:13+00:00</updated>
<author>
<name>Bagas Sanjaya</name>
<email>bagasdotme@gmail.com</email>
</author>
<published>2023-05-22T00:54:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5ce345541ee43333bfbd99a2ea56b1a0a167c457'/>
<id>urn:sha1:5ce345541ee43333bfbd99a2ea56b1a0a167c457</id>
<content type='text'>
The notice refers to full GPL 2.0 text on now defunct MIT FTP site [1].
Replace it with appropriate SPDX license identifier.

Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Pali Rohár &lt;pali@kernel.org&gt;
Link: https://web.archive.org/web/20020809115410/ftp://prep.ai.mit.edu/pub/gnu/GPL [1]
Signed-off-by: Bagas Sanjaya &lt;bagasdotme@gmail.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Message-Id: &lt;20230522005434.22133-2-bagasdotme@gmail.com&gt;
</content>
</entry>
<entry>
<title>udf: Limit file size to 4TB</title>
<updated>2023-01-26T15:46:37+00:00</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2023-01-25T16:56:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c2efd13a2ed4f29bf9ef14ac2fbb7474084655f8'/>
<id>urn:sha1:c2efd13a2ed4f29bf9ef14ac2fbb7474084655f8</id>
<content type='text'>
UDF disk format supports in principle file sizes up to 1&lt;&lt;64-1. However
the file space (including holes) is described by a linked list of
extents, each of which can have at most 1GB. Thus the creation and
handling of extents gets unusably slow beyond certain point. Limit the
file size to 4TB to avoid locking up the kernel too easily.

Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</content>
</entry>
<entry>
<title>udf: Use udf_bread() in udf_load_vat()</title>
<updated>2023-01-26T15:46:33+00:00</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2023-01-18T13:08:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=08931b78932d56185753af77b93b8dcaace31e04'/>
<id>urn:sha1:08931b78932d56185753af77b93b8dcaace31e04</id>
<content type='text'>
Use udf_bread() instead of mapping and loadign buffer head manually in
udf_load_vat().

Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</content>
</entry>
<entry>
<title>udf: Drop VARCONV support</title>
<updated>2023-01-26T15:46:32+00:00</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2023-01-18T12:27:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=101ee137d32adc5b53f5c2a61fbda8f70f994845'/>
<id>urn:sha1:101ee137d32adc5b53f5c2a61fbda8f70f994845</id>
<content type='text'>
UDF was supporting a strange mode where the media was containing 7
blocks of unknown data for every 32 blocks of the filesystem. I have yet
to see the media that would need such conversion (maybe it comes from
packet writing times) and the conversions have been inconsistent in the
code. In particular any write will write to a wrong block and corrupt
the media. This is an indication and no user actually needs this so
let's just drop the support instead of trying to fix it.

Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</content>
</entry>
<entry>
<title>udf: Unify types in anchor block detection</title>
<updated>2023-01-26T15:46:32+00:00</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2023-01-18T12:55:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bd904f3c74969442b0ac42f81c0d02da54cd47eb'/>
<id>urn:sha1:bd904f3c74969442b0ac42f81c0d02da54cd47eb</id>
<content type='text'>
When detecting last recorded block and from it derived anchor block
position, we were mixing unsigned long, u32, and sector_t types. Since
udf supports only 32-bit block numbers this is harmless but sometimes
makes things awkward. Convert everything to udf_pblk_t and also handle
the situation when block device size would not fit into udf_pblk_t.

Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</content>
</entry>
</feed>
