[PATCH] xfs: do not release buf log item prematurely in xfs_buf_item_done

[PATCH] xfs: do not release buf log item prematurely in xfs_buf_item_done

[Igor Putko]

When a buffer with an active log item is written synchronously to disk
via xfs_bwrite() (for example, in xfs_sync_sb_buf() during
FS_IOC_SETFSLABEL), I/O completion invokes xfs_buf_item_done().

Currently, xfs_buf_item_done() unconditionally calls
xfs_buf_item_relse(), which frees the xfs_buf_log_item even if it still
has active references (e.g. bli_refcount > 0 while the item is pinned in
a CIL context and queued on cilpcp->log_items). When xlog_cil_push_work()
subsequently runs on another CPU, xlog_cil_push_pcp_aggregate() accesses
the freed log item while splicing cilpcp->log_items, triggering a
slab-use-after-free:

  BUG: KASAN: slab-use-after-free in xlog_cil_push_pcp_aggregate
  Write of size 8 at addr ffff888036db9c40 by task kworker/u8:7/300
  Call Trace:
   <TASK>
   __list_splice include/linux/list.h:577 [inline]
   list_splice_init include/linux/list.h:619 [inline]
   xlog_cil_push_pcp_aggregate fs/xfs/xfs_log_cil.c:137 [inline]
   xlog_cil_push_work+0x986/0x2a90 fs/xfs/xfs_log_cil.c:1417

Fix this by checking if the buf log item still has active references
in xfs_buf_item_done(). If bli_refcount is elevated, the item is still
owned by an ongoing transaction or the CIL and must not be torn down.

Fixes: d2fe5c4c8d25 ("xfs: rearrange code in xfs_buf_item.c")
Reported-by: syzbot+c32fff62cf4913d345d0c@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=c32ff62cf4913d345d0c
Signed-off-by: Igor Putko <igorpetindev@gmail.com>
---
 fs/xfs/xfs_buf_item.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/fs/xfs/xfs_buf_item.c b/fs/xfs/xfs_buf_item.c
index 1a4ef34af8d5..6b32061bac53 100644
--- a/fs/xfs/xfs_buf_item.c
+++ b/fs/xfs/xfs_buf_item.c
@@ -1067,6 +1067,14 @@ xfs_buf_item_done(
 	struct xfs_buf		*bp)
 {
 	struct xfs_buf_log_item	*bip = bp->b_log_item;
+	struct xfs_log_item	*lip = &bip->bli_item;
+
+	/*
+	 * If the log item still has active references (e.g. pinned by the CIL
+	 * or held by an ongoing transaction), we cannot tear it down here.
+	 */
+	if (atomic_read(&bip->bli_refcount) > 0)
+		return;
 
 	/*
 	 * If we are forcibly shutting down, this may well be off the AIL
@@ -1080,8 +1088,8 @@ xfs_buf_item_done(
 	 * Note that log recovery writes might have buffer items that are not on
 	 * the AIL even when the file system is not shut down.
 	 */
-	xfs_trans_ail_delete(&bip->bli_item,
-			     xlog_in_recovery(bip->bli_item.li_log) ?
+	xfs_trans_ail_delete(lip,
+			     xlog_in_recovery(lip->li_log) ?
 			     0 : SHUTDOWN_CORRUPT_INCORE);
 	xfs_buf_item_relse(bip);
 }
-- 
2.47.3

Re: [PATCH] xfs: do not release buf log item prematurely in xfs_buf_item_done

[Dave Chinner]

On Sun, Oct 18, 2026 at 08:09:13PM +0300, Igor Putko wrote:
> When a buffer with an active log item is written synchronously to disk
> via xfs_bwrite() (for example, in xfs_sync_sb_buf() during
> FS_IOC_SETFSLABEL), I/O completion invokes xfs_buf_item_done().
> 
> Currently, xfs_buf_item_done() unconditionally calls
> xfs_buf_item_relse(), which frees the xfs_buf_log_item even if it still
> has active references (e.g. bli_refcount > 0 while the item is pinned in
> a CIL context and queued on cilpcp->log_items). When xlog_cil_push_work()
> subsequently runs on another CPU, xlog_cil_push_pcp_aggregate() accesses
> the freed log item while splicing cilpcp->log_items, triggering a
> slab-use-after-free:
> 
>   BUG: KASAN: slab-use-after-free in xlog_cil_push_pcp_aggregate
>   Write of size 8 at addr ffff888036db9c40 by task kworker/u8:7/300
>   Call Trace:
>    <TASK>
>    __list_splice include/linux/list.h:577 [inline]
>    list_splice_init include/linux/list.h:619 [inline]
>    xlog_cil_push_pcp_aggregate fs/xfs/xfs_log_cil.c:137 [inline]
>    xlog_cil_push_work+0x986/0x2a90 fs/xfs/xfs_log_cil.c:1417
> 
> Fix this by checking if the buf log item still has active references
> in xfs_buf_item_done(). If bli_refcount is elevated, the item is still
> owned by an ongoing transaction or the CIL and must not be torn down.
> 
> Fixes: d2fe5c4c8d25 ("xfs: rearrange code in xfs_buf_item.c")
> Reported-by: syzbot+c32fff62cf4913d345d0c@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=c32ff62cf4913d345d0c
> Signed-off-by: Igor Putko <igorpetindev@gmail.com>
> ---
>  fs/xfs/xfs_buf_item.c | 12 ++++++++++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/xfs/xfs_buf_item.c b/fs/xfs/xfs_buf_item.c
> index 1a4ef34af8d5..6b32061bac53 100644
> --- a/fs/xfs/xfs_buf_item.c
> +++ b/fs/xfs/xfs_buf_item.c
> @@ -1067,6 +1067,14 @@ xfs_buf_item_done(
>  	struct xfs_buf		*bp)
>  {
>  	struct xfs_buf_log_item	*bip = bp->b_log_item;
> +	struct xfs_log_item	*lip = &bip->bli_item;
> +
> +	/*
> +	 * If the log item still has active references (e.g. pinned by the CIL
> +	 * or held by an ongoing transaction), we cannot tear it down here.
> +	 */
> +	if (atomic_read(&bip->bli_refcount) > 0)
> +		return;

As I have said several times before: this does not fix the UAF.
Please review the mailing list for similar issues and discussion
before posting fixes.

I've already outlined the root cause and overall fix direction here:

https://lore.kernel.org/all/aqI6v-_dc2DDSbgB@dread/

Jeffin (cc'd) had started working on this, but I don't know how far
he has got with it.

-Dave.
-- 
Dave Chinner
dgc@kernel.org