Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Fixed bug on error when unloading amdgpu<br /> <br /> Fixed bug on error when unloading amdgpu.<br /> <br /> The error message is as follows:<br /> [ 377.706202] kernel BUG at drivers/gpu/drm/drm_buddy.c:278!<br /> [ 377.706215] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 377.706222] CPU: 4 PID: 8610 Comm: modprobe Tainted: G IOE 6.0.0-thomas #1<br /> [ 377.706231] Hardware name: ASUS System Product Name/PRIME Z390-A, BIOS 2004 11/02/2021<br /> [ 377.706238] RIP: 0010:drm_buddy_free_block+0x26/0x30 [drm_buddy]<br /> [ 377.706264] Code: 00 00 00 90 0f 1f 44 00 00 48 8b 0e 89 c8 25 00 0c 00 00 3d 00 04 00 00 75 10 48 8b 47 18 48 d3 e0 48 01 47 28 e9 fa fe ff ff 0b 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 54 55 48 89 f5 53<br /> [ 377.706282] RSP: 0018:ffffad2dc4683cb8 EFLAGS: 00010287<br /> [ 377.706289] RAX: 0000000000000000 RBX: ffff8b1743bd5138 RCX: 0000000000000000<br /> [ 377.706297] RDX: ffff8b1743bd5160 RSI: ffff8b1743bd5c78 RDI: ffff8b16d1b25f70<br /> [ 377.706304] RBP: ffff8b1743bd59e0 R08: 0000000000000001 R09: 0000000000000001<br /> [ 377.706311] R10: ffff8b16c8572400 R11: ffffad2dc4683cf0 R12: ffff8b16d1b25f70<br /> [ 377.706318] R13: ffff8b16d1b25fd0 R14: ffff8b1743bd59c0 R15: ffff8b16d1b25f70<br /> [ 377.706325] FS: 00007fec56c72c40(0000) GS:ffff8b1836500000(0000) knlGS:0000000000000000<br /> [ 377.706334] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 377.706340] CR2: 00007f9b88c1ba50 CR3: 0000000110450004 CR4: 00000000003706e0<br /> [ 377.706347] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 377.706354] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 377.706361] Call Trace:<br /> [ 377.706365] <br /> [ 377.706369] drm_buddy_free_list+0x2a/0x60 [drm_buddy]<br /> [ 377.706376] amdgpu_vram_mgr_fini+0xea/0x180 [amdgpu]<br /> [ 377.706572] amdgpu_ttm_fini+0x12e/0x1a0 [amdgpu]<br /> [ 377.706650] amdgpu_bo_fini+0x22/0x90 [amdgpu]<br /> [ 377.706727] gmc_v11_0_sw_fini+0x26/0x30 [amdgpu]<br /> [ 377.706821] amdgpu_device_fini_sw+0xa1/0x3c0 [amdgpu]<br /> [ 377.706897] amdgpu_driver_release_kms+0x12/0x30 [amdgpu]<br /> [ 377.706975] drm_dev_release+0x20/0x40 [drm]<br /> [ 377.707006] release_nodes+0x35/0xb0<br /> [ 377.707014] devres_release_all+0x8b/0xc0<br /> [ 377.707020] device_unbind_cleanup+0xe/0x70<br /> [ 377.707027] device_release_driver_internal+0xee/0x160<br /> [ 377.707033] driver_detach+0x44/0x90<br /> [ 377.707039] bus_remove_driver+0x55/0xe0<br /> [ 377.707045] pci_unregister_driver+0x3b/0x90<br /> [ 377.707052] amdgpu_exit+0x11/0x6c [amdgpu]<br /> [ 377.707194] __x64_sys_delete_module+0x142/0x2b0<br /> [ 377.707201] ? fpregs_assert_state_consistent+0x22/0x50<br /> [ 377.707208] ? exit_to_user_mode_prepare+0x3e/0x190<br /> [ 377.707215] do_syscall_64+0x38/0x90<br /> [ 377.707221] entry_SYSCALL_64_after_hwframe+0x63/0xcd

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915: Fix potential context UAFs<br /> <br /> gem_context_register() makes the context visible to userspace, and which<br /> point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl.<br /> So we need to ensure that nothing uses the ctx ptr after this. And we<br /> need to ensure that adding the ctx to the xarray is the *last* thing<br /> that gem_context_register() does with the ctx pointer.<br /> <br /> [tursulin: Stable and fixes tags add/tidy.]<br /> (cherry picked from commit bed4b455cf5374e68879be56971c1da563bcd90c)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/poll: add hash if ready poll request can&amp;#39;t complete inline<br /> <br /> If we don&amp;#39;t, then we may lose access to it completely, leading to a<br /> request leak. This will eventually stall the ring exit process as<br /> well.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/poll: don&amp;#39;t reissue in case of poll race on multishot request<br /> <br /> A previous commit fixed a poll race that can occur, but it&amp;#39;s only<br /> applicable for multishot requests. For a multishot request, we can safely<br /> ignore a spurious wakeup, as we never leave the waitqueue to begin with.<br /> <br /> A blunt reissue of a multishot armed request can cause us to leak a<br /> buffer, if they are ring provided. While this seems like a bug in itself,<br /> it&amp;#39;s not really defined behavior to reissue a multishot request directly.<br /> It&amp;#39;s less efficient to do so as well, and not required to rearm anything<br /> like it is for singleshot poll requests.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix race between quota rescan and disable leading to NULL pointer deref<br /> <br /> If we have one task trying to start the quota rescan worker while another<br /> one is trying to disable quotas, we can end up hitting a race that results<br /> in the quota rescan worker doing a NULL pointer dereference. The steps for<br /> this are the following:<br /> <br /> 1) Quotas are enabled;<br /> <br /> 2) Task A calls the quota rescan ioctl and enters btrfs_qgroup_rescan().<br /> It calls qgroup_rescan_init() which returns 0 (success) and then joins a<br /> transaction and commits it;<br /> <br /> 3) Task B calls the quota disable ioctl and enters btrfs_quota_disable().<br /> It clears the bit BTRFS_FS_QUOTA_ENABLED from fs_info-&gt;flags and calls<br /> btrfs_qgroup_wait_for_completion(), which returns immediately since the<br /> rescan worker is not yet running.<br /> Then it starts a transaction and locks fs_info-&gt;qgroup_ioctl_lock;<br /> <br /> 4) Task A queues the rescan worker, by calling btrfs_queue_work();<br /> <br /> 5) The rescan worker starts, and calls rescan_should_stop() at the start<br /> of its while loop, which results in 0 iterations of the loop, since<br /> the flag BTRFS_FS_QUOTA_ENABLED was cleared from fs_info-&gt;flags by<br /> task B at step 3);<br /> <br /> 6) Task B sets fs_info-&gt;quota_root to NULL;<br /> <br /> 7) The rescan worker tries to start a transaction and uses<br /> fs_info-&gt;quota_root as the root argument for btrfs_start_transaction().<br /> This results in a NULL pointer dereference down the call chain of<br /> btrfs_start_transaction(). The stack trace is something like the one<br /> reported in Link tag below:<br /> <br /> general protection fault, probably for non-canonical address 0xdffffc0000000041: 0000 [#1] PREEMPT SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000208-0x000000000000020f]<br /> CPU: 1 PID: 34 Comm: kworker/u4:2 Not tainted 6.1.0-syzkaller-13872-gb6bb9676f216 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022<br /> Workqueue: btrfs-qgroup-rescan btrfs_work_helper<br /> RIP: 0010:start_transaction+0x48/0x10f0 fs/btrfs/transaction.c:564<br /> Code: 48 89 fb 48 (...)<br /> RSP: 0018:ffffc90000ab7ab0 EFLAGS: 00010206<br /> RAX: 0000000000000041 RBX: 0000000000000208 RCX: ffff88801779ba80<br /> RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000<br /> RBP: dffffc0000000000 R08: 0000000000000001 R09: fffff52000156f5d<br /> R10: fffff52000156f5d R11: 1ffff92000156f5c R12: 0000000000000000<br /> R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000003<br /> FS: 0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f2bea75b718 CR3: 000000001d0cc000 CR4: 00000000003506e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> btrfs_qgroup_rescan_worker+0x3bb/0x6a0 fs/btrfs/qgroup.c:3402<br /> btrfs_work_helper+0x312/0x850 fs/btrfs/async-thread.c:280<br /> process_one_work+0x877/0xdb0 kernel/workqueue.c:2289<br /> worker_thread+0xb14/0x1330 kernel/workqueue.c:2436<br /> kthread+0x266/0x300 kernel/kthread.c:376<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308<br /> <br /> Modules linked in:<br /> <br /> So fix this by having the rescan worker function not attempt to start a<br /> transaction if it didn&amp;#39;t do any rescan work.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: qgroup: do not warn on record without old_roots populated<br /> <br /> [BUG]<br /> There are some reports from the mailing list that since v6.1 kernel, the<br /> WARN_ON() inside btrfs_qgroup_account_extent() gets triggered during<br /> rescan:<br /> <br /> WARNING: CPU: 3 PID: 6424 at fs/btrfs/qgroup.c:2756 btrfs_qgroup_account_extents+0x1ae/0x260 [btrfs]<br /> CPU: 3 PID: 6424 Comm: snapperd Tainted: P OE 6.1.2-1-default #1 openSUSE Tumbleweed 05c7a1b1b61d5627475528f71f50444637b5aad7<br /> RIP: 0010:btrfs_qgroup_account_extents+0x1ae/0x260 [btrfs]<br /> Call Trace:<br /> <br /> btrfs_commit_transaction+0x30c/0xb40 [btrfs c39c9c546c241c593f03bd6d5f39ea1b676250f6]<br /> ? start_transaction+0xc3/0x5b0 [btrfs c39c9c546c241c593f03bd6d5f39ea1b676250f6]<br /> btrfs_qgroup_rescan+0x42/0xc0 [btrfs c39c9c546c241c593f03bd6d5f39ea1b676250f6]<br /> btrfs_ioctl+0x1ab9/0x25c0 [btrfs c39c9c546c241c593f03bd6d5f39ea1b676250f6]<br /> ? __rseq_handle_notify_resume+0xa9/0x4a0<br /> ? mntput_no_expire+0x4a/0x240<br /> ? __seccomp_filter+0x319/0x4d0<br /> __x64_sys_ioctl+0x90/0xd0<br /> do_syscall_64+0x5b/0x80<br /> ? syscall_exit_to_user_mode+0x17/0x40<br /> ? do_syscall_64+0x67/0x80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x7fd9b790d9bf<br /> <br /> <br /> [CAUSE]<br /> Since commit e15e9f43c7ca ("btrfs: introduce<br /> BTRFS_QGROUP_RUNTIME_FLAG_NO_ACCOUNTING to skip qgroup accounting"), if<br /> our qgroup is already in inconsistent state, we will no longer do the<br /> time-consuming backref walk.<br /> <br /> This can leave some qgroup records without a valid old_roots ulist.<br /> Normally this is fine, as btrfs_qgroup_account_extents() would also skip<br /> those records if we have NO_ACCOUNTING flag set.<br /> <br /> But there is a small window, if we have NO_ACCOUNTING flag set, and<br /> inserted some qgroup_record without a old_roots ulist, but then the user<br /> triggered a qgroup rescan.<br /> <br /> During btrfs_qgroup_rescan(), we firstly clear NO_ACCOUNTING flag, then<br /> commit current transaction.<br /> <br /> And since we have a qgroup_record with old_roots = NULL, we trigger the<br /> WARN_ON() during btrfs_qgroup_account_extents().<br /> <br /> [FIX]<br /> Unfortunately due to the introduction of NO_ACCOUNTING flag, the<br /> assumption that every qgroup_record would have its old_roots populated<br /> is no longer correct.<br /> <br /> Fix the false alerts and drop the WARN_ON().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xhci: Fix null pointer dereference when host dies<br /> <br /> Make sure xhci_free_dev() and xhci_kill_endpoint_urbs() do not race<br /> and cause null pointer dereference when host suddenly dies.<br /> <br /> Usb core may call xhci_free_dev() which frees the xhci-&gt;devs[slot_id]<br /> virt device at the same time that xhci_kill_endpoint_urbs() tries to<br /> loop through all the device&amp;#39;s endpoints, checking if there are any<br /> cancelled urbs left to give back.<br /> <br /> hold the xhci spinlock while freeing the virt device

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Add exception protection processing for vd in axi_chan_handle_err function<br /> <br /> Since there is no protection for vd, a kernel panic will be<br /> triggered here in exceptional cases.<br /> <br /> You can refer to the processing of axi_chan_block_xfer_complete function<br /> <br /> The triggered kernel panic is as follows:<br /> <br /> [ 67.848444] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060<br /> [ 67.848447] Mem abort info:<br /> [ 67.848449] ESR = 0x96000004<br /> [ 67.848451] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 67.848454] SET = 0, FnV = 0<br /> [ 67.848456] EA = 0, S1PTW = 0<br /> [ 67.848458] Data abort info:<br /> [ 67.848460] ISV = 0, ISS = 0x00000004<br /> [ 67.848462] CM = 0, WnR = 0<br /> [ 67.848465] user pgtable: 4k pages, 48-bit VAs, pgdp=00000800c4c0b000<br /> [ 67.848468] [0000000000000060] pgd=0000000000000000, p4d=0000000000000000<br /> [ 67.848472] Internal error: Oops: 96000004 [#1] SMP<br /> [ 67.848475] Modules linked in: dmatest<br /> [ 67.848479] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.100-emu_x2rc+ #11<br /> [ 67.848483] pstate: 62000085 (nZCv daIf -PAN -UAO +TCO BTYPE=--)<br /> [ 67.848487] pc : axi_chan_handle_err+0xc4/0x230<br /> [ 67.848491] lr : axi_chan_handle_err+0x30/0x230<br /> [ 67.848493] sp : ffff0803fe55ae50<br /> [ 67.848495] x29: ffff0803fe55ae50 x28: ffff800011212200<br /> [ 67.848500] x27: ffff0800c42c0080 x26: ffff0800c097c080<br /> [ 67.848504] x25: ffff800010d33880 x24: ffff80001139d850<br /> [ 67.848508] x23: ffff0800c097c168 x22: 0000000000000000<br /> [ 67.848512] x21: 0000000000000080 x20: 0000000000002000<br /> [ 67.848517] x19: ffff0800c097c080 x18: 0000000000000000<br /> [ 67.848521] x17: 0000000000000000 x16: 0000000000000000<br /> [ 67.848525] x15: 0000000000000000 x14: 0000000000000000<br /> [ 67.848529] x13: 0000000000000000 x12: 0000000000000040<br /> [ 67.848533] x11: ffff0800c0400248 x10: ffff0800c040024a<br /> [ 67.848538] x9 : ffff800010576cd4 x8 : ffff0800c0400270<br /> [ 67.848542] x7 : 0000000000000000 x6 : ffff0800c04003e0<br /> [ 67.848546] x5 : ffff0800c0400248 x4 : ffff0800c4294480<br /> [ 67.848550] x3 : dead000000000100 x2 : dead000000000122<br /> [ 67.848555] x1 : 0000000000000100 x0 : ffff0800c097c168<br /> [ 67.848559] Call trace:<br /> [ 67.848562] axi_chan_handle_err+0xc4/0x230<br /> [ 67.848566] dw_axi_dma_interrupt+0xf4/0x590<br /> [ 67.848569] __handle_irq_event_percpu+0x60/0x220<br /> [ 67.848573] handle_irq_event+0x64/0x120<br /> [ 67.848576] handle_fasteoi_irq+0xc4/0x220<br /> [ 67.848580] __handle_domain_irq+0x80/0xe0<br /> [ 67.848583] gic_handle_irq+0xc0/0x138<br /> [ 67.848585] el1_irq+0xc8/0x180<br /> [ 67.848588] arch_cpu_idle+0x14/0x2c<br /> [ 67.848591] default_idle_call+0x40/0x16c<br /> [ 67.848594] do_idle+0x1f0/0x250<br /> [ 67.848597] cpu_startup_entry+0x2c/0x60<br /> [ 67.848600] rest_init+0xc0/0xcc<br /> [ 67.848603] arch_call_rest_init+0x14/0x1c<br /> [ 67.848606] start_kernel+0x4cc/0x500<br /> [ 67.848610] Code: eb0002ff 9a9f12d6 f2fbd5a2 f2fbd5a3 (a94602c1)<br /> [ 67.848613] ---[ end trace 585a97036f88203a ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix general protection fault in nilfs_btree_insert()<br /> <br /> If nilfs2 reads a corrupted disk image and tries to reads a b-tree node<br /> block by calling __nilfs_btree_get_block() against an invalid virtual<br /> block address, it returns -ENOENT because conversion of the virtual block<br /> address to a disk block address fails. However, this return value is the<br /> same as the internal code that b-tree lookup routines return to indicate<br /> that the block being searched does not exist, so functions that operate on<br /> that b-tree may misbehave.<br /> <br /> When nilfs_btree_insert() receives this spurious &amp;#39;not found&amp;#39; code from<br /> nilfs_btree_do_lookup(), it misunderstands that the &amp;#39;not found&amp;#39; check was<br /> successful and continues the insert operation using incomplete lookup path<br /> data, causing the following crash:<br /> <br /> general protection fault, probably for non-canonical address<br /> 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]<br /> ...<br /> RIP: 0010:nilfs_btree_get_nonroot_node fs/nilfs2/btree.c:418 [inline]<br /> RIP: 0010:nilfs_btree_prepare_insert fs/nilfs2/btree.c:1077 [inline]<br /> RIP: 0010:nilfs_btree_insert+0x6d3/0x1c10 fs/nilfs2/btree.c:1238<br /> Code: bc 24 80 00 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89<br /> ff e8 4b 02 92 fe 4d 8b 3f 49 83 c7 28 4c 89 f8 48 c1 e8 03 80 3c<br /> 28 00 74 08 4c 89 ff e8 2e 02 92 fe 4d 8b 3f 49 83 c7 02<br /> ...<br /> Call Trace:<br /> <br /> nilfs_bmap_do_insert fs/nilfs2/bmap.c:121 [inline]<br /> nilfs_bmap_insert+0x20d/0x360 fs/nilfs2/bmap.c:147<br /> nilfs_get_block+0x414/0x8d0 fs/nilfs2/inode.c:101<br /> __block_write_begin_int+0x54c/0x1a80 fs/buffer.c:1991<br /> __block_write_begin fs/buffer.c:2041 [inline]<br /> block_write_begin+0x93/0x1e0 fs/buffer.c:2102<br /> nilfs_write_begin+0x9c/0x110 fs/nilfs2/inode.c:261<br /> generic_perform_write+0x2e4/0x5e0 mm/filemap.c:3772<br /> __generic_file_write_iter+0x176/0x400 mm/filemap.c:3900<br /> generic_file_write_iter+0xab/0x310 mm/filemap.c:3932<br /> call_write_iter include/linux/fs.h:2186 [inline]<br /> new_sync_write fs/read_write.c:491 [inline]<br /> vfs_write+0x7dc/0xc50 fs/read_write.c:584<br /> ksys_write+0x177/0x2a0 fs/read_write.c:637<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> ...<br /> <br /> <br /> This patch fixes the root cause of this problem by replacing the error<br /> code that __nilfs_btree_get_block() returns on block address conversion<br /> failure from -ENOENT to another internal code -EINVAL which means that the<br /> b-tree metadata is corrupted.<br /> <br /> By returning -EINVAL, it propagates without glitches, and for all relevant<br /> b-tree operations, functions in the upper bmap layer output an error<br /> message indicating corrupted b-tree metadata via<br /> nilfs_bmap_convert_error(), and code -EIO will be eventually returned as<br /> it should be.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: xhci: Check endpoint is valid before dereferencing it<br /> <br /> When the host controller is not responding, all URBs queued to all<br /> endpoints need to be killed. This can cause a kernel panic if we<br /> dereference an invalid endpoint.<br /> <br /> Fix this by using xhci_get_virt_ep() helper to find the endpoint and<br /> checking if the endpoint is valid before dereferencing it.<br /> <br /> [233311.853271] xhci-hcd xhci-hcd.1.auto: xHCI host controller not responding, assume dead<br /> [233311.853393] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000e8<br /> <br /> [233311.853964] pc : xhci_hc_died+0x10c/0x270<br /> [233311.853971] lr : xhci_hc_died+0x1ac/0x270<br /> <br /> [233311.854077] Call trace:<br /> [233311.854085] xhci_hc_died+0x10c/0x270<br /> [233311.854093] xhci_stop_endpoint_command_watchdog+0x100/0x1a4<br /> [233311.854105] call_timer_fn+0x50/0x2d4<br /> [233311.854112] expire_timers+0xac/0x2e4<br /> [233311.854118] run_timer_softirq+0x300/0xabc<br /> [233311.854127] __do_softirq+0x148/0x528<br /> [233311.854135] irq_exit+0x194/0x1a8<br /> [233311.854143] __handle_domain_irq+0x164/0x1d0<br /> [233311.854149] gic_handle_irq.22273+0x10c/0x188<br /> [233311.854156] el1_irq+0xfc/0x1a8<br /> [233311.854175] lpm_cpuidle_enter+0x25c/0x418 [msm_pm]<br /> [233311.854185] cpuidle_enter_state+0x1f0/0x764<br /> [233311.854194] do_idle+0x594/0x6ac<br /> [233311.854201] cpu_startup_entry+0x7c/0x80<br /> [233311.854209] secondary_start_kernel+0x170/0x198

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nommu: fix memory leak in do_mmap() error path<br /> <br /> The preallocation of the maple tree nodes may leak if the error path to<br /> "error_just_free" is taken. Fix this by moving the freeing of the maple<br /> tree nodes to a shared location for all error paths.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring: lock overflowing for IOPOLL<br /> <br /> syzbot reports an issue with overflow filling for IOPOLL:<br /> <br /> WARNING: CPU: 0 PID: 28 at io_uring/io_uring.c:734 io_cqring_event_overflow+0x1c0/0x230 io_uring/io_uring.c:734<br /> CPU: 0 PID: 28 Comm: kworker/u4:1 Not tainted 6.2.0-rc3-syzkaller-16369-g358a161a6a9e #0<br /> Workqueue: events_unbound io_ring_exit_work<br /> Call trace:<br />  io_cqring_event_overflow+0x1c0/0x230 io_uring/io_uring.c:734<br />  io_req_cqe_overflow+0x5c/0x70 io_uring/io_uring.c:773<br />  io_fill_cqe_req io_uring/io_uring.h:168 [inline]<br />  io_do_iopoll+0x474/0x62c io_uring/rw.c:1065<br />  io_iopoll_try_reap_events+0x6c/0x108 io_uring/io_uring.c:1513<br />  io_uring_try_cancel_requests+0x13c/0x258 io_uring/io_uring.c:3056<br />  io_ring_exit_work+0xec/0x390 io_uring/io_uring.c:2869<br />  process_one_work+0x2d8/0x504 kernel/workqueue.c:2289<br />  worker_thread+0x340/0x610 kernel/workqueue.c:2436<br />  kthread+0x12c/0x158 kernel/kthread.c:376<br />  ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:863<br /> <br /> There is no real problem for normal IOPOLL as flush is also called with<br /> uring_lock taken, but it&amp;#39;s getting more complicated for IOPOLL|SQPOLL,<br /> for which __io_cqring_overflow_flush() happens from the CQ waiting path.