CVE-2022-50705
Description
In the Linux kernel, the following vulnerability has been resolved:
io_uring/rw: defer fsnotify calls to task context
We can't call these off the kiocb completion as that might be off soft/hard irq context. Defer the calls to when we process the task_work for this request. That avoids valid complaints like:
stack backtrace: CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.0.0-rc6-syzkaller-00321-g105a36f3694e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/26/2022 Call Trace:
__dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_usage_bug kernel/locking/lockdep.c:3961 [inline] valid_state kernel/locking/lockdep.c:3973 [inline] mark_lock_irq kernel/locking/lockdep.c:4176 [inline] mark_lock.part.0.cold+0x18/0xd8 kernel/locking/lockdep.c:4632 mark_lock kernel/locking/lockdep.c:4596 [inline] mark_usage kernel/locking/lockdep.c:4527 [inline] __lock_acquire+0x11d9/0x56d0 kernel/locking/lockdep.c:5007 lock_acquire kernel/locking/lockdep.c:5666 [inline] lock_acquire+0x1ab/0x570 kernel/locking/lockdep.c:5631 __fs_reclaim_acquire mm/page_alloc.c:4674 [inline] fs_reclaim_acquire+0x115/0x160 mm/page_alloc.c:4688 might_alloc include/linux/sched/mm.h:271 [inline] slab_pre_alloc_hook mm/slab.h:700 [inline] slab_alloc mm/slab.c:3278 [inline] __kmem_cache_alloc_lru mm/slab.c:3471 [inline] kmem_cache_alloc+0x39/0x520 mm/slab.c:3491 fanotify_alloc_fid_event fs/notify/fanotify/fanotify.c:580 [inline] fanotify_alloc_event fs/notify/fanotify/fanotify.c:813 [inline] fanotify_handle_event+0x1130/0x3f40 fs/notify/fanotify/fanotify.c:948 send_to_group fs/notify/fsnotify.c:360 [inline] fsnotify+0xafb/0x1680 fs/notify/fsnotify.c:570 __fsnotify_parent+0x62f/0xa60 fs/notify/fsnotify.c:230 fsnotify_parent include/linux/fsnotify.h:77 [inline] fsnotify_file include/linux/fsnotify.h:99 [inline] fsnotify_access include/linux/fsnotify.h:309 [inline] __io_complete_rw_common+0x485/0x720 io_uring/rw.c:195 io_complete_rw+0x1a/0x1f0 io_uring/rw.c:228 iomap_dio_complete_work fs/iomap/direct-io.c:144 [inline] iomap_dio_bio_end_io+0x438/0x5e0 fs/iomap/direct-io.c:178 bio_endio+0x5f9/0x780 block/bio.c:1564 req_bio_endio block/blk-mq.c:695 [inline] blk_update_request+0x3fc/0x1300 block/blk-mq.c:825 scsi_end_request+0x7a/0x9a0 drivers/scsi/scsi_lib.c:541 scsi_io_completion+0x173/0x1f70 drivers/scsi/scsi_lib.c:971 scsi_complete+0x122/0x3b0 drivers/scsi/scsi_lib.c:1438 blk_complete_reqs+0xad/0xe0 block/blk-mq.c:1022 __do_softirq+0x1d3/0x9c6 kernel/softirq.c:571 invoke_softirq kernel/softirq.c:445 [inline] __irq_exit_rcu+0x123/0x180 kernel/softirq.c:650 irq_exit_rcu+0x5/0x20 kernel/softirq.c:662 common_interrupt+0xa9/0xc0 arch/x86/kernel/irq.c:240
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
In the Linux kernel, io_uring calls fsnotify functions from interrupt context, causing a lockdep splat; deferred to task context.
Root
Cause
CVE-2022-50705 is a vulnerability in the Linux kernel's io_uring subsystem, specifically in the read/write (rw) completion path. The __io_complete_rw_common function in io_uring/rw.c calls fsnotify_access and similar file system notification functions. These functions may allocate memory (e.g., via fanotify_alloc_event) and therefore need to run in a context where memory reclaim is allowed. However, the completion path can be invoked from hard or soft interrupt context, where calling into the memory allocator with GFP_KERNEL is invalid and triggers a lockdep warning about reclaim context. The kernel stack trace in the description shows the call chain leading to a lock_acquire on fs_reclaim from an IRQ handler, which violates lockdep rules. [1]
Attack
Surface and Prerequisites
Exploitation of this issue does not require local access or special privileges beyond being able to submit io_uring requests that complete and trigger file system notifications. An attacker who can trigger many io_uring reads or writes on a file system with file notification watches (e.g., fanotify, inotify) could repeatedly cause the kernel to execute the invalid memory allocation path from interrupt context. This is a denial-of-service condition, as the lockdep warning is a symptom of a potential deadlock or memory corruption if the allocation succeeds in an unsafe context. No authentication or specific network position is required; the attack can be performed by any user able to use io_uring, which is available to unprivileged users in default configurations. [1]
Impact
If triggered, the vulnerability leads to a kernel splat (lockdep warning) and can potentially cause a system hang or crash due to undefined behavior when memory allocation is attempted in IRQ context. In the worst case, an attacker could exploit this to cause a denial of service (system panic) or, under specific conditions, achieve privilege escalation by corrupting kernel memory. The primary impact is denial of service, as the kernel may become unstable or panic. [1]
Mitigation
A patch has been applied to the Linux kernel stable tree (commit 89a410dbd0f159d8f6ecd6ba682fc753e4771). The fix defers the fsnotify calls to task work context, which is a safe context for memory allocation. Users should update to a kernel version that includes this patch. No workarounds are available aside from avoiding the use of io_uring with file notification watches, which is impractical. The vulnerability is fixed in kernel version 6.0 and later stable updates. [1]
AI Insight generated on May 19, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
1Patches
389a410dbd0f12a853c206e55b000145e9907Vulnerability mechanics
Generated on May 9, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
3News mentions
0No linked articles in our index yet.