linux-kernel - Re: [PATCH] libfs: Fix NULL pointer access in simple_recursive

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: <2025111343-landowner-bush-149b@gregkh>
Date: Thu, 13 Nov 2025 08:25:32 -0500
From: Greg KH <gregkh@...uxfoundation.org>
To: "rom.wang" <r4o5m6e8o@....com>
Cc: lexander Viro <viro@...iv.linux.org.uk>,
	Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	Yufeng Wang <wangyufeng@...inos.cn>, stable@...r.kernel.org
Subject: Re: [PATCH] libfs: Fix NULL pointer access in
 simple_recursive_removal

On Thu, Nov 13, 2025 at 01:23:57PM +0800, rom.wang wrote:
> From: Yufeng Wang <wangyufeng@...inos.cn>
> 
> There is an issue in the kernel:
> if inode is NULL pointer. the function "inode_lock_nested"
> (or function "inode_lock" before)
> a crash will happen at code "&inode->i_rwsem".

How is inode NULL?  What is causing that?

> [292618.520532] BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0
> [...]
> [292618.560398] RIP: 0010:down_write+0x12/0x30
> [292618.565580] Code: 83 f8 01 74 08 48 c7 47 20 01 00 00 00 f3 c3 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 ba 01 00 00 00 ff ff ff ff 48 89 f8 <f0> 48 0f c1 10 85 d2 74 05 e8 00 43 ff ff 65 48 8b 04 25 80 5c 01
> [292618.587219] RSP: 0018:ffffb898dc86fc20 EFLAGS: 00010246
> [292618.593666] RAX: 00000000000000a0 RBX: ffff94c84f363950 RCX: ffffff8000000000
> [292618.602255] RDX: ffffffff00000001 RSI: 0000000000000063 RDI: 00000000000000a0
> [292618.610844] RBP: ffffb898dc86fc78 R08: 0000000000000000 R09: 0000000000000000
> [292618.619434] R10: ffffb898dc86fca8 R11: 0000000000000000 R12: 0000000000000000
> [292618.628022] R13: ffff94c84f362a20 R14: ffff954d3f2fb4a0 R15: ffff954c3afa5010
> [292618.636612] FS:  0000555555989cc0(0000) GS:ffff956dbf900000(0000) knlGS:0000000000000000
> [292618.646271] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [292618.653300] CR2: 00000000000000a0 CR3: 000000fc7f25a000 CR4: 00000000003406e0
> [292618.661888] Call Trace:
> [292618.665225]  simple_recursive_removal+0x4f/0x230
> [292618.670994]  ? debug_fill_super+0xe0/0xe0
> [292618.676079]  debugfs_remove+0x40/0x60
> [292618.680799]  kvm_vcpu_release+0x19/0x30 [kvm]

Is the kvm code doing something wrong here?  debugfs shouldn't be trying
to remove an inode that is already removed, so please fix the root
cause, do not paper over it.

thanks,

greg k-h