linux-kernel - Re: [PATCH] acct: Prevent NULL pointer dereference when writing to sysfs

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: <20250211002308.GG1977892@ZenIV>
Date: Tue, 11 Feb 2025 00:23:08 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: Christian Brauner <brauner@...nel.org>
Cc: Zicheng Qu <quzicheng@...wei.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>, jlayton@...nel.org,
	axboe@...nel.dk, joel.granados@...nel.org, tglx@...utronix.de,
	linux-kernel@...r.kernel.org, hch@....de, len.brown@...el.com,
	pavel@....cz, pengfei.xu@...el.com, rafael@...nel.org,
	syzkaller-bugs@...glegroups.com, linux-pm@...r.kernel.org,
	tanghui20@...wei.com, zhangqiao22@...wei.com,
	judy.chenhui@...wei.com
Subject: Re: [PATCH] acct: Prevent NULL pointer dereference when writing to
 sysfs

On Mon, Feb 10, 2025 at 06:19:02PM +0000, Al Viro wrote:
> On Mon, Feb 10, 2025 at 05:02:35PM +0100, Christian Brauner wrote:
> > On Mon, Feb 10, 2025 at 03:21:46PM +0000, Al Viro wrote:
> > > On Mon, Feb 10, 2025 at 04:12:54PM +0100, Christian Brauner wrote:
> > > 
> > > > One fix would be to move exit_fs() past exit_task_work(). It looks like
> > > > that this should be doable without much of a problem and it would fix
> > > > the path_init() problem.
> > > > 
> > > > There should hopefully be nothing relying on task->fs == NULL in
> > > > exit_task_work().
> > > 
> > > There's a question of the task_work_add() issued by exit_task_fs(),
> > > though.
> > 
> > Can't we simply remove the pins on the mounts of fs->root and fs->pwd in
> > exit_fs() explicitly? If that works I think that's a fair enough
> > compromise for this shite.
> 
> I'd rather go for a simpler approach...  Why do we need those writes
> to be done in context of exiting process in the first place?  It's
> not as if they needed to go out before it terminates, so what's to
> stop us from having a kernel thread in background and queue the data
> to be written for it to pick up?
> 
> Does anybody see problems with that approach?

Note, BTW, that games with rlimit and creds switching disappear if done
that way.  

FWIW, I wonder if we should simply allocate a page worth of buffer,
occupied by acct_t array, with count + pointer to buffer kept in acct,
with acct->mutex used to protect the entire thing, so that do_acct_process()
would add a record to that sucker and wake the kthread up, with kthread
handling actual writes and emptying the buffer.  No need for exit(2)
to wait unless the buffer is full...