CVE-2022-50116: tty: n_gsm: fix deadlock and link starvation in outgoing data path

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

tty: ngsm: fix deadlock and link starvation in outgoing data path

The current implementation queues up new control and user packets as needed and processes this queue down to the ldisc in the same code path. That means that the upper and the lower layer are hard coupled in the code. Due to this deadlocks can happen as seen below while transmitting data, especially during ldisc congestion. Furthermore, the data channels starve the control channel on high transmission load on the ldisc.

Introduce an additional control channel data queue to prevent timeouts and link hangups during ldisc congestion. This is being processed before the user channel data queue in gsmdatakick(), i.e. with the highest priority. Put the queue to ldisc data path into a workqueue and trigger it whenever new data has been put into the transmission queue. Change gsmdlcidatasweep() accordingly to fill up the transmission queue until TXTHRESHHI. This solves the locking issue, keeps latency low and provides good performance on high data load. Note that now all packets from a DLCI are removed from the internal queue if the associated DLCI was closed. This ensures that no data is sent by the introduced write task to an already closed DLCI.

BUG: spinlock recursion on CPU#0, testv24loop/124 lock: serial8250ports+0x3a8/0x7500, .magic: dead4ead, .owner: testv24loop/124, .ownercpu: 0 CPU: 0 PID: 124 Comm: testv24loop Tainted: G O 5.18.0-rc2 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <IRQ> dumpstacklvl+0x34/0x44 dorawspinlock+0x76/0xa0 rawspinlockirqsave+0x72/0x80 uartwriteroom+0x3b/0xc0 gsmdatakick+0x14b/0x240 [ngsm] gsmldwritewakeup+0x35/0x70 [ngsm] ttywakeup+0x53/0x60 ttyportdefaultwakeup+0x1b/0x30 serial8250txchars+0x12f/0x220 serial8250handleirq.part.0+0xfe/0x150 serial8250defaulthandleirq+0x48/0x80 serial8250interrupt+0x56/0xa0 handleirqeventpercpu+0x78/0x1f0 handleirqevent+0x34/0x70 handlefasteoiirq+0x90/0x1e0 commoninterrupt+0x69/0x100 commoninterrupt+0x48/0xc0 asmcommoninterrupt+0x1e/0x40 RIP: 0010:dosoftirq+0x83/0x34e Code: 2a 0a ff 0f b7 ed c7 44 24 10 0a 00 00 00 48 c7 c7 51 2a 64 82 e8 2d e2 d5 ff 65 66 c7 05 83 af 1e 7e 00 00 fb b8 ff ff ff ff <49> c7 c2 40 61 80 82 0f bc c5 41 89 c4 41 83 c4 01 0f 84 e6 00 00 RSP: 0018:ffffc90000003f98 EFLAGS: 00000286 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff82642a51 RDI: ffffffff825bb5e7 RBP: 0000000000000200 R08: 00000008de3271a8 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000030 R14: 0000000000000000 R15: 0000000000000000 ? dosoftirq+0x73/0x34e irqexitrcu+0xb5/0x100 commoninterrupt+0xa4/0xc0 </IRQ> <TASK> asmcommoninterrupt+0x1e/0x40 RIP: 0010:rawspinunlockirqrestore+0x2e/0x50 Code: 00 55 48 89 fd 48 83 c7 18 53 48 89 f3 48 8b 74 24 10 e8 85 28 36 ff 48 89 ef e8 cd 58 36 ff 80 e7 02 74 01 fb bf 01 00 00 00 <e8> 3d 97 33 ff 65 8b 05 96 23 2b 7e 85 c0 74 03 5b 5d c3 0f 1f 44 RSP: 0018:ffffc9000020fd08 EFLAGS: 00000202 RAX: 0000000000000000 RBX: 0000000000000246 RCX: 0000000000000000 RDX: 0000000000000004 RSI: ffffffff8257fd74 RDI: 0000000000000001 RBP: ffff8880057de3a0 R08: 00000008de233000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000100 R14: 0000000000000202 R15: ffff8880057df0b8 ? rawspinunlockirqrestore+0x23/0x50 gsmttywrite+0x65/0x80 [ngsm] nttywrite+0x33f/0x530 ? swakeupall+0xe0/0xe0 filettywrite.constprop.0+0x1b1/0x320 ? nttyflushbuffer+0xb0/0xb0 newsyncwrite+0x10c/0x190 vfswrite+0x282/0x310 ksyswrite+0x68/0xe0 dosyscall64+0x3b/0x90 entrySYSCALL64afterhwframe+0x44/0xae RIP: 0033:0x7f3e5e35c15c Code: 8b 7c 24 08 89 c5 e8 c5 ff ff ff 89 ef 89 44 24 ---truncated---