CVE-2024-53047
- Source
- https://nvd.nist.gov/vuln/detail/CVE-2024-53047
- Import Source
- https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2024-53047.json
- JSON Data
- https://api.test.osv.dev/v1/vulns/CVE-2024-53047
- Downstream
- Related
- Published
- 2024-11-19T18:15:25Z
- Modified
- 2025-10-01T21:16:21Z
- Severity
-
- 5.5 (Medium) CVSS_V3 - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H CVSS Calculator
- Summary
- [none]
- Details
-
In the Linux kernel, the following vulnerability has been resolved:
mptcp: init: protect sched with rcureadlock
Enabling CONFIGPROVERCULIST with its dependence CONFIGRCU_EXPERT 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.
- References