CVE-2024-49946: Vulnerability in Linux Linux

Severity: highType: vulnerabilityCVE-2024-49946

In the Linux kernel, the following vulnerability has been resolved: ppp: do not assume bh is held in ppp_channel_bridge_input() 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, release_sock(), __release_sock(), and sk_backlog_rcv() might call the sk->sk_backlog_rcv() handler in process context. sybot caught ppp was not considering this case in ppp_channel_bridge_input() : 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: spin_lock include/linux/spinlock.h:351 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 {SOFTIRQ-ON-W} state was registered at: lock_acquire+0x240/0x728 kernel/locking/lockdep.c:5759 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline] _raw_spin_lock+0x48/0x60 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [inline] ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0xfc/0x314 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv include/net/sock.h:1111 [inline] __release_sock+0x1a8/0x3d8 net/core/sock.c:3004 release_sock+0x68/0x1b8 net/core/sock.c:3558 pppoe_sendmsg+0xc8/0x5d8 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x374/0x4f4 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __arm64_sys_sendto+0xd8/0xf8 net/socket.c:2212 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 irq event stamp: 282914 hardirqs last enabled at (282914): [<ffff80008b42e30c>] __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:151 [inline] hardirqs last enabled at (282914): [<ffff80008b42e30c>] _raw_spin_unlock_irqrestore+0x38/0x98 kernel/locking/spinlock.c:194 hardirqs last disabled at (282913): [<ffff80008b42e13c>] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline] hardirqs last disabled at (282913): [<ffff80008b42e13c>] _raw_spin_lock_irqsave+0x2c/0x7c kernel/locking/spinlock.c:162 softirqs last enabled at (282904): [<ffff8000801f8e88>] softirq_handle_end kernel/softirq.c:400 [inline] softirqs last enabled at (282904): [<ffff8000801f8e88>] handle_softirqs+0xa3c/0xbfc kernel/softirq.c:582 softirqs last disabled at (282909): [<ffff8000801fbdf8>] run_ksoftirqd+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 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire+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: dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:319 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:326 __dump_sta ---truncated---

AI Analysis

Technical Summary

CVE-2024-49946 is a vulnerability identified in the Linux kernel's PPP (Point-to-Point Protocol) networking subsystem, specifically within the function ppp_channel_bridge_input(). The vulnerability arises from incorrect assumptions about the locking state of bottom halves (BH) during packet processing. Normally, the networking receive path is handled in a BH context, but certain protocols require acquiring the socket lock, and packets may be queued in the socket backlog if the socket is owned by a user process. In these cases, functions such as release_sock(), __release_sock(), and sk_backlog_rcv() may invoke the sk->sk_backlog_rcv() handler in process context rather than BH context. The PPP code did not account for this scenario, leading to inconsistent lock states and potential deadlocks. The issue was detected by syzkaller, a kernel fuzzing tool, which reported warnings about inconsistent lock states and a possible deadlock scenario involving double locking of the same spinlock from different contexts (softirq and process context). This can cause kernel instability, including deadlocks and system hangs, due to improper synchronization in the PPP channel bridge input path. The vulnerability affects Linux kernel versions around 6.11.0-rc7 and likely earlier versions using the affected PPP code. No known exploits are reported in the wild yet, and no CVSS score has been assigned. The root cause is a race condition and locking mishandling in the PPP networking code, which can lead to kernel-level deadlocks and denial of service (DoS) conditions.

Potential Impact

For European organizations, this vulnerability poses a risk primarily to systems running Linux kernels with PPP networking enabled, which may include embedded devices, network appliances, and servers using PPPoE (PPP over Ethernet) for broadband connectivity. The impact includes potential kernel deadlocks causing system hangs or crashes, resulting in denial of service. This can disrupt critical network services, especially in ISPs, telecommunications infrastructure, and enterprises relying on PPP-based connections. While the vulnerability does not appear to allow privilege escalation or remote code execution directly, the resulting DoS can impact availability of network services and critical infrastructure. Organizations with Linux-based networking equipment or servers in sectors such as finance, healthcare, and government could face operational disruptions. The lack of known exploits reduces immediate risk, but the complexity of the bug and its presence in core networking code means it could be targeted in future attacks. The vulnerability also affects ARM64 architectures, which are increasingly common in European data centers and edge devices, broadening the scope of affected systems.

Mitigation Recommendations

1. Apply the official Linux kernel patches that address this locking issue in the PPP networking code as soon as they become available. Monitor Linux kernel mailing lists and vendor advisories for updates. 2. For organizations using custom or embedded Linux kernels, coordinate with vendors or internal development teams to backport the fix promptly. 3. Disable PPP and PPPoE services on systems where they are not required to reduce the attack surface. 4. Implement kernel hardening and monitoring tools that can detect and alert on kernel deadlocks or unusual locking behavior. 5. Use network segmentation to isolate PPP-based network devices from critical infrastructure to limit impact in case of DoS. 6. Conduct thorough testing of kernel updates in staging environments to ensure stability before production deployment. 7. Maintain up-to-date backups and incident response plans to recover quickly from potential DoS incidents caused by this vulnerability. 8. Engage with Linux distribution security teams to ensure timely patch availability and deployment guidance.