From: Al Viro <viro@zeniv.linux.org.uk>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: "rom.wang" <r4o5m6e8o@163.com>,
Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
Yufeng Wang <wangyufeng@kylinos.cn>,
stable@vger.kernel.org
Subject: Re: [PATCH] libfs: Fix NULL pointer access in simple_recursive_removal
Date: Tue, 18 Nov 2025 17:04:50 +0000 [thread overview]
Message-ID: <20251118170450.GG2441659@ZenIV> (raw)
In-Reply-To: <2025111343-landowner-bush-149b@gregkh>
On Thu, Nov 13, 2025 at 08:25:32AM -0500, Greg KH wrote:
> On Thu, Nov 13, 2025 at 01:23:57PM +0800, rom.wang wrote:
> > From: Yufeng Wang <wangyufeng@kylinos.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.
That's... interesting. It's not just inode that is already removed,
it's very likely a dentry that has already beed freed (dentry with
refcount greater than 1 can not become negative).
next prev parent reply other threads:[~2025-11-18 17:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-13 5:23 [PATCH] libfs: Fix NULL pointer access in simple_recursive_removal rom.wang
2025-11-13 13:25 ` Greg KH
2025-11-18 17:04 ` Al Viro [this message]
2025-11-26 8:36 ` rom.wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251118170450.GG2441659@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=brauner@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=r4o5m6e8o@163.com \
--cc=stable@vger.kernel.org \
--cc=wangyufeng@kylinos.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.