CVE-2024-53047: mptcp: init: protect sched with rcu_read_lock

In the Linux kernel, the following vulnerability has been resolved:

mptcp: init: protect sched with rcureadlock

Enabling CONFIGPROVERCULIST with its dependence CONFIGRCUEXPERT creates this splat when an MPTCP socket is created:

============================= WARNING: suspicious RCU usage 6.12.0-rc2+ #11 Not tainted ----------------------------- net/mptcp/sched.c:44 RCU-list traversed in non-reader section!!

other info that might help us debug this:

rcuscheduleractive = 2, debuglocks = 1 no locks held by mptcpconnect/176.

stack backtrace: CPU: 0 UID: 0 PID: 176 Comm: mptcpconnect Not tainted 6.12.0-rc2+ #11 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: <TASK> dumpstacklvl (lib/dumpstack.c:123) lockdeprcususpicious (kernel/locking/lockdep.c:6822) mptcpschedfind (net/mptcp/sched.c:44 (discriminator 7)) mptcpinitsock (net/mptcp/protocol.c:2867 (discriminator 1)) ? sockinitdatauid (arch/x86/include/asm/atomic.h:28) inetcreate.part.0.constprop.0 (net/ipv4/afinet.c:386) ? sockcreate (include/linux/rcupdate.h:347 (discriminator 1)) sockcreate (net/socket.c:1576) syssocket (net/socket.c:1671) ? pfxsyssocket (net/socket.c:1712) ? douseraddrfault (arch/x86/mm/fault.c:1419 (discriminator 1)) x64syssocket (net/socket.c:1728) dosyscall64 (arch/x86/entry/common.c:52 (discriminator 1)) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130)

That's because when the socket is initialised, rcureadlock() is not used despite the explicit comment written above the declaration of mptcpschedfind() in sched.c. Adding the missing lock/unlock avoids the warning.

— NVD

This CVE was automatically created from a reference found in an email or other text. If you are reading this, then this CVE entry is probably erroneous, since this text should be replaced by the official CVE description automatically.

— Launchpad