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: <20250104202126.GH1977892@ZenIV>
Date: Sat, 4 Jan 2025 20:21:26 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: Matthieu Baerts <matttbe@...nel.org>
Cc: Eric Dumazet <edumazet@...gle.com>, 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 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?