DEBIAN-CVE-2022-50652

In the Linux kernel, the following vulnerability has been resolved: uio: uiodmemgenirq: Fix missing unlock in irq configuration Commit b74351287d4b ("uio: fix a sleep-in-atomic-context bug in uiodmemgenirqirqcontrol()") started calling disableirq() without holding the spinlock because it can sleep. However, that fix introduced another bug: if interrupt is already disabled and a new disable request comes in, then the spinlock is not unlocked: root@localhost:~# printf '\x00\x00\x00\x00' > /dev/uio0 root@localhost:~# printf '\x00\x00\x00\x00' > /dev/uio0 root@localhost:~# [ 14.851538] BUG: scheduling while atomic: bash/223/0x00000002 [ 14.851991] Modules linked in: uiodmemgenirq uio myfpga(OE) bochs drmvramhelper drmttmhelper ttm drmkmshelper drm sndpcm ppdev joydev psmouse sndtimer snd e1000fbsysfops syscopyarea parport sysfillrect soundcore sysimgblt inputleds pcspkr i2cpiix4 serioraw floppy evbug qemufwcfg machid pataacpi iptables xtables autofs4 [last unloaded: parportpc] [ 14.854206] CPU: 0 PID: 223 Comm: bash Tainted: G OE 6.0.0-rc7 #21 [ 14.854786] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 14.855664] Call Trace: [ 14.855861] <TASK> [ 14.856025] dumpstacklvl+0x4d/0x67 [ 14.856325] dumpstack+0x14/0x1a [ 14.856583] _schedulebug.cold+0x4b/0x5c [ 14.856915] _schedule+0xe81/0x13d0 [ 14.857199] ? idrfind+0x13/0x20 [ 14.857456] ? getworkpool+0x2d/0x50 [ 14.857756] ? _flushwork+0x233/0x280 [ 14.858068] ? _schedule+0xa95/0x13d0 [ 14.858307] ? idrfind+0x13/0x20 [ 14.858519] ? getworkpool+0x2d/0x50 [ 14.858798] schedule+0x6c/0x100 [ 14.859009] schedulehrtimeoutrangeclock+0xff/0x110 [ 14.859335] ? ttywriteroom+0x1f/0x30 [ 14.859598] ? nttypoll+0x1ec/0x220 [ 14.859830] ? ttyldiscderef+0x1a/0x20 [ 14.860090] schedulehrtimeoutrange+0x17/0x20 [ 14.860373] doselect+0x596/0x840 [ 14.860627] ? _kerneltextaddress+0x16/0x50 [ 14.860954] ? pollfreewait+0xb0/0xb0 [ 14.861235] ? pollfreewait+0xb0/0xb0 [ 14.861517] ? rpmresume+0x49d/0x780 [ 14.861798] ? commoninterrupt+0x59/0xa0 [ 14.862127] ? asmcommoninterrupt+0x2b/0x40 [ 14.862511] ? _uartstart.isra.0+0x61/0x70 [ 14.862902] ? _checkobjectsize+0x61/0x280 [ 14.863255] coresysselect+0x1c6/0x400 [ 14.863575] ? vfswrite+0x1c9/0x3d0 [ 14.863853] ? vfswrite+0x1c9/0x3d0 [ 14.864121] ? _copyfromuser+0x45/0x70 [ 14.864526] dopselect.constprop.0+0xb3/0xf0 [ 14.864893] ? dosyscall64+0x6d/0x90 [ 14.865228] ? dosyscall64+0x6d/0x90 [ 14.865556] _x64syspselect6+0x76/0xa0 [ 14.865906] dosyscall64+0x60/0x90 [ 14.866214] ? syscallexittousermode+0x2a/0x50 [ 14.866640] ? dosyscall64+0x6d/0x90 [ 14.866972] ? dosyscall64+0x6d/0x90 [ 14.867286] ? dosyscall64+0x6d/0x90 [ 14.867626] entrySYSCALL64afterhwframe+0x63/0xcd [...] stripped [ 14.872959] </TASK> ('myfpga' is a simple 'uiodmemgenirq' driver I wrote to test this) The implementation of "uiodmemgenirq" was based on "uiopdrvgenirq" and it is used in a similar manner to the "uiopdrvgenirq" driver with respect to interrupt configuration and handling. At the time "uiodmemgenirq" was introduced, both had the same implementation of the 'uioinfo' handlers irqcontrol() and handler(). Then commit 34cb27528398 ("UIO: Fix concurrency issue"), which was only applied to "uiopdrvgenirq", ended up making them a little different. That commit, among other things, changed disableirq() to disableirqnosync() in the implementation of irqcontrol(). The motivation there was to avoid a deadlock between irqcontrol() and handler(), since it added a spinlock in the irq handler, and disableirq() waits for the completion of the irq handler. By changing disableirq() to disableirq_nosync() in irqcontrol(), we also avoid the sleeping-whil ---truncated---