linux-kernel - [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 for Android: free password hash cracker in your pocket

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

Message-ID: <AA6A7gB4JrG-pMrNGmqTzap7.1.1763463974419.Hmail.2200013188@stu.pku.edu.cn>
Date: Tue, 18 Nov 2025 19:06:14 +0800 (GMT+08:00)
From: 李天宇 <lty218@....pku.edu.cn>
To: linux-kernel <linux-kernel@...r.kernel.org>
Cc: linux-xfs <linux-xfs@...r.kernel.org>, cem <cem@...nel.org>
Subject: [BUG] xfs: NULL pointer dereference in xfs_buf.h: xfs_buf_daddr()

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(x86_64, QEMU). Since no reproducing code is left, we have only the report to analyze. I have checked the stack frame and relevant code. After comparing it with the mainline code, the buggy code at xfs_buf.h:333 and at xfs_btree.c:1902 (lines according to rc5 on mainline) remains unchanged. Therefore, I suspect that this bug could also occur in the latest kernel.

To determine why b_maps is NULL, I reviewed all statements involving b_maps and found only 2 assignments to b_maps: at xfs_buf.c:296/298. Thus, I believe the issue may be due to one of the following reasons:
1. At xfs_buf.c: xfs_buf_alloc(), no proper value is set for b_maps, which seems unlikely.
2. Race conditions may have occurred, causing the b_maps field to be accessed before properly initialized.

A simple fix might be to ensure bp-&gt;b_maps is not NULL in xfs_buf_daddr(), but this does not address the root cause of the problem. It may be better to investigate whether there could be a situation where the usage occurs before initialization.
I hope this analysis helps provide more clarity.

Test environment, configuration, and kernel logs are listed below:

	Kernel 6.2: https://www.kernel.org/pub/linux/kernel/v6.x/linux-6.2.tar.gz
	Configuration: https://github.com/Wxm-233/KConfigFuzz_Repros/raw/refs/heads/master/62-config
	Kernel log: https://github.com/j1akai/KConfigFuzz_bug/raw/d50808fe31d5fc307cc0eb57f0cb29bc4fa537d2/x86/crashes-part1/0008_0b8eea7d39710d97dcf1bc48d36ac038269a5e7e/x86_62_66_syzkaller_0904-2_6.2_xian+yin/report0