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 sockaddr_pppol2tp addr;

sock = socket(AF_PPPOX, SOCK_DGRAM, PX_PROTO_OL2TP);
if (sock < 0) {
    perror("socket");
    return 1;
}

addr.sa_family = AF_PPPOX;
addr.sa_protocol = PX_PROTO_OL2TP;
addr.pppol2tp.pid = 0;
addr.pppol2tp.fd = sock;
addr.pppol2tp.addr.sin_family = PF_INET;
addr.pppol2tp.addr.sin_port = htons(0);
addr.pppol2tp.addr.sin_addr.s_addr = inet_addr("192.168.0.1");
addr.pppol2tp.s_tunnel = 1;
addr.pppol2tp.s_session = 0;
addr.pppol2tp.d_tunnel = 0;
addr.pppol2tp.d_session = 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: pppol2tp_connect+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: pppol2tp_connect+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.