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

On Sun, Jan 05, 2025 at 05:52:19PM +0100, Eric Dumazet wrote:

On Sun, Jan 5, 2025 at 12:29 PM Al Viro [off-list ref] wrote:

quoted

On Sun, Jan 05, 2025 at 09:32:36AM +0100, Eric Dumazet wrote:

quoted

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.