linux-kernel - Re: [BUG] xfs: NULL pointer dereference in xfs_buf.h: xfs_buf

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aR1mhcGvS7yxCG-R@dread.disaster.area>
Date: Wed, 19 Nov 2025 17:41:09 +1100
From: Dave Chinner <david@...morbit.com>
To: Christoph Hellwig <hch@...radead.org>
Cc: 李天宇 <lty218@....pku.edu.cn>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-xfs <linux-xfs@...r.kernel.org>, cem <cem@...nel.org>
Subject: Re: [BUG] xfs: NULL pointer dereference in xfs_buf.h: xfs_buf_daddr()

On Tue, Nov 18, 2025 at 10:06:49PM -0800, Christoph Hellwig wrote:
> On Tue, Nov 18, 2025 at 07:06:14PM +0800, 李天宇 wrote:
> > The kernel reports a kernel NULL pointer dereference when the sys_mount is called. This is triggered by the statement b_maps[0], where b_maps is NULL.
> > 
> > This bug was discovered through a fuzzing framework on Linux v6.2
> 
> Linux 6.2 is ancient (Feb 2023), and the buffer cache code has seen a
> major rewrite since:
> 
> ch@...ck:~/work/linux$ git diff v6.2..HEAD fs/xfs/xfs_buf.[ch] | diffstat
>  xfs_buf.c | 1651 +++++++++++++++++++++++++++++++++++++++-----------------------------------------------------
>   xfs_buf.h |   96 +++--
> 2 files changed, 768 insertions(+), 979 deletions(-)
> 
> hch@...ck:~/work/linux$ wc -l fs/xfs/xfs_buf.[ch]
>  2132 fs/xfs/xfs_buf.c
>   391 fs/xfs/xfs_buf.h
>  2523 total
> 
> so I'm not sure how relevant this report is, especially without a good
> report.

It's not even a buffer cache bug. Something trashed a buffer
pointer in a btree cursor and xfs_buf_daddr() is the first
dereference to trip over it. It looks like random memory
corruption to me, so unless it is reproduced on a TOT kernel there's
no point spending any time looking at it...

-Dave.
-- 
Dave Chinner
david@...morbit.com