DEBIAN-CVE-2023-53809

In the Linux kernel, the following vulnerability has been resolved: l2tp: Avoid possible recursive deadlock in l2tptunnelregister() When a file descriptor of pppol2tp socket is passed as file descriptor of UDP socket, a recursive deadlock occurs in l2tptunnelregister(). This situation is reproduced by the following program: int main(void) { int sock; struct sockaddrpppol2tp addr; sock = socket(AFPPPOX, SOCKDGRAM, PXPROTOOL2TP); if (sock < 0) { perror("socket"); return 1; } addr.safamily = AFPPPOX; addr.saprotocol = PXPROTOOL2TP; addr.pppol2tp.pid = 0; addr.pppol2tp.fd = sock; addr.pppol2tp.addr.sinfamily = PFINET; addr.pppol2tp.addr.sinport = htons(0); addr.pppol2tp.addr.sinaddr.saddr = inetaddr("192.168.0.1"); addr.pppol2tp.stunnel = 1; addr.pppol2tp.ssession = 0; addr.pppol2tp.dtunnel = 0; addr.pppol2tp.dsession = 0; if (connect(sock, (const struct sockaddr *)&addr, sizeof(addr)) < 0) { perror("connect"); return 1; } return 0; } This program causes the following lockdep warning: ============================================ WARNING: possible recursive locking detected 6.2.0-rc5-00205-gc96618275234 #56 Not tainted -------------------------------------------- repro/8607 is trying to acquire lock: ffff8880213c8130 (sklock-AFPPPOX){+.+.}-{0:0}, at: l2tptunnelregister+0x2b7/0x11c0 but task is already holding lock: ffff8880213c8130 (sklock-AFPPPOX){+.+.}-{0:0}, at: pppol2tpconnect+0xa82/0x1a30 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(sklock-AFPPPOX); lock(sklock-AFPPPOX); *** DEADLOCK *** May be due to missing lock nesting notation 1 lock held by repro/8607: #0: ffff8880213c8130 (sklock-AFPPPOX){+.+.}-{0:0}, at: pppol2tpconnect+0xa82/0x1a30 stack backtrace: CPU: 0 PID: 8607 Comm: repro Not tainted 6.2.0-rc5-00205-gc96618275234 #56 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x100/0x178 __lockacquire.cold+0x119/0x3b9 ? lockdephardirqsonprepare+0x410/0x410 lockacquire+0x1e0/0x610 ? l2tptunnelregister+0x2b7/0x11c0 ? lockdowngrade+0x710/0x710 ? __fgetfiles+0x283/0x3e0 locksocknested+0x3a/0xf0 ? l2tptunnelregister+0x2b7/0x11c0 l2tptunnelregister+0x2b7/0x11c0 ? sprintf+0xc4/0x100 ? l2tptunneldelwork+0x6b0/0x6b0 ? debugobjectdeactivate+0x320/0x320 ? lockdepinitmaptype+0x16d/0x7a0 ? lockdepinitmaptype+0x16d/0x7a0 ? l2tptunnelcreate+0x2bf/0x4b0 ? l2tptunnelcreate+0x3c6/0x4b0 pppol2tpconnect+0x14e1/0x1a30 ? pppol2tpputsk+0xd0/0xd0 ? aaskperm+0x2b7/0xa80 ? aaafperm+0x260/0x260 ? bpflsmsocketconnect+0x9/0x10 ? pppol2tpputsk+0xd0/0xd0 __sysconnectfile+0x14f/0x190 __sys_connect+0x133/0x160 ? __sysconnectfile+0x190/0x190 ? lockdephardirqson+0x7d/0x100 ? ktimegetcoarserealts64+0x1b7/0x200 ? ktimegetcoarserealts64+0x147/0x200 ? __auditsyscallentry+0x396/0x500 __x64sysconnect+0x72/0xb0 dosyscall64+0x38/0xb0 entrySYSCALL64afterhwframe+0x63/0xcd This patch fixes the issue by getting/creating the tunnel before locking the pppol2tp socket.