Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring: check for overflows in io_pin_pages<br /> <br /> WARNING: CPU: 0 PID: 5834 at io_uring/memmap.c:144 io_pin_pages+0x149/0x180 io_uring/memmap.c:144<br /> CPU: 0 UID: 0 PID: 5834 Comm: syz-executor825 Not tainted 6.12.0-next-20241118-syzkaller #0<br /> Call Trace:<br /> <br /> __io_uaddr_map+0xfb/0x2d0 io_uring/memmap.c:183<br /> io_rings_map io_uring/io_uring.c:2611 [inline]<br /> io_allocate_scq_urings+0x1c0/0x650 io_uring/io_uring.c:3470<br /> io_uring_create+0x5b5/0xc00 io_uring/io_uring.c:3692<br /> io_uring_setup io_uring/io_uring.c:3781 [inline]<br /> ...<br /> <br /> <br /> io_pin_pages()&amp;#39;s uaddr parameter came directly from the user and can be<br /> garbage. Don&amp;#39;t just add size to it as it can overflow.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: nl80211: fix bounds checker error in nl80211_parse_sched_scan<br /> <br /> The channels array in the cfg80211_scan_request has a __counted_by<br /> attribute attached to it, which points to the n_channels variable. This<br /> attribute is used in bounds checking, and if it is not set before the<br /> array is filled, then the bounds sanitizer will issue a warning or a<br /> kernel panic if CONFIG_UBSAN_TRAP is set.<br /> <br /> This patch sets the size of allocated memory as the initial value for<br /> n_channels. It is updated with the actual number of added elements after<br /> the array is filled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of failures<br /> <br /> Syzkaller reported a hung task with uevent_show() on stack trace. That<br /> specific issue was addressed by another commit [0], but even with that<br /> fix applied (for example, running v6.12-rc5) we face another type of hung<br /> task that comes from the same reproducer [1]. By investigating that, we<br /> could narrow it to the following path:<br /> <br /> (a) Syzkaller emulates a Realtek USB WiFi adapter using raw-gadget and<br /> dummy_hcd infrastructure.<br /> <br /> (b) During the probe of rtl8192cu, the driver ends-up performing an efuse<br /> read procedure (which is related to EEPROM load IIUC), and here lies the<br /> issue: the function read_efuse() calls read_efuse_byte() many times, as<br /> loop iterations depending on the efuse size (in our example, 512 in total).<br /> <br /> This procedure for reading efuse bytes relies in a loop that performs an<br /> I/O read up to *10k* times in case of failures. We measured the time of<br /> the loop inside read_efuse_byte() alone, and in this reproducer (which<br /> involves the dummy_hcd emulation layer), it takes 15 seconds each. As a<br /> consequence, we have the driver stuck in its probe routine for big time,<br /> exposing a stack trace like below if we attempt to reboot the system, for<br /> example:<br /> <br /> task:kworker/0:3 state:D stack:0 pid:662 tgid:662 ppid:2 flags:0x00004000<br /> Workqueue: usb_hub_wq hub_event<br /> Call Trace:<br /> __schedule+0xe22/0xeb6<br /> schedule_timeout+0xe7/0x132<br /> __wait_for_common+0xb5/0x12e<br /> usb_start_wait_urb+0xc5/0x1ef<br /> ? usb_alloc_urb+0x95/0xa4<br /> usb_control_msg+0xff/0x184<br /> _usbctrl_vendorreq_sync+0xa0/0x161<br /> _usb_read_sync+0xb3/0xc5<br /> read_efuse_byte+0x13c/0x146<br /> read_efuse+0x351/0x5f0<br /> efuse_read_all_map+0x42/0x52<br /> rtl_efuse_shadow_map_update+0x60/0xef<br /> rtl_get_hwinfo+0x5d/0x1c2<br /> rtl92cu_read_eeprom_info+0x10a/0x8d5<br /> ? rtl92c_read_chip_version+0x14f/0x17e<br /> rtl_usb_probe+0x323/0x851<br /> usb_probe_interface+0x278/0x34b<br /> really_probe+0x202/0x4a4<br /> __driver_probe_device+0x166/0x1b2<br /> driver_probe_device+0x2f/0xd8<br /> [...]<br /> <br /> We propose hereby to drastically reduce the attempts of doing the I/O<br /> reads in case of failures, restricted to USB devices (given that<br /> they&amp;#39;re inherently slower than PCIe ones). By retrying up to 10 times<br /> (instead of 10000), we got reponsiveness in the reproducer, while seems<br /> reasonable to believe that there&amp;#39;s no sane USB device implementation in<br /> the field requiring this amount of retries at every I/O read in order<br /> to properly work. Based on that assumption, it&amp;#39;d be good to have it<br /> backported to stable but maybe not since driver implementation (the 10k<br /> number comes from day 0), perhaps up to 6.x series makes sense.<br /> <br /> [0] Commit 15fffc6a5624 ("driver core: Fix uevent_show() vs driver detach race")<br /> <br /> [1] A note about that: this syzkaller report presents multiple reproducers<br /> that differs by the type of emulated USB device. For this specific case,<br /> check the entry from 2024/08/08 06:23 in the list of crashes; the C repro<br /> is available at https://syzkaller.appspot.com/text?tag=ReproC&amp;x=1521fc83980000.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: clk-loongson2: Fix memory corruption bug in struct loongson2_clk_provider<br /> <br /> Some heap space is allocated for the flexible structure `struct<br /> clk_hw_onecell_data` and its flexible-array member `hws` through<br /> the composite structure `struct loongson2_clk_provider` in function<br /> `loongson2_clk_probe()`, as shown below:<br /> <br /> 289 struct loongson2_clk_provider *clp;<br /> ...<br /> 296 for (p = data; p-&gt;name; p++)<br /> 297 clks_num++;<br /> 298<br /> 299 clp = devm_kzalloc(dev, struct_size(clp, clk_data.hws, clks_num),<br /> 300 GFP_KERNEL);<br /> <br /> Then some data is written into the flexible array:<br /> <br /> 350 clp-&gt;clk_data.hws[p-&gt;id] = hw;<br /> <br /> This corrupts `clk_lock`, which is the spinlock variable immediately<br /> following the `clk_data` member in `struct loongson2_clk_provider`:<br /> <br /> struct loongson2_clk_provider {<br /> void __iomem *base;<br /> struct device *dev;<br /> struct clk_hw_onecell_data clk_data;<br /> spinlock_t clk_lock; /* protect access to DIV registers */<br /> };<br /> <br /> The problem is that the flexible structure is currently placed in the<br /> middle of `struct loongson2_clk_provider` instead of at the end.<br /> <br /> Fix this by moving `struct clk_hw_onecell_data clk_data;` to the end of<br /> `struct loongson2_clk_provider`. Also, add a code comment to help<br /> prevent this from happening again in case new members are added to the<br /> structure in the future.<br /> <br /> This change also fixes the following -Wflex-array-member-not-at-end<br /> warning:<br /> <br /> drivers/clk/clk-loongson2.c:32:36: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: clk-loongson2: Fix potential buffer overflow in flexible-array member access<br /> <br /> Flexible-array member `hws` in `struct clk_hw_onecell_data` is annotated<br /> with the `counted_by()` attribute. This means that when memory is<br /> allocated for this array, the _counter_, which in this case is member<br /> `num` in the flexible structure, should be set to the maximum number of<br /> elements the flexible array can contain, or fewer.<br /> <br /> In this case, the total number of elements for the flexible array is<br /> determined by variable `clks_num` when allocating heap space via<br /> `devm_kzalloc()`, as shown below:<br /> <br /> 289 struct loongson2_clk_provider *clp;<br /> ...<br /> 296 for (p = data; p-&gt;name; p++)<br /> 297 clks_num++;<br /> 298<br /> 299 clp = devm_kzalloc(dev, struct_size(clp, clk_data.hws, clks_num),<br /> 300 GFP_KERNEL);<br /> <br /> So, `clp-&gt;clk_data.num` should be set to `clks_num` or less, and not<br /> exceed `clks_num`, as is currently the case. Otherwise, if data is<br /> written into `clp-&gt;clk_data.hws[clks_num]`, the instrumentation<br /> provided by the compiler won&amp;#39;t detect the overflow, leading to a<br /> memory corruption bug at runtime.<br /> <br /> Fix this issue by setting `clp-&gt;clk_data.num` to `clks_num`.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix use-after-free in SMB request handling<br /> <br /> A race condition exists between SMB request handling in<br /> `ksmbd_conn_handler_loop()` and the freeing of `ksmbd_conn` in the<br /> workqueue handler `handle_ksmbd_work()`. This leads to a UAF.<br /> - KASAN: slab-use-after-free Read in handle_ksmbd_work<br /> - KASAN: slab-use-after-free in rtlock_slowlock_locked<br /> <br /> This race condition arises as follows:<br /> - `ksmbd_conn_handler_loop()` waits for `conn-&gt;r_count` to reach zero:<br /> `wait_event(conn-&gt;r_count_q, atomic_read(&amp;conn-&gt;r_count) == 0);`<br /> - Meanwhile, `handle_ksmbd_work()` decrements `conn-&gt;r_count` using<br /> `atomic_dec_return(&amp;conn-&gt;r_count)`, and if it reaches zero, calls<br /> `ksmbd_conn_free()`, which frees `conn`.<br /> - However, after `handle_ksmbd_work()` decrements `conn-&gt;r_count`,<br /> it may still access `conn-&gt;r_count_q` in the following line:<br /> `waitqueue_active(&amp;conn-&gt;r_count_q)` or `wake_up(&amp;conn-&gt;r_count_q)`<br /> This results in a UAF, as `conn` has already been freed.<br /> <br /> The discovery of this UAF can be referenced in the following PR for<br /> syzkaller&amp;#39;s support for SMB requests.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: pcm: Add sanity NULL check for the default mmap fault handler<br /> <br /> A driver might allow the mmap access before initializing its<br /> runtime-&gt;dma_area properly. Add a proper NULL check before passing to<br /> virt_to_page() for avoiding a panic.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: Don&amp;#39;t leak cfid when reconnect races with open_cached_dir<br /> <br /> open_cached_dir() may either race with the tcon reconnection even before<br /> compound_send_recv() or directly trigger a reconnection via<br /> SMB2_open_init() or SMB_query_info_init().<br /> <br /> The reconnection process invokes invalidate_all_cached_dirs() via<br /> cifs_mark_open_files_invalid(), which removes all cfids from the<br /> cfids-&gt;entries list but doesn&amp;#39;t drop a ref if has_lease isn&amp;#39;t true. This<br /> results in the currently-being-constructed cfid not being on the list,<br /> but still having a refcount of 2. It leaks if returned from<br /> open_cached_dir().<br /> <br /> Fix this by setting cfid-&gt;has_lease when the ref is actually taken; the<br /> cfid will not be used by other threads until it has a valid time.<br /> <br /> Addresses these kmemleaks:<br /> <br /> unreferenced object 0xffff8881090c4000 (size 1024):<br /> comm "bash", pid 1860, jiffies 4295126592<br /> hex dump (first 32 bytes):<br /> 00 01 00 00 00 00 ad de 22 01 00 00 00 00 ad de ........".......<br /> 00 ca 45 22 81 88 ff ff f8 dc 4f 04 81 88 ff ff ..E"......O.....<br /> backtrace (crc 6f58c20f):<br /> [] __kmalloc_cache_noprof+0x2be/0x350<br /> [] open_cached_dir+0x993/0x1fb0<br /> [] cifs_readdir+0x15a0/0x1d50<br /> [] iterate_dir+0x28f/0x4b0<br /> [] __x64_sys_getdents64+0xfd/0x200<br /> [] do_syscall_64+0x95/0x1a0<br /> [] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> unreferenced object 0xffff8881044fdcf8 (size 8):<br /> comm "bash", pid 1860, jiffies 4295126592<br /> hex dump (first 8 bytes):<br /> 00 cc cc cc cc cc cc cc ........<br /> backtrace (crc 10c106a9):<br /> [] __kmalloc_node_track_caller_noprof+0x363/0x480<br /> [] kstrdup+0x36/0x60<br /> [] open_cached_dir+0x9b0/0x1fb0<br /> [] cifs_readdir+0x15a0/0x1d50<br /> [] iterate_dir+0x28f/0x4b0<br /> [] __x64_sys_getdents64+0xfd/0x200<br /> [] do_syscall_64+0x95/0x1a0<br /> [] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> And addresses these BUG splats when unmounting the SMB filesystem:<br /> <br /> BUG: Dentry ffff888140590ba0{i=1000000000080,n=/} still in use (2) [unmount of cifs cifs]<br /> WARNING: CPU: 3 PID: 3433 at fs/dcache.c:1536 umount_check+0xd0/0x100<br /> Modules linked in:<br /> CPU: 3 UID: 0 PID: 3433 Comm: bash Not tainted 6.12.0-rc4-g850925a8133c-dirty #49<br /> Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020<br /> RIP: 0010:umount_check+0xd0/0x100<br /> Code: 8d 7c 24 40 e8 31 5a f4 ff 49 8b 54 24 40 41 56 49 89 e9 45 89 e8 48 89 d9 41 57 48 89 de 48 c7 c7 80 e7 db ac e8 f0 72 9a ff 0b 58 31 c0 5a 5b 5d 41 5c 41 5d 41 5e 41 5f e9 2b e5 5d 01 41<br /> RSP: 0018:ffff88811cc27978 EFLAGS: 00010286<br /> RAX: 0000000000000000 RBX: ffff888140590ba0 RCX: ffffffffaaf20bae<br /> RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881f6fb6f40<br /> RBP: ffff8881462ec000 R08: 0000000000000001 R09: ffffed1023984ee3<br /> R10: ffff88811cc2771f R11: 00000000016cfcc0 R12: ffff888134383e08<br /> R13: 0000000000000002 R14: ffff8881462ec668 R15: ffffffffaceab4c0<br /> FS: 00007f23bfa98740(0000) GS:ffff8881f6f80000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000556de4a6f808 CR3: 0000000123c80000 CR4: 0000000000350ef0<br /> Call Trace:<br /> <br /> d_walk+0x6a/0x530<br /> shrink_dcache_for_umount+0x6a/0x200<br /> generic_shutdown_super+0x52/0x2a0<br /> kill_anon_super+0x22/0x40<br /> cifs_kill_sb+0x159/0x1e0<br /> deactivate_locked_super+0x66/0xe0<br /> cleanup_mnt+0x140/0x210<br /> task_work_run+0xfb/0x170<br /> syscall_exit_to_user_mode+0x29f/0x2b0<br /> do_syscall_64+0xa1/0x1a0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7f23bfb93ae7<br /> Code: ff ff ff ff c3 66 0f 1f 44 00 00 48 8b 0d 11 93 0d 00 f7 d8 64 89 01 b8 ff ff ff ff eb bf 0f 1f 44 00 00 b8 50 00 00 00 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d e9 92 0d 00 f7 d8 64 89 <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> um: vector: Do not use drvdata in release<br /> <br /> The drvdata is not available in release. Let&amp;#39;s just use container_of()<br /> to get the vector_device instance. Otherwise, removing a vector device<br /> will result in a crash:<br /> <br /> RIP: 0033:vector_device_release+0xf/0x50<br /> RSP: 00000000e187bc40 EFLAGS: 00010202<br /> RAX: 0000000060028f61 RBX: 00000000600f1baf RCX: 00000000620074e0<br /> RDX: 000000006220b9c0 RSI: 0000000060551c80 RDI: 0000000000000000<br /> RBP: 00000000e187bc50 R08: 00000000603ad594 R09: 00000000e187bb70<br /> R10: 000000000000135a R11: 00000000603ad422 R12: 00000000623ae028<br /> R13: 000000006287a200 R14: 0000000062006d30 R15: 00000000623700b6<br /> Kernel panic - not syncing: Segfault with no mm<br /> CPU: 0 UID: 0 PID: 16 Comm: kworker/0:1 Not tainted 6.12.0-rc6-g59b723cd2adb #1<br /> Workqueue: events mc_work_proc<br /> Stack:<br /> 60028f61 623ae028 e187bc80 60276fcd<br /> 6220b9c0 603f5820 623ae028 00000000<br /> e187bcb0 603a2bcd 623ae000 62370010<br /> Call Trace:<br /> [] ? vector_device_release+0x0/0x50<br /> [] device_release+0x70/0xba<br /> [] kobject_put+0xba/0xe7<br /> [] put_device+0x19/0x1c<br /> [] platform_device_put+0x26/0x29<br /> [] platform_device_unregister+0x2c/0x2e<br /> [] vector_remove+0x52/0x58<br /> [] ? mconsole_reply+0x0/0x50<br /> [] mconsole_remove+0x160/0x1cc<br /> [] ? strlen+0x0/0x15<br /> [] ? __dequeue_entity+0x1a9/0x206<br /> [] ? set_next_entity+0x39/0x63<br /> [] ? set_next_entity+0x0/0x63<br /> [] ? um_set_signals+0x0/0x43<br /> [] mc_work_proc+0x77/0x91<br /> [] process_scheduled_works+0x1b3/0x2dd<br /> [] ? assign_work+0x0/0x58<br /> [] worker_thread+0x1e9/0x293<br /> [] ? set_pf_worker+0x0/0x64<br /> [] ? arch_local_irq_save+0x0/0x2d<br /> [] ? kthread_exit+0x0/0x3a<br /> [] ? worker_thread+0x0/0x293<br /> [] kthread+0x126/0x12b<br /> [] new_thread_handler+0x85/0xb6

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> um: net: Do not use drvdata in release<br /> <br /> The drvdata is not available in release. Let&amp;#39;s just use container_of()<br /> to get the uml_net instance. Otherwise, removing a network device will<br /> result in a crash:<br /> <br /> RIP: 0033:net_device_release+0x10/0x6f<br /> RSP: 00000000e20c7c40 EFLAGS: 00010206<br /> RAX: 000000006002e4e7 RBX: 00000000600f1baf RCX: 00000000624074e0<br /> RDX: 0000000062778000 RSI: 0000000060551c80 RDI: 00000000627af028<br /> RBP: 00000000e20c7c50 R08: 00000000603ad594 R09: 00000000e20c7b70<br /> R10: 000000000000135a R11: 00000000603ad422 R12: 0000000000000000<br /> R13: 0000000062c7af00 R14: 0000000062406d60 R15: 00000000627700b6<br /> Kernel panic - not syncing: Segfault with no mm<br /> CPU: 0 UID: 0 PID: 29 Comm: kworker/0:2 Not tainted 6.12.0-rc6-g59b723cd2adb #1<br /> Workqueue: events mc_work_proc<br /> Stack:<br /> 627af028 62c7af00 e20c7c80 60276fcd<br /> 62778000 603f5820 627af028 00000000<br /> e20c7cb0 603a2bcd 627af000 62770010<br /> Call Trace:<br /> [] device_release+0x70/0xba<br /> [] kobject_put+0xba/0xe7<br /> [] put_device+0x19/0x1c<br /> [] platform_device_put+0x26/0x29<br /> [] platform_device_unregister+0x2c/0x2e<br /> [] net_remove+0x63/0x69<br /> [] ? mconsole_reply+0x0/0x50<br /> [] mconsole_remove+0x160/0x1cc<br /> [] ? __remove_hrtimer+0x38/0x74<br /> [] ? hrtimer_try_to_cancel+0x8c/0x98<br /> [] ? dl_server_stop+0x3f/0x48<br /> [] ? dl_server_stop+0x0/0x48<br /> [] ? dequeue_entities+0x327/0x390<br /> [] ? um_set_signals+0x0/0x43<br /> [] mc_work_proc+0x77/0x91<br /> [] process_scheduled_works+0x1b3/0x2dd<br /> [] ? assign_work+0x0/0x58<br /> [] worker_thread+0x1e9/0x293<br /> [] ? set_pf_worker+0x0/0x64<br /> [] ? arch_local_irq_save+0x0/0x2d<br /> [] ? kthread_exit+0x0/0x3a<br /> [] ? worker_thread+0x0/0x293<br /> [] kthread+0x126/0x12b<br /> [] new_thread_handler+0x85/0xb6

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> um: ubd: Do not use drvdata in release<br /> <br /> The drvdata is not available in release. Let&amp;#39;s just use container_of()<br /> to get the ubd instance. Otherwise, removing a ubd device will result<br /> in a crash:<br /> <br /> RIP: 0033:blk_mq_free_tag_set+0x1f/0xba<br /> RSP: 00000000e2083bf0 EFLAGS: 00010246<br /> RAX: 000000006021463a RBX: 0000000000000348 RCX: 0000000062604d00<br /> RDX: 0000000004208060 RSI: 00000000605241a0 RDI: 0000000000000348<br /> RBP: 00000000e2083c10 R08: 0000000062414010 R09: 00000000601603f7<br /> R10: 000000000000133a R11: 000000006038c4bd R12: 0000000000000000<br /> R13: 0000000060213a5c R14: 0000000062405d20 R15: 00000000604f7aa0<br /> Kernel panic - not syncing: Segfault with no mm<br /> CPU: 0 PID: 17 Comm: kworker/0:1 Not tainted 6.8.0-rc3-00107-gba3f67c11638 #1<br /> Workqueue: events mc_work_proc<br /> Stack:<br /> 00000000 604f7ef0 62c5d000 62405d20<br /> e2083c30 6002c776 6002c755 600e47ff<br /> e2083c60 6025ffe3 04208060 603d36e0<br /> Call Trace:<br /> [] ubd_device_release+0x21/0x55<br /> [] ? ubd_device_release+0x0/0x55<br /> [] ? kfree+0x0/0x100<br /> [] device_release+0x70/0xba<br /> [] kobject_put+0xb5/0xe2<br /> [] put_device+0x19/0x1c<br /> [] platform_device_put+0x26/0x29<br /> [] platform_device_unregister+0x2c/0x2e<br /> [] ubd_remove+0xb8/0xd6<br /> [] ? mconsole_reply+0x0/0x50<br /> [] mconsole_remove+0x160/0x1cc<br /> [] ? mconsole_reply+0x48/0x50<br /> [] ? um_set_signals+0x3b/0x43<br /> [] ? update_min_vruntime+0x14/0x70<br /> [] ? dequeue_task_fair+0x164/0x235<br /> [] ? update_cfs_group+0x0/0x40<br /> [] ? __schedule+0x0/0x3ed<br /> [] ? um_set_signals+0x0/0x43<br /> [] mc_work_proc+0x77/0x91<br /> [] process_scheduled_works+0x1af/0x2c3<br /> [] ? assign_work+0x0/0x58<br /> [] worker_thread+0x2f7/0x37a<br /> [] ? set_pf_worker+0x0/0x64<br /> [] ? arch_local_irq_save+0x0/0x2d<br /> [] ? kthread_exit+0x0/0x3a<br /> [] ? worker_thread+0x0/0x37a<br /> [] kthread+0x130/0x135<br /> [] new_thread_handler+0x85/0xb6

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "block, bfq: merge bfq_release_process_ref() into bfq_put_cooperator()"<br /> <br /> This reverts commit bc3b1e9e7c50e1de0f573eea3871db61dd4787de.<br /> <br /> The bic is associated with sync_bfqq, and bfq_release_process_ref cannot<br /> be put into bfq_put_cooperator.<br /> <br /> kasan report:<br /> [ 400.347277] ==================================================================<br /> [ 400.347287] BUG: KASAN: slab-use-after-free in bic_set_bfqq+0x200/0x230<br /> [ 400.347420] Read of size 8 at addr ffff88881cab7d60 by task dockerd/5800<br /> [ 400.347430]<br /> [ 400.347436] CPU: 24 UID: 0 PID: 5800 Comm: dockerd Kdump: loaded Tainted: G E 6.12.0 #32<br /> [ 400.347450] Tainted: [E]=UNSIGNED_MODULE<br /> [ 400.347454] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022<br /> [ 400.347460] Call Trace:<br /> [ 400.347464] <br /> [ 400.347468] dump_stack_lvl+0x5d/0x80<br /> [ 400.347490] print_report+0x174/0x505<br /> [ 400.347521] kasan_report+0xe0/0x160<br /> [ 400.347541] bic_set_bfqq+0x200/0x230<br /> [ 400.347549] bfq_bic_update_cgroup+0x419/0x740<br /> [ 400.347560] bfq_bio_merge+0x133/0x320<br /> [ 400.347584] blk_mq_submit_bio+0x1761/0x1e20<br /> [ 400.347625] __submit_bio+0x28b/0x7b0<br /> [ 400.347664] submit_bio_noacct_nocheck+0x6b2/0xd30<br /> [ 400.347690] iomap_readahead+0x50c/0x680<br /> [ 400.347731] read_pages+0x17f/0x9c0<br /> [ 400.347785] page_cache_ra_unbounded+0x366/0x4a0<br /> [ 400.347795] filemap_fault+0x83d/0x2340<br /> [ 400.347819] __xfs_filemap_fault+0x11a/0x7d0 [xfs]<br /> [ 400.349256] __do_fault+0xf1/0x610<br /> [ 400.349270] do_fault+0x977/0x11a0<br /> [ 400.349281] __handle_mm_fault+0x5d1/0x850<br /> [ 400.349314] handle_mm_fault+0x1f8/0x560<br /> [ 400.349324] do_user_addr_fault+0x324/0x970<br /> [ 400.349337] exc_page_fault+0x76/0xf0<br /> [ 400.349350] asm_exc_page_fault+0x26/0x30<br /> [ 400.349360] RIP: 0033:0x55a480d77375<br /> [ 400.349384] Code: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 49 3b 66 10 0f 86 ae 02 00 00 55 48 89 e5 48 83 ec 58 48 8b 10 7a 10 00 0f 84 27 02 00 00 44 0f b6 42 28 44 0f b6 4a 29 41 80<br /> [ 400.349392] RSP: 002b:00007f18c37fd8b8 EFLAGS: 00010216<br /> [ 400.349401] RAX: 00007f18c37fd9d0 RBX: 0000000000000000 RCX: 0000000000000000<br /> [ 400.349407] RDX: 000055a484407d38 RSI: 000000c000e8b0c0 RDI: 0000000000000000<br /> [ 400.349412] RBP: 00007f18c37fd910 R08: 000055a484017f60 R09: 000055a484066f80<br /> [ 400.349417] R10: 0000000000194000 R11: 0000000000000005 R12: 0000000000000008<br /> [ 400.349422] R13: 0000000000000000 R14: 000000c000476a80 R15: 0000000000000000<br /> [ 400.349430] <br /> [ 400.349452]<br /> [ 400.349454] Allocated by task 5800:<br /> [ 400.349459] kasan_save_stack+0x30/0x50<br /> [ 400.349469] kasan_save_track+0x14/0x30<br /> [ 400.349475] __kasan_slab_alloc+0x89/0x90<br /> [ 400.349482] kmem_cache_alloc_node_noprof+0xdc/0x2a0<br /> [ 400.349492] bfq_get_queue+0x1ef/0x1100<br /> [ 400.349502] __bfq_get_bfqq_handle_split+0x11a/0x510<br /> [ 400.349511] bfq_insert_requests+0xf55/0x9030<br /> [ 400.349519] blk_mq_flush_plug_list+0x446/0x14c0<br /> [ 400.349527] __blk_flush_plug+0x27c/0x4e0<br /> [ 400.349534] blk_finish_plug+0x52/0xa0<br /> [ 400.349540] _xfs_buf_ioapply+0x739/0xc30 [xfs]<br /> [ 400.350246] __xfs_buf_submit+0x1b2/0x640 [xfs]<br /> [ 400.350967] xfs_buf_read_map+0x306/0xa20 [xfs]<br /> [ 400.351672] xfs_trans_read_buf_map+0x285/0x7d0 [xfs]<br /> [ 400.352386] xfs_imap_to_bp+0x107/0x270 [xfs]<br /> [ 400.353077] xfs_iget+0x70d/0x1eb0 [xfs]<br /> [ 400.353786] xfs_lookup+0x2ca/0x3a0 [xfs]<br /> [ 400.354506] xfs_vn_lookup+0x14e/0x1a0 [xfs]<br /> [ 400.355197] __lookup_slow+0x19c/0x340<br /> [ 400.355204] lookup_one_unlocked+0xfc/0x120<br /> [ 400.355211] ovl_lookup_single+0x1b3/0xcf0 [overlay]<br /> [ 400.355255] ovl_lookup_layer+0x316/0x490 [overlay]<br /> [ 400.355295] ovl_lookup+0x844/0x1fd0 [overlay]<br /> [ 400.355351] lookup_one_qstr_excl+0xef/0x150<br /> [ 400.355357] do_unlinkat+0x22a/0x620<br /> [ 400.355366] __x64_sys_unlinkat+0x109/0x1e0<br /> [ 400.355375] do_syscall_64+0x82/0x160<br /> [ 400.355384] entry_SYSCALL_64_after_hwframe+0x76/0x7<br /> ---truncated---