CVE-2024-49946: ppp: do not assume bh is held in ppp_channel_bridge_input()
In the Linux kernel, the following vulnerability has been resolved:
ppp: do not assume bh is held in pppchannelbridgeinput()
Networking receive path is usually handled from BH handler. However, some protocols need to acquire the socket lock, and packets might be stored in the socket backlog is the socket was owned by a user process.
In this case, releasesock(), releasesock(), and skbacklogrcv() might call the sk->skbacklogrcv() handler in process context.
sybot caught ppp was not considering this case in pppchannelbridgeinput() :
WARNING: inconsistent lock state 6.11.0-rc7-syzkaller-g5f5673607153 #0 Not tainted -------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. ksoftirqd/1/24 [HC0[0]:SC1[1]:HE1:SE0] takes: ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: spinlock include/linux/spinlock.h:351 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: pppchannelbridgeinput drivers/net/ppp/pppgeneric.c:2272 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: pppinput+0x16c/0x854 drivers/net/ppp/pppgeneric.c:2304 {SOFTIRQ-ON-W} state was registered at: lockacquire+0x240/0x728 kernel/locking/lockdep.c:5759 rawspinlock include/linux/spinlockapismp.h:133 [inline] rawspinlock+0x48/0x60 kernel/locking/spinlock.c:154 spinlock include/linux/spinlock.h:351 [inline] pppchannelbridgeinput drivers/net/ppp/pppgeneric.c:2272 [inline] pppinput+0x16c/0x854 drivers/net/ppp/pppgeneric.c:2304 pppoercvcore+0xfc/0x314 drivers/net/ppp/pppoe.c:379 skbacklogrcv include/net/sock.h:1111 [inline] releasesock+0x1a8/0x3d8 net/core/sock.c:3004 releasesock+0x68/0x1b8 net/core/sock.c:3558 pppoesendmsg+0xc8/0x5d8 drivers/net/ppp/pppoe.c:903 socksendmsgnosec net/socket.c:730 [inline] socksendmsg net/socket.c:745 [inline] syssendto+0x374/0x4f4 net/socket.c:2204 dosyssendto net/socket.c:2216 [inline] sesyssendto net/socket.c:2212 [inline] arm64syssendto+0xd8/0xf8 net/socket.c:2212 invokesyscall arch/arm64/kernel/syscall.c:35 [inline] invokesyscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0svccommon+0x130/0x23c arch/arm64/kernel/syscall.c:132 doel0svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0svc+0x54/0x168 arch/arm64/kernel/entry-common.c:712 el0t64synchandler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t64sync+0x190/0x194 arch/arm64/kernel/entry.S:598 irq event stamp: 282914 hardirqs last enabled at (282914): [<ffff80008b42e30c>] rawspinunlockirqrestore include/linux/spinlockapismp.h:151 [inline] hardirqs last enabled at (282914): [<ffff80008b42e30c>] rawspinunlockirqrestore+0x38/0x98 kernel/locking/spinlock.c:194 hardirqs last disabled at (282913): [<ffff80008b42e13c>] rawspinlockirqsave include/linux/spinlockapismp.h:108 [inline] hardirqs last disabled at (282913): [<ffff80008b42e13c>] rawspinlockirqsave+0x2c/0x7c kernel/locking/spinlock.c:162 softirqs last enabled at (282904): [<ffff8000801f8e88>] softirqhandleend kernel/softirq.c:400 [inline] softirqs last enabled at (282904): [<ffff8000801f8e88>] handlesoftirqs+0xa3c/0xbfc kernel/softirq.c:582 softirqs last disabled at (282909): [<ffff8000801fbdf8>] runksoftirqd+0x70/0x158 kernel/softirq.c:928
other info that might help us debug this: Possible unsafe locking scenario:
CPU0 ---- lock(&pch->downl); <Interrupt> lock(&pch->downl);
DEADLOCK
1 lock held by ksoftirqd/1/24: #0: ffff80008f74dfa0 (rcureadlock){....}-{1:2}, at: rculockacquire+0x10/0x4c include/linux/rcupdate.h:325
stack backtrace: CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call trace: dumpbacktrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:319 showstack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:326 dumpsta ---truncated---
Other sources
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
Affected Software
Remediation
Event History
Frequently Asked Questions
What is the severity of CVE-2024-49946?
The severity of CVE-2024-49946 has not been explicitly rated but is associated with potential vulnerabilities in the Linux kernel networking stack.
How do I fix CVE-2024-49946?
To fix CVE-2024-49946, you should update your Linux kernel to a patched version such as 5.10.223-1, 6.1.123-1, or 6.12.12-1.
Which versions of the Linux kernel are affected by CVE-2024-49946?
CVE-2024-49946 affects Linux kernel versions between 5.11 and 5.15.168, 5.16 and 6.1.113, 6.2 and 6.6.55, 6.7 and 6.10.14, and 6.11 and 6.11.3.
What kind of vulnerability is CVE-2024-49946?
CVE-2024-49946 is a vulnerability that may arise from improper assumptions in the networking receive path within the Linux kernel.
Is there a workaround for CVE-2024-49946?
There are no official workarounds for CVE-2024-49946, and updating the kernel is the recommended approach to mitigate the vulnerability.