From: Al Viro <viro@zeniv.linux.org.uk>
To: Eric Dumazet <edumazet@google.com>
Cc: Matthieu Baerts <matttbe@kernel.org>,
davem@davemloft.net, geliang@kernel.org, horms@kernel.org,
kuba@kernel.org, linux-kernel@vger.kernel.org,
martineau@kernel.org, mptcp@lists.linux.dev,
netdev@vger.kernel.org, pabeni@redhat.com,
syzkaller-bugs@googlegroups.com,
syzbot <syzbot+e364f774c6f57f2c86d1@syzkaller.appspotmail.com>
Subject: Re: [syzbot] [mptcp?] general protection fault in proc_scheduler
Date: Sun, 5 Jan 2025 20:50:56 +0000 [thread overview]
Message-ID: <20250105205056.GK1977892@ZenIV> (raw)
In-Reply-To: <20250105195434.GJ1977892@ZenIV>
On Sun, Jan 05, 2025 at 07:54:34PM +0000, Al Viro wrote:
> 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.
FWIW, looks like we have two such in mptcp (with sysctls next to
those definitely accessing the netns of opener rather than reader/writer),
two in rds (both inconsistent on the write side -
struct net *net = current->nsproxy->net_ns;
int err;
err = proc_dointvec_minmax(ctl, write, buffer, lenp, fpos);
if (err < 0) {
pr_warn("Invalid input. Must be >= %d\n",
*(int *)(ctl->extra1));
return err;
}
if (write)
rds_tcp_sysctl_reset(net);
will modify ctl->data, which points to &rtn->{snd,rcv}buf_size, with
rtn == net_generic(net, rds_tcp_netid) and net being for opener's netns
and then call rds_tcp_sysctl_reset(net) with net being the writer's
netns) and 6 in sctp. At least some of sctp ones are also inconsistent
on the write side; e.g.
static int proc_sctp_do_rto_min(const struct ctl_table *ctl, int write,
void *buffer, size_t *lenp, loff_t *ppos)
{
struct net *net = current->nsproxy->net_ns;
unsigned int min = *(unsigned int *) ctl->extra1;
unsigned int max = *(unsigned int *) ctl->extra2;
struct ctl_table tbl;
int ret, new_value;
memset(&tbl, 0, sizeof(struct ctl_table));
tbl.maxlen = sizeof(unsigned int);
if (write)
tbl.data = &new_value;
else
tbl.data = &net->sctp.rto_min;
ret = proc_dointvec(&tbl, write, buffer, lenp, ppos);
if (write && ret == 0) {
if (new_value > max || new_value < min)
return -EINVAL;
net->sctp.rto_min = new_value;
}
return ret;
}
has max taken from ctl->extra2, which is &net->sctp.rto_max of the
opener's netns, but the value capped by that in stored into
net->sctp.rto_min of *writer's* netns. So the logics that is supposed
to prevent rto_min > rto_max can be bypassed; no idea how much can that
escalate to, but it's clearly not what the code intends.
So I'd rather document the "don't assume that current->nsproxy->netns will
point to the same netns this ctl is for" and fix those 10 instances - at
least some smell seriously fishy. It's not just the acct(2) weirdness and
the damage may be worse than an oops...
next prev parent reply other threads:[~2025-01-05 20:50 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-02 14:12 [syzbot] [mptcp?] general protection fault in proc_scheduler syzbot
2025-01-02 15:21 ` Eric Dumazet
2025-01-04 18:38 ` Matthieu Baerts
2025-01-04 18:53 ` Eric Dumazet
2025-01-04 19:00 ` Al Viro
2025-01-04 19:11 ` Matthieu Baerts
2025-01-04 20:21 ` Al Viro
2025-01-05 8:32 ` Eric Dumazet
2025-01-05 11:29 ` Al Viro
2025-01-05 16:52 ` Eric Dumazet
2025-01-05 17:03 ` Matthieu Baerts
2025-01-05 19:54 ` Al Viro
2025-01-05 20:50 ` Al Viro [this message]
2025-01-05 21:11 ` Al Viro
2025-01-05 17:03 ` Matthieu Baerts
2025-01-04 19:11 ` Matthieu Baerts
2025-01-06 13:32 ` Joel Granados
2025-01-06 14:27 ` Matthieu Baerts
2025-01-06 15:27 ` Eric Dumazet
2025-01-06 15:34 ` Matthieu Baerts
2025-01-08 14:37 ` Joel Granados
2025-01-04 20:09 ` Al Viro
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=20250105205056.GK1977892@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=geliang@kernel.org \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martineau@kernel.org \
--cc=matttbe@kernel.org \
--cc=mptcp@lists.linux.dev \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=syzbot+e364f774c6f57f2c86d1@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).