CVE-2024-49946

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

ppp: do not assume bh is held in pppchannelbridge_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, releasesock(), _releasesock(), and skbacklogrcv() might call the sk->skbacklog_rcv() handler in process context.

sybot caught ppp was not considering this case in pppchannelbridge_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: 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---