linux-kernel - Re: [PATCH] fs: improve dump

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZaiJIIrzUR7qPkjC@casper.infradead.org>
Date: Thu, 18 Jan 2024 02:12:48 +0000
From: Matthew Wilcox <willy@...radead.org>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: Baolin Wang <baolin.wang@...ux.alibaba.com>, akpm@...ux-foundation.org,
	brauner@...nel.org, jack@...e.cz, linux-mm@...ck.org,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fs: improve dump_mapping() robustness

On Thu, Jan 18, 2024 at 01:38:57AM +0000, Al Viro wrote:
> On Tue, Jan 16, 2024 at 03:53:35PM +0800, Baolin Wang wrote:
> 
> > With checking the 'dentry.parent' and 'dentry.d_name.name' used by
> > dentry_name(), I can see dump_mapping() will output the invalid dentry
> > instead of crashing the system when this issue is reproduced again.
> 
> >  	dentry_ptr = container_of(dentry_first, struct dentry, d_u.d_alias);
> > -	if (get_kernel_nofault(dentry, dentry_ptr)) {
> > +	if (get_kernel_nofault(dentry, dentry_ptr) ||
> > +	    !dentry.d_parent || !dentry.d_name.name) {
> >  		pr_warn("aops:%ps ino:%lx invalid dentry:%px\n",
> >  				a_ops, ino, dentry_ptr);
> >  		return;
> 
> That's nowhere near enough.  Your ->d_name.name can bloody well be pointing
> to an external name that gets freed right under you.  Legitimately so.
> 
> Think what happens if dentry has a long name (longer than would fit into
> the embedded array) and gets renamed name just after you copy it into
> a local variable.  Old name will get freed.  Yes, freeing is RCU-delayed,
> but I don't see anything that would prevent your thread losing CPU
> and not getting it back until after the sucker's been freed.

Agreed that it's not enough.  It does usually work, and it's very
helpful when it does.  We've had it since 2018 (1c6fb1d89e73) and we've
been gradually making it more robust over time.  Part of my reason for
splitting dump_mapping() out of dump_page() was so that it would get
more review from people who understand the fs side of things ... and
that seems to have worked.

Can I trouble you to suggest a more robust solution?  Bear in mind that
dump_page() does get called on pointers which turn out not to even be
pointers to struct page so this is all very much best-effort, and giving
up and printing 'this is not a dentry" is always an option.