From: Junzhe Yu <junzheyu1@gmail.com>
To: Theodore Ts'o <tytso@mit.edu>, Jan Kara <jack@suse.com>,
Andreas Dilger <adilger.kernel@dilger.ca>
Cc: linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [BUG] ext4/jbd2: KASAN UAF in jbd2_fc_release_bufs after loop shrink + fast commit fsync
Date: Tue, 4 Aug 2026 16:24:42 +0800 [thread overview]
Message-ID: <7e4b109d-64c3-444f-a5dc-93c2ca4576cc@gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2219 bytes --]
Hello,
I am reporting a use-after-free in jbd2_fc_release_bufs() when ext4 fast
commit fails after the loop backing store is shrunk while journal I/O is
still in flight.
Summary
=======
On ext4 with fast commits mounted on loop0:
1. Write + fsync (fast commit path).
2. Shrink loop capacity (campaign case: 32768 -> 16726 sectors).
3. fsync again.
Journal block writes fail; ext4_fc_commit falls back and ext4_fc_cleanup
calls jbd2_fc_release_bufs(), which put_bh()s buffer heads whose pages
were already torn down by the loop shrink / I/O error path. KASAN reports
use-after-free at fs/jbd2/journal.c:942 (jbd2_fc_release_bufs).
This is distinct from CVE-2022-50328 (jbd2_fc_wait_bufs UAF on the wait
path, already on 6.6). Our crash is on the release/cleanup path after
failed FC commit.
Affected
========
- Confirmed on Linux 6.6.144 KASAN (QEMU guest)
- Files: fs/jbd2/journal.c, fs/ext4/fast_commit.c
- Needs CONFIG_EXT4_FS, fast_commit feature, loop device
Crash excerpt (campaign)
========================
BUG: KASAN: use-after-free in jbd2_fc_release_bufs+0x95/0x170
ext4_fc_cleanup
__jbd2_fc_end_commit
ext4_fc_commit
ext4_sync_file
__x64_sys_fsync
(Preceding ext4_end_bio I/O errors and loop capacity change.)
Reproducer
==========
Attached: ext4-fc-jbd2-fc-release-bufs-uaf-repro.tar.gz
VM-only (KASAN runs inside QEMU, not on the host):
tar xzf ext4-fc-jbd2-fc-release-bufs-uaf-repro.tar.gz
cd attachments
docker build -t ext4-fc-jbd2-fc-release-bufs-uaf -f Dockerfile .
mkdir -p artifacts
docker run --rm --privileged --device=/dev/kvm --network=host \
-v "$PWD/artifacts:/artifacts" -e OUTPUT_DIR=/artifacts \
-e RUN_TIMEOUT_SEC=900 -e REPRO_TRIES=5 \
ext4-fc-jbd2-fc-release-bufs-uaf
First run builds Linux 6.6.144 KASAN + guest image (cached under
artifacts/).
Expect >=1 hit in REPRO_TRIES attempts when successful.
Impact
======
Local DoS / memory corruption on error paths when loop (or similar) backing
disappears during fast commit. Practical exploitation beyond DoS not
evaluated.
Happy to test patches. Let me know if you need a C reproducer or
syzkaller prog.
Thanks,
Yu Junzhe
FuzzAnything <fuzzanything@gmail.com>
[-- Attachment #2: ext4-fc-jbd2-fc-release-bufs-uaf-repro.tar.gz --]
[-- Type: application/x-gzip, Size: 11811 bytes --]
reply other threads:[~2026-08-04 8:24 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=7e4b109d-64c3-444f-a5dc-93c2ca4576cc@gmail.com \
--to=junzheyu1@gmail.com \
--cc=adilger.kernel@dilger.ca \
--cc=jack@suse.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
/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