{ "cveId": "CVE-2022-50652", "url": "https://patchblox.com/security/cve/CVE-2022-50652", "summary": "CVE-2022-50652 is fixed in linux on 1 platform, first by DEBIAN-CVE-2022-50652, released December 9, 2025. It is not reported as exploited. Patch Radar priority: Routine.", "title": "linux: In the Linux kernel, the following vulnerability has been resolved: uio: uio_dmem_genirq: Fix missing unlock in irq...", "description": "In the Linux kernel, the following vulnerability has been resolved: uio: uio_dmem_genirq: Fix missing unlock in irq configuration Commit b74351287d4b (\u0022uio: fix a sleep-in-atomic-context bug in uio_dmem_genirq_irqcontrol()\u0022) started calling disable_irq() 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 \u0027\\x00\\x00\\x00\\x00\u0027 \u003E /dev/uio0 root@localhost:~# printf \u0027\\x00\\x00\\x00\\x00\u0027 \u003E /dev/uio0 root@localhost:~# [ 14.851538] BUG: scheduling while atomic: bash/223/0x00000002 [ 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] [ 14.854206] CPU: 0 PID: 223 Comm: bash Tainted: G OE 6.0.0-rc7 #21 [ 14.854786] Hardware name: QEMU Standard PC (i440FX \u002B PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 14.855664] Call Trace: [ 14.855861] \u003CTASK\u003E [ 14.856025] dump_stack_lvl\u002B0x4d/0x67 [ 14.856325] dump_stack\u002B0x14/0x1a [ 14.856583] __schedule_bug.cold\u002B0x4b/0x5c [ 14.856915] __schedule\u002B0xe81/0x13d0 [ 14.857199] ? idr_find\u002B0x13/0x20 [ 14.857456] ? get_work_pool\u002B0x2d/0x50 [ 14.857756] ? __flush_work\u002B0x233/0x280 [ 14.858068] ? __schedule\u002B0xa95/0x13d0 [ 14.858307] ? idr_find\u002B0x13/0x20 [ 14.858519] ? get_work_pool\u002B0x2d/0x50 [ 14.858798] schedule\u002B0x6c/0x100 [ 14.859009] schedule_hrtimeout_range_clock\u002B0xff/0x110 [ 14.859335] ? tty_write_room\u002B0x1f/0x30 [ 14.859598] ? n_tty_poll\u002B0x1ec/0x220 [ 14.859830] ? tty_ldisc_deref\u002B0x1a/0x20 [ 14.860090] schedule_hrtimeout_range\u002B0x17/0x20 [ 14.860373] do_select\u002B0x596/0x840 [ 14.860627] ? __kernel_text_address\u002B0x16/0x50 [ 14.860954] ? poll_freewait\u002B0xb0/0xb0 [ 14.861235] ? poll_freewait\u002B0xb0/0xb0 [ 14.861517] ? rpm_resume\u002B0x49d/0x780 [ 14.861798] ? common_interrupt\u002B0x59/0xa0 [ 14.862127] ? asm_common_interrupt\u002B0x2b/0x40 [ 14.862511] ? __uart_start.isra.0\u002B0x61/0x70 [ 14.862902] ? __check_object_size\u002B0x61/0x280 [ 14.863255] core_sys_select\u002B0x1c6/0x400 [ 14.863575] ? vfs_write\u002B0x1c9/0x3d0 [ 14.863853] ? vfs_write\u002B0x1c9/0x3d0 [ 14.864121] ? _copy_from_user\u002B0x45/0x70 [ 14.864526] do_pselect.constprop.0\u002B0xb3/0xf0 [ 14.864893] ? do_syscall_64\u002B0x6d/0x90 [ 14.865228] ? do_syscall_64\u002B0x6d/0x90 [ 14.865556] __x64_sys_pselect6\u002B0x76/0xa0 [ 14.865906] do_syscall_64\u002B0x60/0x90 [ 14.866214] ? syscall_exit_to_user_mode\u002B0x2a/0x50 [ 14.866640] ? do_syscall_64\u002B0x6d/0x90 [ 14.866972] ? do_syscall_64\u002B0x6d/0x90 [ 14.867286] ? do_syscall_64\u002B0x6d/0x90 [ 14.867626] entry_SYSCALL_64_after_hwframe\u002B0x63/0xcd [...] stripped [ 14.872959] \u003C/TASK\u003E (\u0027myfpga\u0027 is a simple \u0027uio_dmem_genirq\u0027 driver I wrote to test this) The implementation of \u0022uio_dmem_genirq\u0022 was based on \u0022uio_pdrv_genirq\u0022 and it is used in a similar manner to the \u0022uio_pdrv_genirq\u0022 driver with respect to interrupt configuration and handling. At the time \u0022uio_dmem_genirq\u0022 was introduced, both had the same implementation of the \u0027uio_info\u0027 handlers irqcontrol() and handler(). Then commit 34cb27528398 (\u0022UIO: Fix concurrency issue\u0022), which was only applied to \u0022uio_pdrv_genirq\u0022, ended up making them a little different. That commit, among other things, changed disable_irq() to disable_irq_nosync() 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 disable_irq() waits for the completion of the irq handler. By changing disable_irq() to disable_irq_nosync() in irqcontrol(), we also avoid the sleeping-whil ---truncated---", "published": "2025-12-09T01:16:48Z", "severity": "", "epss": 0.00232, "epssPercentile": 0.1413, "priority": "Routine", "priorityTier": 4, "exploited": false, "vendorExploited": false, "disclosed": false, "fixes": [ { "platform": "linux", "product": "linux", "release": "Debian 12.15 (bookworm)", "fixedVersion": "6.1.4-1", "fix": "DEBIAN-CVE-2022-50652", "url": "https://patchblox.com/security/fix/linux/debian-cve-2022-50652", "released": "2025-12-09T01:16:48Z" }, { "platform": "linux", "product": "linux", "release": "Debian 13.5 (trixie)", "fixedVersion": "6.1.4-1", "fix": "DEBIAN-CVE-2022-50652", "url": "https://patchblox.com/security/fix/linux/debian-cve-2022-50652", "released": "2025-12-09T01:16:48Z" }, { "platform": "linux", "product": "linux", "release": "Debian 14", "fixedVersion": "6.1.4-1", "fix": "DEBIAN-CVE-2022-50652", "url": "https://patchblox.com/security/fix/linux/debian-cve-2022-50652", "released": "2025-12-09T01:16:48Z" } ], "noFixYet": [], "dataAsOf": "2026-11-08T00:53:09Z", "attribution": { "text": "Data: Patchblox Patch Radar", "url": "https://patchblox.com/security/patch-radar", "terms": "https://patchblox.com/security/patch-radar/use-the-data" } }