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: <20250105211158.GL1977892@ZenIV>
Date: Sun, 5 Jan 2025 21:11:58 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: Eric Dumazet <edumazet@...gle.com>
Cc: Matthieu Baerts <matttbe@...nel.org>, 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 Sun, Jan 05, 2025 at 08:50:56PM +0000, Al Viro wrote:

> 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.

Speaking of which, the logics that tries to maintain rto_min <= rto_max is
broken in another way.  There's no exclusion in those suckers.  IOW, if
we have set rto_min to 1 and rto_max to 10000, two processes can try to
write 1000 to rto_min and 10 to rto_max resp., with successful validations
done against the original state in both, followed by actual stores.
Result is rto_min == 1000 and rto_max == 10, which is probably not what
one wants there...

IOW, the validation and stores should be atomic; the same goes for another
pair (pf_retrans <= ps_retrans).  Again, I've no idea how severe it is,
but result seems to be at least contrary to expectation of the code
authors...