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