From nobody Thu Apr 9 03:28:36 2026 Received: from m16.mail.163.com (m16.mail.163.com [220.197.31.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9D2313B634D; Wed, 11 Mar 2026 08:20:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.197.31.2 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773217204; cv=none; b=Ch40+keRqOq04HNavLoToZ4Q/Uv/MZIYb0TKL9NuJaa2XEYC530vTYniK5EHfG7yQ333WkvYuP+gOs7Xm4DYznpZtc8+oC38LGJeNsiVqS2o85BN4kJvnP2vCm6ZIeqXpXUDeeQp9ay4SfPweWCAzF5ZgUD3G8qiOSdIomKixKY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773217204; c=relaxed/simple; bh=9b/HCfYrblKzqYNxAiFi6ZLIyQg+b+v4lCFo4ej0fAQ=; h=Date:From:To:Subject:Content-Type:MIME-Version:Message-ID; b=BaQMhirrj7wXvjvllGZE17Zp2mmm07Ec0aUDBh6VMkuBH8Cq2GSI3+ZZMkX/KuOdngz18cA9hLqspwdVJdHV64fBmcUACb1lNFw9rDm9D1yk95c9ElNJDr9nb5SJMH2fGQsFJWvVHf5H+PPHkbfbUYf/gPIPvbhrYdHugXM+H+o= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com; spf=pass smtp.mailfrom=163.com; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b=ZLfaqzoZ; arc=none smtp.client-ip=220.197.31.2 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=163.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b="ZLfaqzoZ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Date:From:To:Subject:Content-Type:MIME-Version: Message-ID; bh=9b/HCfYrblKzqYNxAiFi6ZLIyQg+b+v4lCFo4ej0fAQ=; b=Z LfaqzoZTixNAQzPLu+37WCtfNdgSjhAwkR0knb1e0STa5TBYNqC0CKZbkUdvLGg5 Th133zpGSjcoXI3/F3yKgtfR95IKtuscxexUEXRFOH6lTmT89Qgi3RVsqoJGP4W1 mGnnLkNpwKpAntQvmGA7JzfLOeLoyAZH8GDwB2nlvY= Received: from luckd0g$163.com ( [183.205.138.18] ) by ajax-webmail-wmsvr-40-127 (Coremail) ; Wed, 11 Mar 2026 16:19:41 +0800 (CST) Date: Wed, 11 Mar 2026 16:19:41 +0800 (CST) From: "Jianzhou Zhao" To: linux-kernel@vger.kernel.org, jack@suse.cz, brauner@kernel.org, viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org Subject: BUG: unable to handle kernel NULL pointer dereference in __bread_gfp X-Priority: 3 X-Mailer: Coremail Webmail Server Version 2023.4-cmXT build 20251222(83accb85) Copyright (c) 2002-2026 www.mailtech.cn 163com X-NTES-SC: AL_Qu2cAf6auEkj5ySQZ+kfmU4Rhug7UMO3uf8n24JfPJ9wjA/p2yseUUF9NmPf88CwFTuXvxiGfTNO1/ZAU5BifrwxXpTsu88leTd2mmjykc218Q== Content-Transfer-Encoding: quoted-printable Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-ID: <3f2c9284.71e4.19cdbfaef3d.Coremail.luckd0g@163.com> X-Coremail-Locale: zh_CN X-CM-TRANSID: fygvCgDX_4udJbFpeMp2AA--.39156W X-CM-SenderInfo: poxfyvkqj6il2tof0z/xtbC9h03wWmxJZ1JTgAA36 X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== Content-Type: text/plain; charset="utf-8" Subject: [BUG] isofs: kernel NULL pointer dereference in __bread_gfp Dear Maintainers, We are writing to report a NULL pointer dereference vulnerability within th= e JFS/ISOFS mounting architecture. This bug was found by our custom fuzzing= tool, RacePilot. The bug occurs because `isofs_fill_super()` initiates dis= k reads via `sb_bread()` immediately relying on the superblock's `s_bdev` b= lock device map being valid, which triggers an immediate NULL pointer deref= erence inside the `__bread_gfp()` buffer logic if a corrupted/malformed mou= nt request bypasses or fails basic block device bindings. We observed this = bug on the Linux kernel version 6.18.0-08691-g2061f18ad76e-dirty. Call Trace & Context =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 33da6067 P4D 33da6067 PUD 0=20 Oops: Oops: 0002 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 12411 Comm: syz.8.1172 Not tainted 6.18.0-08691-g2061f18= ad76e-dirty #50 PREEMPT(voluntary)=20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/= 2014 Call Trace: sb_bread include/linux/buffer_head.h:346 [inline] isofs_fill_super+0x2ff/0x1900 fs/isofs/inode.c:632 get_tree_bdev_flags+0x256/0x370 fs/super.c:1699 get_tree_bdev+0x1f/0x30 fs/super.c:1722 isofs_get_tree+0x1c/0x30 fs/isofs/inode.c:1538 vfs_get_tree+0x51/0x1a0 fs/super.c:1759 fc_mount+0x1a/0x130 fs/namespace.c:1199 do_new_mount_fc fs/namespace.c:3636 [inline] do_new_mount fs/namespace.c:3712 [inline] path_mount+0x105c/0x1830 fs/namespace.c:4022 do_mount fs/namespace.c:4035 [inline] __do_sys_mount fs/namespace.c:4224 [inline] __se_sys_mount fs/namespace.c:4201 [inline] __x64_sys_mount+0x1d7/0x210 fs/namespace.c:4201 ... =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Execution Flow & Code Context During an `isofs` filesystem mount sequence, the `isofs_fill_super` initial= ization relies heavily on establishing hardware block parameters from the p= rimary superblock wrapper `s->s_bdev`. The driver attempts to parse Volume = Descriptors iteratively across standard offsets: ```c // fs/isofs/inode.c static int isofs_fill_super(struct super_block *s, struct fs_context *fc) { ... for (iso_blknum =3D vol_desc_start+16; iso_blknum < vol_desc_start+100; iso_blknum++) { struct hs_volume_descriptor *hdp; struct iso_volume_descriptor *vdp; block =3D iso_blknum << (ISOFS_BLOCK_BITS - s->s_blocksize_bits); if (!(bh =3D sb_bread(s, block))) // <-- Fatal call triggering fault goto out_no_read; ... ``` The underlying `sb_bread` helper operates blindly on `s->s_bdev` mapping it= directly into `__bread_gfp`: ```c // include/linux/buffer_head.h static inline struct buffer_head * sb_bread(struct super_block *sb, sector_t block) { return __bread_gfp(sb->s_bdev, block, sb->s_blocksize, __GFP_MOVABLE); } ``` Root Cause Analysis A NULL pointer dereference takes place within the deepest buffer traversal = locks. When fuzzy mounts present a dummy context, network stream, or loopba= ck context absent of a strict block device assignment, `get_tree_bdev_flags= ` may pass down a partially mapped `super_block` containing `s->s_bdev =3D= =3D NULL`. The `isofs_fill_super()` code makes no defensive verification of= `s->s_bdev` before executing `bdev_logical_block_size(s->s_bdev)` and `sb_= bread(s, block)`, which ultimately cascades down to `__bread_gfp` attemptin= g atomic flag acquisitions unconditionally against a zero-target address. Unfortunately, we were unable to generate a reproducer for this bug. Potential Impact This memory management gap presents a local kernel panic/Denial of Service = (DoS). It manifests immediately if non-standard namespaces attempt to attac= h ISO images against arbitrary file descriptors instead of block device bou= ndaries. Proposed Fix To intercept the vulnerability effectively, we suggest introducing a prelim= inary null-check protecting the interface invocations directly inside the s= uperblock assembly: ```diff --- a/fs/isofs/inode.c +++ b/fs/isofs/inode.c @@ -598,6 +598,12 @@ static int isofs_fill_super(struct super_block *s, str= uct fs_context *fc) * larger than the blocksize the user specified, then use * that value. */ +=09 + if (!s->s_bdev) { + printk(KERN_WARNING "ISOFS: missing underlying block device\n"); + goto out_freesbi; + } +=09 /* * What if bugger tells us to go beyond page size? */ ``` We would be highly honored if this could be of any help. Best regards, RacePilot Team