netdev - Re: [syzbot] [mptcp?] general protection fault in proc

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: <CANn89i+GUGLQSFp3a2qwH+zOsR-46CyWevjhAQQMmO5K9tmkUg@mail.gmail.com>
Date: Sun, 5 Jan 2025 09:32:36 +0100
From: Eric Dumazet <edumazet@...gle.com>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: Matthieu Baerts <matttbe@...nel.org>, davem@...emloft.net, geliang@...nel.org, 
	horms@...nel.org, kuba@...nel.org, linux-kernel@...r.kernel.org, 
	martineau@...nel.org, mptcp@...ts.linux.dev, netdev@...r.kernel.org, 
	pabeni@...hat.com, syzkaller-bugs@...glegroups.com, 
	syzbot <syzbot+e364f774c6f57f2c86d1@...kaller.appspotmail.com>
Subject: Re: [syzbot] [mptcp?] general protection fault in proc_scheduler

On Sat, Jan 4, 2025 at 9:21 PM Al Viro <viro@...iv.linux.org.uk> wrote:
>
> On Sat, Jan 04, 2025 at 08:11:49PM +0100, Matthieu Baerts wrote:
> > >> +       if (S_ISREG(file_inode(file)->i_mode))
>                 ^^^^^^^^^
> > >> +               return;
> > >
> > > ... won't help, since the file in question *is* a regular file.  IOW, it's
> > > a wrong predicate here.
> >
> > On my side, it looks like I'm not able to reproduce the issue with this
> > patch. Without it, it is very easy to reproduce it. (But I don't know if
> > there are other consequences that would avoid the issue to happen: when
> > looking at the logs, with the patch, I don't have heaps of "Process
> > accounting resumed" messages that I had before.)
>
> Unsurprisingly so, since it rejects all regular files due to a typo;
> fix that and you'll see that the oops is still there.
>
> The real issue (and the one that affects more than just this scenario) is
> the use of current->nsproxy->net to get to the damn thing.

According to grep, we have many other places directly reading
current->nsproxy->net_ns
For instance in net/sctp/sysctl.c
Should we change them all ?

Perhaps an alternative would be to add a generic check in
proc_sys_call_handler()

diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c
index 27a283d85a6e7df1a7edbfb513ce75832363e2e6..84968b10ce86e7fd88c6e3c43f52b601394b056f
100644
--- a/fs/proc/proc_sysctl.c
+++ b/fs/proc/proc_sysctl.c
@@ -576,6 +576,8 @@ static ssize_t proc_sys_call_handler(struct kiocb
*iocb, struct iov_iter *iter,
        error = -EINVAL;
        if (!table->proc_handler)
                goto out;
+       if (unlikely(current->flags & PF_EXITING))
+               goto out;

        /* don't even try if the size is too large */
        error = -ENOMEM;


Thanks.