From: Zheng Shuhao <viennaoffh@gmail.com>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Carlos Maiolino <cem@kernel.org>,
linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org,
syzbot+e7f24354da9f7915bc54@syzkaller.appspotmail.com
Subject: Re: [PATCH] xfs: fix slab-use-after-free in xrep_newbt_free()
Date: Sat, 17 Oct 2026 09:56:00 +0800 [thread overview]
Message-ID: <6ad2d5b5.969afe5a.ee04c.f286@mx.google.com> (raw)
In-Reply-To: <20261016152359.GA107986@frogsfrogsfrogs>
Hi Darrick,
Thanks. Re: "What if some other thread initiates the shutdown?"
That is what I tested. The paused autoreap dfps are freed by the failed
xrep_defer_finish() in the repair thread, no matter which thread sets the
shutdown. xfs_defer_finish_noroll()'s out_shutdown path forces the
shutdown before xfs_defer_cancel_list(), which frees every
xfs_defer_pending on the scrub transaction, including the paused autoreap
EFIs. resv->autoreap.dfp is dangling by the time junkit runs.
If the shutdown is already set before repair starts, the dfps may still be
alive, but unpausing them is a no-op: deferred work cannot progress on a
dead log, and scrub teardown cancels the transaction and frees the dfps.
Any EFI that reached the log is replayed at mount, which is exactly the
intended autoreap behavior for a repair that never committed its new
btree.
The guard cannot miss the dangling case, because the cancel that frees the
dfps happens after the shutdown is forced.
Testing: helper threads issue XFS_IOC_GOINGDOWN (LOGFLUSH and NOLOGFLUSH)
after the xfs_defer_item_pause trace event -- 1 to 8 threads, 0-100 ms
delays -- while the main thread force-rebuilds a bmap btree. Unpatched:
KASAN UAF every time in xrep_newbt_free() -> xfs_defer_item_unpause().
Patched: no splats, scrub returns -EIO; after remount the log replays,
free block count is unchanged, data reads back intact, xfs_repair -n is
clean. Healthy forced rebuilds still do the normal pause/unpause.
Thanks,
Zheng Shuhao
prev parent reply other threads:[~2026-10-17 1:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-16 8:55 [PATCH] xfs: fix slab-use-after-free in xrep_newbt_free() vienna-0FFH
2026-10-16 13:17 ` Carlos Maiolino
2026-10-16 14:16 ` Zheng Shuhao
2026-10-17 4:54 ` Carlos Maiolino
2026-10-16 15:23 ` Darrick J. Wong
2026-10-17 1:56 ` Zheng Shuhao [this message]
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=6ad2d5b5.969afe5a.ee04c.f286@mx.google.com \
--to=viennaoffh@gmail.com \
--cc=cem@kernel.org \
--cc=djwong@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=syzbot+e7f24354da9f7915bc54@syzkaller.appspotmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.