{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2022-50652 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2022-50652 is a denial of service vulnerability in Linux, published on 9 Dec 2025. It can only be exploited from the same machine or local network, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2022-50652 and fix it if it is affected.\n\nWhat it is: CVE-2022-50652 is a denial of service vulnerability in Linux, published on 9 Dec 2025. It can only be exploited from the same machine or local network, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2022-50652 in the wild and no public exploit code.\n\nAffected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2022-50652/ (Markdown: https://insights.sbomify.com/CVE-2022-50652/index.md)","id":"CVE-2022-50652","markdown":"https://insights.sbomify.com/CVE-2022-50652/index.md","name":"CVE-2022-50652","record":{"aliases":["DEBIAN-CVE-2022-50652","GHSA-7863-hf67-mmwv","UBUNTU-CVE-2022-50652"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel","requires_auth":"low_privilege","summary":"A local attacker can cause a kernel panic and system crash by repeatedly writing to a specific UIO device file due to a missing spinlock unlock.","user_interaction":"not_required","vuln_class":"denial_of_service"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\nuio: uio_dmem_genirq: Fix missing unlock in irq configuration\n\nCommit b74351287d4b (\"uio: fix a sleep-in-atomic-context bug in\nuio_dmem_genirq_irqcontrol()\") started calling disable_irq() without\nholding the spinlock because it can sleep. However, that fix introduced\nanother bug: if interrupt is already disabled and a new disable request\ncomes in, then the spinlock is not unlocked:\n\nroot@localhost:~# printf '\\x00\\x00\\x00\\x00' \u003e /dev/uio0\nroot@localhost:~# printf '\\x00\\x00\\x00\\x00' \u003e /dev/uio0\nroot@localhost:~# [   14.851538] BUG: scheduling while atomic: bash/223/0x00000002\n[   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]\n[   14.854206] CPU: 0 PID: 223 Comm: bash Tainted: G           OE      6.0.0-rc7 #21\n[   14.854786] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\n[   14.855664] Call Trace:\n[   14.855861]  \u003cTASK\u003e\n[   14.856025]  dump_stack_lvl+0x4d/0x67\n[   14.856325]  dump_stack+0x14/0x1a\n[   14.856583]  __schedule_bug.cold+0x4b/0x5c\n[   14.856915]  __schedule+0xe81/0x13d0\n[   14.857199]  ? idr_find+0x13/0x20\n[   14.857456]  ? get_work_pool+0x2d/0x50\n[   14.857756]  ? __flush_work+0x233/0x280\n[   14.858068]  ? __schedule+0xa95/0x13d0\n[   14.858307]  ? idr_find+0x13/0x20\n[   14.858519]  ? get_work_pool+0x2d/0x50\n[   14.858798]  schedule+0x6c/0x100\n[   14.859009]  schedule_hrtimeout_range_clock+0xff/0x110\n[   14.859335]  ? tty_write_room+0x1f/0x30\n[   14.859598]  ? n_tty_poll+0x1ec/0x220\n[   14.859830]  ? tty_ldisc_deref+0x1a/0x20\n[   14.860090]  schedule_hrtimeout_range+0x17/0x20\n[   14.860373]  do_select+0x596/0x840\n[   14.860627]  ? __kernel_text_address+0x16/0x50\n[   14.860954]  ? poll_freewait+0xb0/0xb0\n[   14.861235]  ? poll_freewait+0xb0/0xb0\n[   14.861517]  ? rpm_resume+0x49d/0x780\n[   14.861798]  ? common_interrupt+0x59/0xa0\n[   14.862127]  ? asm_common_interrupt+0x2b/0x40\n[   14.862511]  ? __uart_start.isra.0+0x61/0x70\n[   14.862902]  ? __check_object_size+0x61/0x280\n[   14.863255]  core_sys_select+0x1c6/0x400\n[   14.863575]  ? vfs_write+0x1c9/0x3d0\n[   14.863853]  ? vfs_write+0x1c9/0x3d0\n[   14.864121]  ? _copy_from_user+0x45/0x70\n[   14.864526]  do_pselect.constprop.0+0xb3/0xf0\n[   14.864893]  ? do_syscall_64+0x6d/0x90\n[   14.865228]  ? do_syscall_64+0x6d/0x90\n[   14.865556]  __x64_sys_pselect6+0x76/0xa0\n[   14.865906]  do_syscall_64+0x60/0x90\n[   14.866214]  ? syscall_exit_to_user_mode+0x2a/0x50\n[   14.866640]  ? do_syscall_64+0x6d/0x90\n[   14.866972]  ? do_syscall_64+0x6d/0x90\n[   14.867286]  ? do_syscall_64+0x6d/0x90\n[   14.867626]  entry_SYSCALL_64_after_hwframe+0x63/0xcd\n[...] stripped\n[   14.872959]  \u003c/TASK\u003e\n\n('myfpga' is a simple 'uio_dmem_genirq' driver I wrote to test this)\n\nThe implementation of \"uio_dmem_genirq\" was based on \"uio_pdrv_genirq\" and\nit is used in a similar manner to the \"uio_pdrv_genirq\" driver with respect\nto interrupt configuration and handling. At the time \"uio_dmem_genirq\" was\nintroduced, both had the same implementation of the 'uio_info' handlers\nirqcontrol() and handler(). Then commit 34cb27528398 (\"UIO: Fix concurrency\nissue\"), which was only applied to \"uio_pdrv_genirq\", ended up making them\na little different. That commit, among other things, changed disable_irq()\nto disable_irq_nosync() in the implementation of irqcontrol(). The\nmotivation there was to avoid a deadlock between irqcontrol() and\nhandler(), since it added a spinlock in the irq handler, and disable_irq()\nwaits for the completion of the irq handler.\n\nBy changing disable_irq() to disable_irq_nosync() in irqcontrol(), we also\navoid the sleeping-whil\n---truncated---","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"uio: uio_dmem_genirq: Fix missing unlock in irq configuration","id":"CVE-2022-50652","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"denial_of_service","year":"2022"},"n_packages":0,"n_references":9,"next":{"headline":"mmc: atmel-mci: fix return value check of mmc_add_host()","id":"CVE-2022-50653"},"packages":[],"prev":{"headline":"ethtool: eeprom: fix null-deref on genl_info in dump","id":"CVE-2022-50651"},"products":["Linux"],"published":"2025-12-09","related":[],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-05-23","vendors":["Linux"]},"summary":"A local attacker can cause a kernel panic and system crash by repeatedly writing to a specific UIO device file due to a missing spinlock unlock.","url":"https://insights.sbomify.com/CVE-2022-50652/"}