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

Al Viro
2025-01-04T20:21:28Z

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.

Why not something like
static int proc_scheduler(const struct ctl_table *ctl, int write,
void *buffer, size_t *lenp, loff_t *ppos)
{
char (*data)[MPTCP_SCHED_NAME_MAX] = table->data;
char val[MPTCP_SCHED_NAME_MAX];
struct ctl_table tbl = {
.data = val,
.maxlen = MPTCP_SCHED_NAME_MAX,
};
int ret;

strscpy(val, *data, MPTCP_SCHED_NAME_MAX);

ret = proc_dostring(&tbl, write, buffer, lenp, ppos);
if (write && ret == 0) {
rcu_read_lock();
sched = mptcp_sched_find(val);
if (sched)
strscpy(*data, val, MPTCP_SCHED_NAME_MAX);
else
ret = -ENOENT;
rcu_read_unlock();
}
return ret;
}

seeing that the data object you really want to access is
mptcp_get_pernet(net)->scheduler and you have that pointer
stored in table->data at the registration time?