CVE-2022-50652

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> uio: uio_dmem_genirq: Fix missing unlock in irq configuration<br /> <br /> Commit b74351287d4b ("uio: fix a sleep-in-atomic-context bug in<br /> uio_dmem_genirq_irqcontrol()") started calling disable_irq() without<br /> holding the spinlock because it can sleep. However, that fix introduced<br /> another bug: if interrupt is already disabled and a new disable request<br /> comes in, then the spinlock is not unlocked:<br /> <br /> root@localhost:~# printf &amp;#39;\x00\x00\x00\x00&amp;#39; &gt; /dev/uio0<br /> root@localhost:~# printf &amp;#39;\x00\x00\x00\x00&amp;#39; &gt; /dev/uio0<br /> root@localhost:~# [ 14.851538] BUG: scheduling while atomic: bash/223/0x00000002<br /> [ 14.851991] Modules linked in: uio_dmem_genirq uio myfpga(OE) bochs drm_vram_helper drm_ttm_helper ttm drm_kms_helper drm snd_pcm ppdev joydev psmouse snd_timer snd e1000fb_sys_fops syscopyarea parport sysfillrect soundcore sysimgblt input_leds pcspkr i2c_piix4 serio_raw floppy evbug qemu_fw_cfg mac_hid pata_acpi ip_tables x_tables autofs4 [last unloaded: parport_pc]<br /> [ 14.854206] CPU: 0 PID: 223 Comm: bash Tainted: G OE 6.0.0-rc7 #21<br /> [ 14.854786] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> [ 14.855664] Call Trace:<br /> [ 14.855861] <br /> [ 14.856025] dump_stack_lvl+0x4d/0x67<br /> [ 14.856325] dump_stack+0x14/0x1a<br /> [ 14.856583] __schedule_bug.cold+0x4b/0x5c<br /> [ 14.856915] __schedule+0xe81/0x13d0<br /> [ 14.857199] ? idr_find+0x13/0x20<br /> [ 14.857456] ? get_work_pool+0x2d/0x50<br /> [ 14.857756] ? __flush_work+0x233/0x280<br /> [ 14.858068] ? __schedule+0xa95/0x13d0<br /> [ 14.858307] ? idr_find+0x13/0x20<br /> [ 14.858519] ? get_work_pool+0x2d/0x50<br /> [ 14.858798] schedule+0x6c/0x100<br /> [ 14.859009] schedule_hrtimeout_range_clock+0xff/0x110<br /> [ 14.859335] ? tty_write_room+0x1f/0x30<br /> [ 14.859598] ? n_tty_poll+0x1ec/0x220<br /> [ 14.859830] ? tty_ldisc_deref+0x1a/0x20<br /> [ 14.860090] schedule_hrtimeout_range+0x17/0x20<br /> [ 14.860373] do_select+0x596/0x840<br /> [ 14.860627] ? __kernel_text_address+0x16/0x50<br /> [ 14.860954] ? poll_freewait+0xb0/0xb0<br /> [ 14.861235] ? poll_freewait+0xb0/0xb0<br /> [ 14.861517] ? rpm_resume+0x49d/0x780<br /> [ 14.861798] ? common_interrupt+0x59/0xa0<br /> [ 14.862127] ? asm_common_interrupt+0x2b/0x40<br /> [ 14.862511] ? __uart_start.isra.0+0x61/0x70<br /> [ 14.862902] ? __check_object_size+0x61/0x280<br /> [ 14.863255] core_sys_select+0x1c6/0x400<br /> [ 14.863575] ? vfs_write+0x1c9/0x3d0<br /> [ 14.863853] ? vfs_write+0x1c9/0x3d0<br /> [ 14.864121] ? _copy_from_user+0x45/0x70<br /> [ 14.864526] do_pselect.constprop.0+0xb3/0xf0<br /> [ 14.864893] ? do_syscall_64+0x6d/0x90<br /> [ 14.865228] ? do_syscall_64+0x6d/0x90<br /> [ 14.865556] __x64_sys_pselect6+0x76/0xa0<br /> [ 14.865906] do_syscall_64+0x60/0x90<br /> [ 14.866214] ? syscall_exit_to_user_mode+0x2a/0x50<br /> [ 14.866640] ? do_syscall_64+0x6d/0x90<br /> [ 14.866972] ? do_syscall_64+0x6d/0x90<br /> [ 14.867286] ? do_syscall_64+0x6d/0x90<br /> [ 14.867626] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [...] stripped<br /> [ 14.872959] <br /> <br /> (&amp;#39;myfpga&amp;#39; is a simple &amp;#39;uio_dmem_genirq&amp;#39; driver I wrote to test this)<br /> <br /> The implementation of "uio_dmem_genirq" was based on "uio_pdrv_genirq" and<br /> it is used in a similar manner to the "uio_pdrv_genirq" driver with respect<br /> to interrupt configuration and handling. At the time "uio_dmem_genirq" was<br /> introduced, both had the same implementation of the &amp;#39;uio_info&amp;#39; handlers<br /> irqcontrol() and handler(). Then commit 34cb27528398 ("UIO: Fix concurrency<br /> issue"), which was only applied to "uio_pdrv_genirq", ended up making them<br /> a little different. That commit, among other things, changed disable_irq()<br /> to disable_irq_nosync() in the implementation of irqcontrol(). The<br /> motivation there was to avoid a deadlock between irqcontrol() and<br /> handler(), since it added a spinlock in the irq handler, and disable_irq()<br /> waits for the completion of the irq handler.<br /> <br /> By changing disable_irq() to disable_irq_nosync() in irqcontrol(), we also<br /> avoid the sleeping-whil<br /> ---truncated---