Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> resource: fix region_intersects() vs add_memory_driver_managed()<br /> <br /> On a system with CXL memory, the resource tree (/proc/iomem) related to<br /> CXL memory may look like something as follows.<br /> <br /> 490000000-50fffffff : CXL Window 0<br /> 490000000-50fffffff : region0<br /> 490000000-50fffffff : dax0.0<br /> 490000000-50fffffff : System RAM (kmem)<br /> <br /> Because drivers/dax/kmem.c calls add_memory_driver_managed() during<br /> onlining CXL memory, which makes "System RAM (kmem)" a descendant of "CXL<br /> Window X". This confuses region_intersects(), which expects all "System<br /> RAM" resources to be at the top level of iomem_resource. This can lead to<br /> bugs.<br /> <br /> For example, when the following command line is executed to write some<br /> memory in CXL memory range via /dev/mem,<br /> <br /> $ dd if=data of=/dev/mem bs=$((1 10)) count=1<br /> dd: error writing &amp;#39;/dev/mem&amp;#39;: Bad address<br /> 1+0 records in<br /> 0+0 records out<br /> 0 bytes copied, 0.0283507 s, 0.0 kB/s<br /> <br /> the command fails as expected. However, the error code is wrong. It<br /> should be "Operation not permitted" instead of "Bad address". More<br /> seriously, the /dev/mem permission checking in devmem_is_allowed() passes<br /> incorrectly. Although the accessing is prevented later because ioremap()<br /> isn&amp;#39;t allowed to map system RAM, it is a potential security issue. During<br /> command executing, the following warning is reported in the kernel log for<br /> calling ioremap() on system RAM.<br /> <br /> ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff<br /> WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d<br /> Call Trace:<br /> memremap+0xcb/0x184<br /> xlate_dev_mem_ptr+0x25/0x2f<br /> write_mem+0x94/0xfb<br /> vfs_write+0x128/0x26d<br /> ksys_write+0xac/0xfe<br /> do_syscall_64+0x9a/0xfd<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> The details of command execution process are as follows. In the above<br /> resource tree, "System RAM" is a descendant of "CXL Window 0" instead of a<br /> top level resource. So, region_intersects() will report no System RAM<br /> resources in the CXL memory region incorrectly, because it only checks the<br /> top level resources. Consequently, devmem_is_allowed() will return 1<br /> (allow access via /dev/mem) for CXL memory region incorrectly. <br /> Fortunately, ioremap() doesn&amp;#39;t allow to map System RAM and reject the<br /> access.<br /> <br /> So, region_intersects() needs to be fixed to work correctly with the<br /> resource tree with "System RAM" not at top level as above. To fix it, if<br /> we found a unmatched resource in the top level, we will continue to search<br /> matched resources in its descendant resources. So, we will not miss any<br /> matched resources in resource tree anymore.<br /> <br /> In the new implementation, an example resource tree<br /> <br /> |------------- "CXL Window 0" ------------|<br /> |-- "System RAM" --|<br /> <br /> will behave similar as the following fake resource tree for<br /> region_intersects(, IORESOURCE_SYSTEM_RAM, ),<br /> <br /> |-- "System RAM" --||-- "CXL Window 0a" --|<br /> <br /> Where "CXL Window 0a" is part of the original "CXL Window 0" that<br /> isn&amp;#39;t covered by "System RAM".

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: send: fix buffer overflow detection when copying path to cache entry<br /> <br /> Starting with commit c0247d289e73 ("btrfs: send: annotate struct<br /> name_cache_entry with __counted_by()") we annotated the variable length<br /> array "name" from the name_cache_entry structure with __counted_by() to<br /> improve overflow detection. However that alone was not correct, because<br /> the length of that array does not match the "name_len" field - it matches<br /> that plus 1 to include the NUL string terminator, so that makes a<br /> fortified kernel think there&amp;#39;s an overflow and report a splat like this:<br /> <br /> strcpy: detected buffer overflow: 20 byte write of buffer size 19<br /> WARNING: CPU: 3 PID: 3310 at __fortify_report+0x45/0x50<br /> CPU: 3 UID: 0 PID: 3310 Comm: btrfs Not tainted 6.11.0-prnet #1<br /> Hardware name: CompuLab Ltd. sbc-ihsw/Intense-PC2 (IPC2), BIOS IPC2_3.330.7 X64 03/15/2018<br /> RIP: 0010:__fortify_report+0x45/0x50<br /> Code: 48 8b 34 (...)<br /> RSP: 0018:ffff97ebc0d6f650 EFLAGS: 00010246<br /> RAX: 7749924ef60fa600 RBX: ffff8bf5446a521a RCX: 0000000000000027<br /> RDX: 00000000ffffdfff RSI: ffff97ebc0d6f548 RDI: ffff8bf84e7a1cc8<br /> RBP: ffff8bf548574080 R08: ffffffffa8c40e10 R09: 0000000000005ffd<br /> R10: 0000000000000004 R11: ffffffffa8c70e10 R12: ffff8bf551eef400<br /> R13: 0000000000000000 R14: 0000000000000013 R15: 00000000000003a8<br /> FS: 00007fae144de8c0(0000) GS:ffff8bf84e780000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fae14691690 CR3: 00000001027a2003 CR4: 00000000001706f0<br /> Call Trace:<br /> <br /> ? __warn+0x12a/0x1d0<br /> ? __fortify_report+0x45/0x50<br /> ? report_bug+0x154/0x1c0<br /> ? handle_bug+0x42/0x70<br /> ? exc_invalid_op+0x1a/0x50<br /> ? asm_exc_invalid_op+0x1a/0x20<br /> ? __fortify_report+0x45/0x50<br /> __fortify_panic+0x9/0x10<br /> __get_cur_name_and_parent+0x3bc/0x3c0<br /> get_cur_path+0x207/0x3b0<br /> send_extent_data+0x709/0x10d0<br /> ? find_parent_nodes+0x22df/0x25d0<br /> ? mas_nomem+0x13/0x90<br /> ? mtree_insert_range+0xa5/0x110<br /> ? btrfs_lru_cache_store+0x5f/0x1e0<br /> ? iterate_extent_inodes+0x52d/0x5a0<br /> process_extent+0xa96/0x11a0<br /> ? __pfx_lookup_backref_cache+0x10/0x10<br /> ? __pfx_store_backref_cache+0x10/0x10<br /> ? __pfx_iterate_backrefs+0x10/0x10<br /> ? __pfx_check_extent_item+0x10/0x10<br /> changed_cb+0x6fa/0x930<br /> ? tree_advance+0x362/0x390<br /> ? memcmp_extent_buffer+0xd7/0x160<br /> send_subvol+0xf0a/0x1520<br /> btrfs_ioctl_send+0x106b/0x11d0<br /> ? __pfx___clone_root_cmp_sort+0x10/0x10<br /> _btrfs_ioctl_send+0x1ac/0x240<br /> btrfs_ioctl+0x75b/0x850<br /> __se_sys_ioctl+0xca/0x150<br /> do_syscall_64+0x85/0x160<br /> ? __count_memcg_events+0x69/0x100<br /> ? handle_mm_fault+0x1327/0x15c0<br /> ? __se_sys_rt_sigprocmask+0xf1/0x180<br /> ? syscall_exit_to_user_mode+0x75/0xa0<br /> ? do_syscall_64+0x91/0x160<br /> ? do_user_addr_fault+0x21d/0x630<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7fae145eeb4f<br /> Code: 00 48 89 (...)<br /> RSP: 002b:00007ffdf1cb09b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fae145eeb4f<br /> RDX: 00007ffdf1cb0ad0 RSI: 0000000040489426 RDI: 0000000000000004<br /> RBP: 00000000000078fe R08: 00007fae144006c0 R09: 00007ffdf1cb0927<br /> R10: 0000000000000008 R11: 0000000000000246 R12: 00007ffdf1cb1ce8<br /> R13: 0000000000000003 R14: 000055c499fab2e0 R15: 0000000000000004<br /> <br /> <br /> Fix this by not storing the NUL string terminator since we don&amp;#39;t actually<br /> need it for name cache entries, this way "name_len" corresponds to the<br /> actual size of the "name" array. This requires marking the "name" array<br /> field with __nonstring and using memcpy() instead of strcpy() as<br /> recommended by the guidelines at:<br /> <br /> https://github.com/KSPP/linux/issues/90

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/gup: fix memfd_pin_folios alloc race panic<br /> <br /> If memfd_pin_folios tries to create a hugetlb page, but someone else<br /> already did, then folio gets the value -EEXIST here:<br /> <br /> folio = memfd_alloc_folio(memfd, start_idx);<br /> if (IS_ERR(folio)) {<br /> ret = PTR_ERR(folio);<br /> if (ret != -EEXIST)<br /> goto err;<br /> <br /> then on the next trip through the "while start_idx" loop we panic here:<br /> <br /> if (folio) {<br /> folio_put(folio);<br /> <br /> To fix, set the folio to NULL on error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/filemap: fix filemap_get_folios_contig THP panic<br /> <br /> Patch series "memfd-pin huge page fixes".<br /> <br /> Fix multiple bugs that occur when using memfd_pin_folios with hugetlb<br /> pages and THP. The hugetlb bugs only bite when the page is not yet<br /> faulted in when memfd_pin_folios is called. The THP bug bites when the<br /> starting offset passed to memfd_pin_folios is not huge page aligned. See<br /> the commit messages for details.<br /> <br /> <br /> This patch (of 5):<br /> <br /> memfd_pin_folios on memory backed by THP panics if the requested start<br /> offset is not huge page aligned:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000036<br /> RIP: 0010:filemap_get_folios_contig+0xdf/0x290<br /> RSP: 0018:ffffc9002092fbe8 EFLAGS: 00010202<br /> RAX: 0000000000000002 RBX: 0000000000000002 RCX: 0000000000000002<br /> <br /> The fault occurs here, because xas_load returns a folio with value 2:<br /> <br /> filemap_get_folios_contig()<br /> for (folio = xas_load(&amp;xas); folio &amp;&amp; xas.xa_index

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i3c: master: svc: Fix use after free vulnerability in svc_i3c_master Driver Due to Race Condition<br /> <br /> In the svc_i3c_master_probe function, &amp;master-&gt;hj_work is bound with<br /> svc_i3c_master_hj_work, &amp;master-&gt;ibi_work is bound with<br /> svc_i3c_master_ibi_work. And svc_i3c_master_ibi_work can start the<br /> hj_work, svc_i3c_master_irq_handler can start the ibi_work.<br /> <br /> If we remove the module which will call svc_i3c_master_remove to<br /> make cleanup, it will free master-&gt;base through i3c_master_unregister<br /> while the work mentioned above will be used. The sequence of operations<br /> that may lead to a UAF bug is as follows:<br /> <br /> CPU0 CPU1<br /> <br /> | svc_i3c_master_hj_work<br /> svc_i3c_master_remove |<br /> i3c_master_unregister(&amp;master-&gt;base)|<br /> device_unregister(&amp;master-&gt;dev) |<br /> device_release |<br /> //free master-&gt;base |<br /> | i3c_master_do_daa(&amp;master-&gt;base)<br /> | //use master-&gt;base<br /> <br /> Fix it by ensuring that the work is canceled before proceeding with the<br /> cleanup in svc_i3c_master_remove.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cachefiles: fix dentry leak in cachefiles_open_file()<br /> <br /> A dentry leak may be caused when a lookup cookie and a cull are concurrent:<br /> <br /> P1 | P2<br /> -----------------------------------------------------------<br /> cachefiles_lookup_cookie<br /> cachefiles_look_up_object<br /> lookup_one_positive_unlocked<br /> // get dentry<br /> cachefiles_cull<br /> inode-&gt;i_flags |= S_KERNEL_FILE;<br /> cachefiles_open_file<br /> cachefiles_mark_inode_in_use<br /> __cachefiles_mark_inode_in_use<br /> can_use = false<br /> if (!(inode-&gt;i_flags &amp; S_KERNEL_FILE))<br /> can_use = true<br /> return false<br /> return false<br /> // Returns an error but doesn&amp;#39;t put dentry<br /> <br /> After that the following WARNING will be triggered when the backend folder<br /> is umounted:<br /> <br /> ==================================================================<br /> BUG: Dentry 000000008ad87947{i=7a,n=Dx_1_1.img} still in use (1) [unmount of ext4 sda]<br /> WARNING: CPU: 4 PID: 359261 at fs/dcache.c:1767 umount_check+0x5d/0x70<br /> CPU: 4 PID: 359261 Comm: umount Not tainted 6.6.0-dirty #25<br /> RIP: 0010:umount_check+0x5d/0x70<br /> Call Trace:<br /> <br /> d_walk+0xda/0x2b0<br /> do_one_tree+0x20/0x40<br /> shrink_dcache_for_umount+0x2c/0x90<br /> generic_shutdown_super+0x20/0x160<br /> kill_block_super+0x1a/0x40<br /> ext4_kill_sb+0x22/0x40<br /> deactivate_locked_super+0x35/0x80<br /> cleanup_mnt+0x104/0x160<br /> ==================================================================<br /> <br /> Whether cachefiles_open_file() returns true or false, the reference count<br /> obtained by lookup_positive_unlocked() in cachefiles_look_up_object()<br /> should be released.<br /> <br /> Therefore release that reference count in cachefiles_look_up_object() to<br /> fix the above issue and simplify the code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: adp5589-keys - fix NULL pointer dereference<br /> <br /> We register a devm action to call adp5589_clear_config() and then pass<br /> the i2c client as argument so that we can call i2c_get_clientdata() in<br /> order to get our device object. However, i2c_set_clientdata() is only<br /> being set at the end of the probe function which means that we&amp;#39;ll get a<br /> NULL pointer dereference in case the probe function fails early.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix a race between socket set up and I/O thread creation<br /> <br /> In rxrpc_open_socket(), it sets up the socket and then sets up the I/O<br /> thread that will handle it. This is a problem, however, as there&amp;#39;s a gap<br /> between the two phases in which a packet may come into rxrpc_encap_rcv()<br /> from the UDP packet but we oops when trying to wake the not-yet created I/O<br /> thread.<br /> <br /> As a quick fix, just make rxrpc_encap_rcv() discard the packet if there&amp;#39;s<br /> no I/O thread yet.<br /> <br /> A better, but more intrusive fix would perhaps be to rearrange things such<br /> that the socket creation is done by the I/O thread.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/vm: move xa_alloc to prevent UAF<br /> <br /> Evil user can guess the next id of the vm before the ioctl completes and<br /> then call vm destroy ioctl to trigger UAF since create ioctl is still<br /> referencing the same vm. Move the xa_alloc all the way to the end to<br /> prevent this.<br /> <br /> v2:<br /> - Rebase<br /> <br /> (cherry picked from commit dcfd3971327f3ee92765154baebbaece833d3ca9)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: wait for fixup workers before stopping cleaner kthread during umount<br /> <br /> During unmount, at close_ctree(), we have the following steps in this order:<br /> <br /> 1) Park the cleaner kthread - this doesn&amp;#39;t destroy the kthread, it basically<br /> halts its execution (wake ups against it work but do nothing);<br /> <br /> 2) We stop the cleaner kthread - this results in freeing the respective<br /> struct task_struct;<br /> <br /> 3) We call btrfs_stop_all_workers() which waits for any jobs running in all<br /> the work queues and then free the work queues.<br /> <br /> Syzbot reported a case where a fixup worker resulted in a crash when doing<br /> a delayed iput on its inode while attempting to wake up the cleaner at<br /> btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread<br /> was already freed. This can happen during unmount because we don&amp;#39;t wait<br /> for any fixup workers still running before we call kthread_stop() against<br /> the cleaner kthread, which stops and free all its resources.<br /> <br /> Fix this by waiting for any fixup workers at close_ctree() before we call<br /> kthread_stop() against the cleaner and run pending delayed iputs.<br /> <br /> The stack traces reported by syzbot were the following:<br /> <br /> BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065<br /> Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52<br /> <br /> CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024<br /> Workqueue: btrfs-fixup btrfs_work_helper<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:377 [inline]<br /> print_report+0x169/0x550 mm/kasan/report.c:488<br /> kasan_report+0x143/0x180 mm/kasan/report.c:601<br /> __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065<br /> lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825<br /> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]<br /> _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162<br /> class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline]<br /> try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154<br /> btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842<br /> btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314<br /> process_one_work kernel/workqueue.c:3229 [inline]<br /> process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310<br /> worker_thread+0x870/0xd30 kernel/workqueue.c:3391<br /> kthread+0x2f0/0x390 kernel/kthread.c:389<br /> ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244<br /> <br /> <br /> Allocated by task 2:<br /> kasan_save_stack mm/kasan/common.c:47 [inline]<br /> kasan_save_track+0x3f/0x80 mm/kasan/common.c:68<br /> unpoison_slab_object mm/kasan/common.c:319 [inline]<br /> __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345<br /> kasan_slab_alloc include/linux/kasan.h:247 [inline]<br /> slab_post_alloc_hook mm/slub.c:4086 [inline]<br /> slab_alloc_node mm/slub.c:4135 [inline]<br /> kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187<br /> alloc_task_struct_node kernel/fork.c:180 [inline]<br /> dup_task_struct+0x57/0x8c0 kernel/fork.c:1107<br /> copy_process+0x5d1/0x3d50 kernel/fork.c:2206<br /> kernel_clone+0x223/0x880 kernel/fork.c:2787<br /> kernel_thread+0x1bc/0x240 kernel/fork.c:2849<br /> create_kthread kernel/kthread.c:412 [inline]<br /> kthreadd+0x60d/0x810 kernel/kthread.c:765<br /> ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244<br /> <br /> Freed by task 61:<br /> kasan_save_stack mm/kasan/common.c:47 [inline]<br /> kasan_save_track+0x3f/0x80 mm/kasan/common.c:68<br /> kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579<br /> poison_slab_object mm/kasan/common.c:247 [inline]<br /> __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264<br /> kasan_slab_free include/linux/kasan.h:230 [inline]<br /> slab_free_h<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vhost/scsi: null-ptr-dereference in vhost_scsi_get_req()<br /> <br /> Since commit 3f8ca2e115e5 ("vhost/scsi: Extract common handling code<br /> from control queue handler") a null pointer dereference bug can be<br /> triggered when guest sends an SCSI AN request.<br /> <br /> In vhost_scsi_ctl_handle_vq(), `vc.target` is assigned with<br /> `&amp;v_req.tmf.lun[1]` within a switch-case block and is then passed to<br /> vhost_scsi_get_req() which extracts `vc-&gt;req` and `tpg`. However, for<br /> a `VIRTIO_SCSI_T_AN_*` request, tpg is not required, so `vc.target` is<br /> set to NULL in this branch. Later, in vhost_scsi_get_req(),<br /> `vc-&gt;target` is dereferenced without being checked, leading to a null<br /> pointer dereference bug. This bug can be triggered from guest.<br /> <br /> When this bug occurs, the vhost_worker process is killed while holding<br /> `vq-&gt;mutex` and the corresponding tpg will remain occupied<br /> indefinitely.<br /> <br /> Below is the KASAN report:<br /> Oops: general protection fault, probably for non-canonical address<br /> 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1<br /> Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS<br /> 1.16.3-debian-1.16.3-2 04/01/2014<br /> RIP: 0010:vhost_scsi_get_req+0x165/0x3a0<br /> Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 00<br /> 48 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 b6<br /> 04 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00<br /> RSP: 0018:ffff888017affb50 EFLAGS: 00010246<br /> RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8<br /> RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000<br /> R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000<br /> FS: 000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0<br /> Call Trace:<br /> <br /> ? show_regs+0x86/0xa0<br /> ? die_addr+0x4b/0xd0<br /> ? exc_general_protection+0x163/0x260<br /> ? asm_exc_general_protection+0x27/0x30<br /> ? vhost_scsi_get_req+0x165/0x3a0<br /> vhost_scsi_ctl_handle_vq+0x2a4/0xca0<br /> ? __pfx_vhost_scsi_ctl_handle_vq+0x10/0x10<br /> ? __switch_to+0x721/0xeb0<br /> ? __schedule+0xda5/0x5710<br /> ? __kasan_check_write+0x14/0x30<br /> ? _raw_spin_lock+0x82/0xf0<br /> vhost_scsi_ctl_handle_kick+0x52/0x90<br /> vhost_run_work_list+0x134/0x1b0<br /> vhost_task_fn+0x121/0x350<br /> ...<br /> <br /> ---[ end trace 0000000000000000 ]---<br /> <br /> Let&amp;#39;s add a check in vhost_scsi_get_req.<br /> <br /> [whitespace fixes]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing/timerlat: Fix a race during cpuhp processing<br /> <br /> There is another found exception that the "timerlat/1" thread was<br /> scheduled on CPU0, and lead to timer corruption finally:<br /> <br /> ```<br /> ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220<br /> WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014<br /> RIP: 0010:debug_print_object+0x7d/0xb0<br /> ...<br /> Call Trace:<br /> <br /> ? __warn+0x7c/0x110<br /> ? debug_print_object+0x7d/0xb0<br /> ? report_bug+0xf1/0x1d0<br /> ? prb_read_valid+0x17/0x20<br /> ? handle_bug+0x3f/0x70<br /> ? exc_invalid_op+0x13/0x60<br /> ? asm_exc_invalid_op+0x16/0x20<br /> ? debug_print_object+0x7d/0xb0<br /> ? debug_print_object+0x7d/0xb0<br /> ? __pfx_timerlat_irq+0x10/0x10<br /> __debug_object_init+0x110/0x150<br /> hrtimer_init+0x1d/0x60<br /> timerlat_main+0xab/0x2d0<br /> ? __pfx_timerlat_main+0x10/0x10<br /> kthread+0xb7/0xe0<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x2d/0x40<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> ```<br /> <br /> After tracing the scheduling event, it was discovered that the migration<br /> of the "timerlat/1" thread was performed during thread creation. Further<br /> analysis confirmed that it is because the CPU online processing for<br /> osnoise is implemented through workers, which is asynchronous with the<br /> offline processing. When the worker was scheduled to create a thread, the<br /> CPU may has already been removed from the cpu_online_mask during the offline<br /> process, resulting in the inability to select the right CPU:<br /> <br /> T1 | T2<br /> [CPUHP_ONLINE] | cpu_device_down()<br /> osnoise_hotplug_workfn() |<br /> | cpus_write_lock()<br /> | takedown_cpu(1)<br /> | cpus_write_unlock()<br /> [CPUHP_OFFLINE] |<br /> cpus_read_lock() |<br /> start_kthread(1) |<br /> cpus_read_unlock() |<br /> <br /> To fix this, skip online processing if the CPU is already offline.