Re: [syzbot] [mptcp?] general protection fault in proc_scheduler

[Al Viro]

On Sun, Jan 05, 2025 at 05:52:19PM +0100, Eric Dumazet wrote:
> On Sun, Jan 5, 2025 at 12:29 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Sun, Jan 05, 2025 at 09:32:36AM +0100, Eric Dumazet wrote:
> >
> > > 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 ?
> >
> > Depends - do you want their contents match the netns of opener (as,
> > AFAICS, for ipv4 sysctls) or that of the reader?
> 
> I am only worried that a malicious user could crash the host with
> current kernels,
> not about this MPTP crash, but all unaware users of current->nsproxy
> in sysctl handlers.

I don't hate your mitigation in proc_sysctl.c, but IMO there are two
problems mixed here - one is that we probably should have access
to per-netns sysctl table act on the netns it had been created for,
which may not coincide with reader's/writer's netns and another is that
access to current->nsproxy->netns would simply oops if attempted when
current->nsproxy had been dropped.

So I suspect that current->nsproxy->netns shouldn't be used in
per-netns sysctls for consistency sake (note that it can get more
serious than just consistency, if you have e.g. a spinlock taken
in something hanging off current netns to protect access to
something table->data points to).

As for the mitigation in fs/proc/proc_sysctl.c... might be useful,
if it comes with a clear comment about the reasons it's there.