From: Christian Brauner <brauner@kernel.org>
To: Jeff Layton <jlayton@kernel.org>
Cc: Zicheng Qu <quzicheng@huawei.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
axboe@kernel.dk, joel.granados@kernel.org, tglx@linutronix.de,
viro@zeniv.linux.org.uk, hch@lst.de, len.brown@intel.com,
pavel@ucw.cz, pengfei.xu@intel.com, rafael@kernel.org,
tanghui20@huawei.com, zhangqiao22@huawei.com,
judy.chenhui@huawei.com, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org, syzkaller-bugs@googlegroups.com,
linux-pm@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH 0/2] acct: don't allow access to internal filesystems
Date: Thu, 13 Feb 2025 15:56:35 +0100 [thread overview]
Message-ID: <20250213-fehlgriff-filmt-1dfdd558ab78@brauner> (raw)
In-Reply-To: <20250212-giert-spannend-8893f1eaba7d@brauner>
On Wed, Feb 12, 2025 at 12:16:44PM +0100, Christian Brauner wrote:
> On Tue, Feb 11, 2025 at 01:56:41PM -0500, Jeff Layton wrote:
> > On Tue, 2025-02-11 at 18:15 +0100, Christian Brauner wrote:
> > > In [1] it was reported that the acct(2) system call can be used to
> > > trigger a NULL deref in cases where it is set to write to a file that
> > > triggers an internal lookup.
> > >
> > > This can e.g., happen when pointing acct(2) to /sys/power/resume. At the
> > > point the where the write to this file happens the calling task has
> > > already exited and called exit_fs() but an internal lookup might be
> > > triggered through lookup_bdev(). This may trigger a NULL-deref
> > > when accessing current->fs.
> > >
> > > This series does two things:
> > >
> > > - Reorganize the code so that the the final write happens from the
> > > workqueue but with the caller's credentials. This preserves the
> > > (strange) permission model and has almost no regression risk.
> > >
> > > - Block access to kernel internal filesystems as well as procfs and
> > > sysfs in the first place.
> > >
> > > This api should stop to exist imho.
> > >
> >
> > I wonder who uses it these days, and what would we suggest they replace
> > it with? Maybe syscall auditing?
>
> Someone pointed me to atop but that also works without it. Since this is
> a privileged api I think the natural candidate to replace all of this is
> bpf. I'm pretty sure that it's relatively straightforward to get a lot
> more information out of it than with acct(2) and it will probably be
> more performant too.
>
> Without any limitations as it is right now, acct(2) can easily lockup
> the system quite easily by pointing it to various things in sysfs and
> I'm sure it can be abused in other ways. So I wouldn't enable it.
And I totally forgot about taskstats via Netlink:
https://www.kernel.org/doc/Documentation/accounting/taskstats.txt
include/uapi/linux/taskstats.h
prev parent reply other threads:[~2025-02-13 14:56 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-10 14:04 [Syzkaller & bisect] There is general protection fault in path_init in v6.11-rc2 Pengfei Xu
2025-01-27 9:18 ` Zicheng Qu
2025-02-10 13:17 ` [PATCH] acct: Prevent NULL pointer dereference when writing to sysfs Zicheng Qu
2025-02-10 15:12 ` Christian Brauner
2025-02-10 15:21 ` Al Viro
2025-02-10 16:02 ` Christian Brauner
2025-02-10 18:19 ` Al Viro
2025-02-11 0:23 ` Al Viro
2025-02-11 10:17 ` Christian Brauner
2025-02-11 17:15 ` [PATCH 0/2] acct: don't allow access to internal filesystems Christian Brauner
2025-02-11 17:15 ` [PATCH 1/2] acct: perform last write from workqueue Christian Brauner
2025-02-11 17:16 ` [PATCH 2/2] acct: block access to kernel internal filesystems Christian Brauner
2025-02-11 20:30 ` Amir Goldstein
2025-02-11 20:54 ` Al Viro
2025-02-12 10:32 ` Christian Brauner
2025-02-11 18:56 ` [PATCH 0/2] acct: don't allow access to " Jeff Layton
2025-02-12 11:16 ` Christian Brauner
2025-02-13 14:56 ` Christian Brauner [this message]
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=20250213-fehlgriff-filmt-1dfdd558ab78@brauner \
--to=brauner@kernel.org \
--cc=axboe@kernel.dk \
--cc=hch@lst.de \
--cc=jlayton@kernel.org \
--cc=joel.granados@kernel.org \
--cc=judy.chenhui@huawei.com \
--cc=len.brown@intel.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=pengfei.xu@intel.com \
--cc=quzicheng@huawei.com \
--cc=rafael@kernel.org \
--cc=stable@vger.kernel.org \
--cc=syzkaller-bugs@googlegroups.com \
--cc=tanghui20@huawei.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
--cc=zhangqiao22@huawei.com \
/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.