From: Matthias Goergens <matthias.goergens@gmail.com>
To: Jan Kara <jack@suse.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
syzbot+799a0e744ac47f928024@syzkaller.appspotmail.com,
syzbot+43fc5ba6dcb33e3261ca@syzkaller.appspotmail.com,
syzkaller-bugs@googlegroups.com
Subject: [PATCH 0/3] udf: fix double allocation from the unallocated space table
Date: Fri, 2 Oct 2026 00:34:45 +0800 [thread overview]
Message-ID: <20261001163448.753190-1-matthias.goergens@gmail.com> (raw)
Hi Honza,
A filesystem made with "mkudffs --space=unalloctable" hands out blocks
that are still in use, for two separate reasons.
Patch 1: udf_table_new_block() keeps the extent type in the length
word, so an exhausted type-1 table extent (the type mkudffs writes)
survives as a zero-length extent pointing at an in-use block, and the
next allocation from it underflows into about a gigabyte of "free"
space. Filling a fresh 1 MiB image with empty files is enough to
overwrite the reserve VDS and the backup anchor. This is the double
allocation behind the two syzbot reports linked in the patch.
Patch 2 checks the table once at mount and refuses read-write access
if it is damaged, for example by the bug in patch 1.
Patch 3: when a file's extent list ends in an empty allocation extent,
udf_next_aext() returns 0 with its outputs describing the continuation
descriptor, and udf_discard_prealloc() frees that block a second time
instead of the preallocated blocks. On a table the block is then
handed out twice, and the fsx runs of generic/091 and generic/263 read
back bad data, with or without patches 1 and 2. On a bitmap the
preallocated blocks leak.
With the series, fstests -g quick (2 GiB images; KASAN, UBSAN and
lockdep enabled) passes generic/091 and generic/263 on a table. The
remaining failures (generic/131, 360, 563, 634 and 777, and a hang in
generic/346) are the same without the series and on a bitmap, where
the series changes no result. The reproducers are below the --- of
patches 1 and 3.
The series is based on your for_next and applies to v7.3-rc5 as well.
Thanks,
Matthias
---
For stable: patch 3 builds on the int return of udf_next_aext()
(b405c1e58b73, v6.12, also backported to 6.6.y) and applies as is to
6.6.y and later; older stable trees need a trivial adaptation.
Matthias Goergens (3):
udf: don't let the extent type hide an exhausted free-space table
extent
udf: check the unallocated space table when it is loaded
udf: leave udf_next_aext() outputs alone at the end of the extent list
fs/udf/balloc.c | 9 ++++--
fs/udf/inode.c | 21 ++++++++++---
fs/udf/super.c | 80 ++++++++++++++++++++++++++++++++++++++++++++++++-
3 files changed, 102 insertions(+), 8 deletions(-)
base-commit: ba5855e74bcd761123e39f4708834a0015a74a8b
--
2.55.0
reply other threads:[~2026-10-01 16:34 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261001163448.753190-1-matthias.goergens@gmail.com \
--to=matthias.goergens@gmail.com \
--cc=jack@suse.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=syzbot+43fc5ba6dcb33e3261ca@syzkaller.appspotmail.com \
--cc=syzbot+799a0e744ac47f928024@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox