Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context<br /> <br /> PRMT needs to find the correct type of block to translate the PA-VA<br /> mapping for EFI runtime services.<br /> <br /> The issue arises because the PRMT is finding a block of type<br /> EFI_CONVENTIONAL_MEMORY, which is not appropriate for runtime services<br /> as described in Section 2.2.2 (Runtime Services) of the UEFI<br /> Specification [1]. Since the PRM handler is a type of runtime service,<br /> this causes an exception when the PRM handler is called.<br /> <br /> [Firmware Bug]: Unable to handle paging request in EFI runtime service<br /> WARNING: CPU: 22 PID: 4330 at drivers/firmware/efi/runtime-wrappers.c:341<br /> __efi_queue_work+0x11c/0x170<br /> Call trace:<br /> <br /> Let PRMT find a block with EFI_MEMORY_RUNTIME for PRM handler and PRM<br /> context.<br /> <br /> If no suitable block is found, a warning message will be printed, but<br /> the procedure continues to manage the next PRM handler.<br /> <br /> However, if the PRM handler is actually called without proper allocation,<br /> it would result in a failure during error handling.<br /> <br /> By using the correct memory types for runtime services, ensure that the<br /> PRM handler and the context are properly mapped in the virtual address<br /> space during runtime, preventing the paging request error.<br /> <br /> The issue is really that only memory that has been remapped for runtime<br /> by the firmware can be used by the PRM handler, and so the region needs<br /> to have the EFI_MEMORY_RUNTIME attribute.<br /> <br /> [ rjw: Subject and changelog edits ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: validate new SA&amp;#39;s prefixlen using SA family when sel.family is unset<br /> <br /> This expands the validation introduced in commit 07bf7908950a ("xfrm:<br /> Validate address prefix lengths in the xfrm selector.")<br /> <br /> syzbot created an SA with<br /> usersa.sel.family = AF_UNSPEC<br /> usersa.sel.prefixlen_s = 128<br /> usersa.family = AF_INET<br /> <br /> Because of the AF_UNSPEC selector, verify_newsa_info doesn&amp;#39;t put<br /> limits on prefixlen_{s,d}. But then copy_from_user_state sets<br /> x-&gt;sel.family to usersa.family (AF_INET). Do the same conversion in<br /> verify_newsa_info before validating prefixlen_{s,d}, since that&amp;#39;s how<br /> prefixlen is going to be used later on.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udf: fix uninit-value use in udf_get_fileshortad<br /> <br /> Check for overflow when computing alen in udf_current_aext to mitigate<br /> later uninit-value use in udf_get_fileshortad KMSAN bug[1].<br /> After applying the patch reproducer did not trigger any issue[2].<br /> <br /> [1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df<br /> [2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeon_ep: Add SKB allocation failures handling in __octep_oq_process_rx()<br /> <br /> build_skb() returns NULL in case of a memory allocation failure so handle<br /> it inside __octep_oq_process_rx() to avoid NULL pointer dereference.<br /> <br /> __octep_oq_process_rx() is called during NAPI polling by the driver. If<br /> skb allocation fails, keep on pulling packets out of the Rx DMA queue: we<br /> shouldn&amp;#39;t break the polling immediately and thus falsely indicate to the<br /> octep_napi_poll() that the Rx pressure is going down. As there is no<br /> associated skb in this case, don&amp;#39;t process the packets and don&amp;#39;t push them<br /> up the network stack - they are skipped.<br /> <br /> Helper function is implemented to unmmap/flush all the fragment buffers<br /> used by the dropped packet. &amp;#39;alloc_failures&amp;#39; counter is incremented to<br /> mark the skb allocation error in driver statistics.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Fix command bitmask initialization<br /> <br /> Command bitmask have a dedicated bit for MANAGE_PAGES command, this bit<br /> isn&amp;#39;t Initialize during command bitmask Initialization, only during<br /> MANAGE_PAGES.<br /> <br /> In addition, mlx5_cmd_trigger_completions() is trying to trigger<br /> completion for MANAGE_PAGES command as well.<br /> <br /> Hence, in case health error occurred before any MANAGE_PAGES command<br /> have been invoke (for example, during mlx5_enable_hca()),<br /> mlx5_cmd_trigger_completions() will try to trigger completion for<br /> MANAGE_PAGES command, which will result in null-ptr-deref error.[1]<br /> <br /> Fix it by Initialize command bitmask correctly.<br /> <br /> While at it, re-write the code for better understanding.<br /> <br /> [1]<br /> BUG: KASAN: null-ptr-deref in mlx5_cmd_trigger_completions+0x1db/0x600 [mlx5_core]<br /> Write of size 4 at addr 0000000000000214 by task kworker/u96:2/12078<br /> CPU: 10 PID: 12078 Comm: kworker/u96:2 Not tainted 6.9.0-rc2_for_upstream_debug_2024_04_07_19_01 #1<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> Workqueue: mlx5_health0000:08:00.0 mlx5_fw_fatal_reporter_err_work [mlx5_core]<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x7e/0xc0<br /> kasan_report+0xb9/0xf0<br /> kasan_check_range+0xec/0x190<br /> mlx5_cmd_trigger_completions+0x1db/0x600 [mlx5_core]<br /> mlx5_cmd_flush+0x94/0x240 [mlx5_core]<br /> enter_error_state+0x6c/0xd0 [mlx5_core]<br /> mlx5_fw_fatal_reporter_err_work+0xf3/0x480 [mlx5_core]<br /> process_one_work+0x787/0x1490<br /> ? lockdep_hardirqs_on_prepare+0x400/0x400<br /> ? pwq_dec_nr_in_flight+0xda0/0xda0<br /> ? assign_work+0x168/0x240<br /> worker_thread+0x586/0xd30<br /> ? rescuer_thread+0xae0/0xae0<br /> kthread+0x2df/0x3b0<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork+0x2d/0x70<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork_asm+0x11/0x20<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: bnep: fix wild-memory-access in proto_unregister<br /> <br /> There&amp;#39;s issue as follows:<br /> KASAN: maybe wild-memory-access in range [0xdead...108-0xdead...10f]<br /> CPU: 3 UID: 0 PID: 2805 Comm: rmmod Tainted: G W<br /> RIP: 0010:proto_unregister+0xee/0x400<br /> Call Trace:<br /> <br /> __do_sys_delete_module+0x318/0x580<br /> do_syscall_64+0xc1/0x1d0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> As bnep_init() ignore bnep_sock_init()&amp;#39;s return value, and bnep_sock_init()<br /> will cleanup all resource. Then when remove bnep module will call<br /> bnep_sock_cleanup() to cleanup sock&amp;#39;s resource.<br /> To solve above issue just return bnep_sock_init()&amp;#39;s return value in<br /> bnep_exit().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: altmode should keep reference to parent<br /> <br /> The altmode device release refers to its parent device, but without keeping<br /> a reference to it.<br /> <br /> When registering the altmode, get a reference to the parent and put it in<br /> the release function.<br /> <br /> Before this fix, when using CONFIG_DEBUG_KOBJECT_RELEASE, we see issues<br /> like this:<br /> <br /> [ 43.572860] kobject: &amp;#39;port0.0&amp;#39; (ffff8880057ba008): kobject_release, parent 0000000000000000 (delayed 3000)<br /> [ 43.573532] kobject: &amp;#39;port0.1&amp;#39; (ffff8880057bd008): kobject_release, parent 0000000000000000 (delayed 1000)<br /> [ 43.574407] kobject: &amp;#39;port0&amp;#39; (ffff8880057b9008): kobject_release, parent 0000000000000000 (delayed 3000)<br /> [ 43.575059] kobject: &amp;#39;port1.0&amp;#39; (ffff8880057ca008): kobject_release, parent 0000000000000000 (delayed 4000)<br /> [ 43.575908] kobject: &amp;#39;port1.1&amp;#39; (ffff8880057c9008): kobject_release, parent 0000000000000000 (delayed 4000)<br /> [ 43.576908] kobject: &amp;#39;typec&amp;#39; (ffff8880062dbc00): kobject_release, parent 0000000000000000 (delayed 4000)<br /> [ 43.577769] kobject: &amp;#39;port1&amp;#39; (ffff8880057bf008): kobject_release, parent 0000000000000000 (delayed 3000)<br /> [ 46.612867] ==================================================================<br /> [ 46.613402] BUG: KASAN: slab-use-after-free in typec_altmode_release+0x38/0x129<br /> [ 46.614003] Read of size 8 at addr ffff8880057b9118 by task kworker/2:1/48<br /> [ 46.614538]<br /> [ 46.614668] CPU: 2 UID: 0 PID: 48 Comm: kworker/2:1 Not tainted 6.12.0-rc1-00138-gedbae730ad31 #535<br /> [ 46.615391] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014<br /> [ 46.616042] Workqueue: events kobject_delayed_cleanup<br /> [ 46.616446] Call Trace:<br /> [ 46.616648] <br /> [ 46.616820] dump_stack_lvl+0x5b/0x7c<br /> [ 46.617112] ? typec_altmode_release+0x38/0x129<br /> [ 46.617470] print_report+0x14c/0x49e<br /> [ 46.617769] ? rcu_read_unlock_sched+0x56/0x69<br /> [ 46.618117] ? __virt_addr_valid+0x19a/0x1ab<br /> [ 46.618456] ? kmem_cache_debug_flags+0xc/0x1d<br /> [ 46.618807] ? typec_altmode_release+0x38/0x129<br /> [ 46.619161] kasan_report+0x8d/0xb4<br /> [ 46.619447] ? typec_altmode_release+0x38/0x129<br /> [ 46.619809] ? process_scheduled_works+0x3cb/0x85f<br /> [ 46.620185] typec_altmode_release+0x38/0x129<br /> [ 46.620537] ? process_scheduled_works+0x3cb/0x85f<br /> [ 46.620907] device_release+0xaf/0xf2<br /> [ 46.621206] kobject_delayed_cleanup+0x13b/0x17a<br /> [ 46.621584] process_scheduled_works+0x4f6/0x85f<br /> [ 46.621955] ? __pfx_process_scheduled_works+0x10/0x10<br /> [ 46.622353] ? hlock_class+0x31/0x9a<br /> [ 46.622647] ? lock_acquired+0x361/0x3c3<br /> [ 46.622956] ? move_linked_works+0x46/0x7d<br /> [ 46.623277] worker_thread+0x1ce/0x291<br /> [ 46.623582] ? __kthread_parkme+0xc8/0xdf<br /> [ 46.623900] ? __pfx_worker_thread+0x10/0x10<br /> [ 46.624236] kthread+0x17e/0x190<br /> [ 46.624501] ? kthread+0xfb/0x190<br /> [ 46.624756] ? __pfx_kthread+0x10/0x10<br /> [ 46.625015] ret_from_fork+0x20/0x40<br /> [ 46.625268] ? __pfx_kthread+0x10/0x10<br /> [ 46.625532] ret_from_fork_asm+0x1a/0x30<br /> [ 46.625805] <br /> [ 46.625953]<br /> [ 46.626056] Allocated by task 678:<br /> [ 46.626287] kasan_save_stack+0x24/0x44<br /> [ 46.626555] kasan_save_track+0x14/0x2d<br /> [ 46.626811] __kasan_kmalloc+0x3f/0x4d<br /> [ 46.627049] __kmalloc_noprof+0x1bf/0x1f0<br /> [ 46.627362] typec_register_port+0x23/0x491<br /> [ 46.627698] cros_typec_probe+0x634/0xbb6<br /> [ 46.628026] platform_probe+0x47/0x8c<br /> [ 46.628311] really_probe+0x20a/0x47d<br /> [ 46.628605] device_driver_attach+0x39/0x72<br /> [ 46.628940] bind_store+0x87/0xd7<br /> [ 46.629213] kernfs_fop_write_iter+0x1aa/0x218<br /> [ 46.629574] vfs_write+0x1d6/0x29b<br /> [ 46.629856] ksys_write+0xcd/0x13b<br /> [ 46.630128] do_syscall_64+0xd4/0x139<br /> [ 46.630420] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [ 46.630820]<br /> [ 46.630946] Freed by task 48:<br /> [ 46.631182] kasan_save_stack+0x24/0x44<br /> [ 46.631493] kasan_save_track+0x14/0x2d<br /> [ 46.631799] kasan_save_free_info+0x3f/0x4d<br /> [ 46.632144] __kasan_slab_free+0x37/0x45<br /> [ 46.632474]<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix OOBs when building SMB2_IOCTL request<br /> <br /> When using encryption, either enforced by the server or when using<br /> &amp;#39;seal&amp;#39; mount option, the client will squash all compound request buffers<br /> down for encryption into a single iov in smb2_set_next_command().<br /> <br /> SMB2_ioctl_init() allocates a small buffer (448 bytes) to hold the<br /> SMB2_IOCTL request in the first iov, and if the user passes an input<br /> buffer that is greater than 328 bytes, smb2_set_next_command() will<br /> end up writing off the end of @rqst-&gt;iov[0].iov_base as shown below:<br /> <br /> mount.cifs //srv/share /mnt -o ...,seal<br /> ln -s $(perl -e "print(&amp;#39;a&amp;#39;)for 1..1024") /mnt/link<br /> <br /> BUG: KASAN: slab-out-of-bounds in<br /> smb2_set_next_command.cold+0x1d6/0x24c [cifs]<br /> Write of size 4116 at addr ffff8881148fcab8 by task ln/859<br /> <br /> CPU: 1 UID: 0 PID: 859 Comm: ln Not tainted 6.12.0-rc3 #1<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS<br /> 1.16.3-2.fc40 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x5d/0x80<br /> ? smb2_set_next_command.cold+0x1d6/0x24c [cifs]<br /> print_report+0x156/0x4d9<br /> ? smb2_set_next_command.cold+0x1d6/0x24c [cifs]<br /> ? __virt_addr_valid+0x145/0x310<br /> ? __phys_addr+0x46/0x90<br /> ? smb2_set_next_command.cold+0x1d6/0x24c [cifs]<br /> kasan_report+0xda/0x110<br /> ? smb2_set_next_command.cold+0x1d6/0x24c [cifs]<br /> kasan_check_range+0x10f/0x1f0<br /> __asan_memcpy+0x3c/0x60<br /> smb2_set_next_command.cold+0x1d6/0x24c [cifs]<br /> smb2_compound_op+0x238c/0x3840 [cifs]<br /> ? kasan_save_track+0x14/0x30<br /> ? kasan_save_free_info+0x3b/0x70<br /> ? vfs_symlink+0x1a1/0x2c0<br /> ? do_symlinkat+0x108/0x1c0<br /> ? __pfx_smb2_compound_op+0x10/0x10 [cifs]<br /> ? kmem_cache_free+0x118/0x3e0<br /> ? cifs_get_writable_path+0xeb/0x1a0 [cifs]<br /> smb2_get_reparse_inode+0x423/0x540 [cifs]<br /> ? __pfx_smb2_get_reparse_inode+0x10/0x10 [cifs]<br /> ? rcu_is_watching+0x20/0x50<br /> ? __kmalloc_noprof+0x37c/0x480<br /> ? smb2_create_reparse_symlink+0x257/0x490 [cifs]<br /> ? smb2_create_reparse_symlink+0x38f/0x490 [cifs]<br /> smb2_create_reparse_symlink+0x38f/0x490 [cifs]<br /> ? __pfx_smb2_create_reparse_symlink+0x10/0x10 [cifs]<br /> ? find_held_lock+0x8a/0xa0<br /> ? hlock_class+0x32/0xb0<br /> ? __build_path_from_dentry_optional_prefix+0x19d/0x2e0 [cifs]<br /> cifs_symlink+0x24f/0x960 [cifs]<br /> ? __pfx_make_vfsuid+0x10/0x10<br /> ? __pfx_cifs_symlink+0x10/0x10 [cifs]<br /> ? make_vfsgid+0x6b/0xc0<br /> ? generic_permission+0x96/0x2d0<br /> vfs_symlink+0x1a1/0x2c0<br /> do_symlinkat+0x108/0x1c0<br /> ? __pfx_do_symlinkat+0x10/0x10<br /> ? strncpy_from_user+0xaa/0x160<br /> __x64_sys_symlinkat+0xb9/0xf0<br /> do_syscall_64+0xbb/0x1d0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f08d75c13bb

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: target: core: Fix null-ptr-deref in target_alloc_device()<br /> <br /> There is a null-ptr-deref issue reported by KASAN:<br /> <br /> BUG: KASAN: null-ptr-deref in target_alloc_device+0xbc4/0xbe0 [target_core_mod]<br /> ...<br /> kasan_report+0xb9/0xf0<br /> target_alloc_device+0xbc4/0xbe0 [target_core_mod]<br /> core_dev_setup_virtual_lun0+0xef/0x1f0 [target_core_mod]<br /> target_core_init_configfs+0x205/0x420 [target_core_mod]<br /> do_one_initcall+0xdd/0x4e0<br /> ...<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> In target_alloc_device(), if allocing memory for dev queues fails, then<br /> dev will be freed by dev-&gt;transport-&gt;free_device(), but dev-&gt;transport<br /> is not initialized at that time, which will lead to a null pointer<br /> reference problem.<br /> <br /> Fixing this bug by freeing dev with hba-&gt;backend-&gt;ops-&gt;free_device().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp/dccp: Don&amp;#39;t use timer_pending() in reqsk_queue_unlink().<br /> <br /> Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler().<br /> <br /> """<br /> We are seeing a use-after-free from a bpf prog attached to<br /> trace_tcp_retransmit_synack. The program passes the req-&gt;sk to the<br /> bpf_sk_storage_get_tracing kernel helper which does check for null<br /> before using it.<br /> """<br /> <br /> The commit 83fccfc3940c ("inet: fix potential deadlock in<br /> reqsk_queue_unlink()") added timer_pending() in reqsk_queue_unlink() not<br /> to call del_timer_sync() from reqsk_timer_handler(), but it introduced a<br /> small race window.<br /> <br /> Before the timer is called, expire_timers() calls detach_timer(timer, true)<br /> to clear timer-&gt;entry.pprev and marks it as not pending.<br /> <br /> If reqsk_queue_unlink() checks timer_pending() just after expire_timers()<br /> calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer will<br /> continue running and send multiple SYN+ACKs until it expires.<br /> <br /> The reported UAF could happen if req-&gt;sk is close()d earlier than the timer<br /> expiration, which is 63s by default.<br /> <br /> The scenario would be<br /> <br /> 1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(),<br /> but del_timer_sync() is missed<br /> <br /> 2. reqsk timer is executed and scheduled again<br /> <br /> 3. req-&gt;sk is accept()ed and reqsk_put() decrements rsk_refcnt, but<br /> reqsk timer still has another one, and inet_csk_accept() does not<br /> clear req-&gt;sk for non-TFO sockets<br /> <br /> 4. sk is close()d<br /> <br /> 5. reqsk timer is executed again, and BPF touches req-&gt;sk<br /> <br /> Let&amp;#39;s not use timer_pending() by passing the caller context to<br /> __inet_csk_reqsk_queue_drop().<br /> <br /> Note that reqsk timer is pinned, so the issue does not happen in most<br /> use cases. [1]<br /> <br /> [0]<br /> BUG: KFENCE: use-after-free read in bpf_sk_storage_get_tracing+0x2e/0x1b0<br /> <br /> Use-after-free read at 0x00000000a891fb3a (in kfence-#1):<br /> bpf_sk_storage_get_tracing+0x2e/0x1b0<br /> bpf_prog_5ea3e95db6da0438_tcp_retransmit_synack+0x1d20/0x1dda<br /> bpf_trace_run2+0x4c/0xc0<br /> tcp_rtx_synack+0xf9/0x100<br /> reqsk_timer_handler+0xda/0x3d0<br /> run_timer_softirq+0x292/0x8a0<br /> irq_exit_rcu+0xf5/0x320<br /> sysvec_apic_timer_interrupt+0x6d/0x80<br /> asm_sysvec_apic_timer_interrupt+0x16/0x20<br /> intel_idle_irq+0x5a/0xa0<br /> cpuidle_enter_state+0x94/0x273<br /> cpu_startup_entry+0x15e/0x260<br /> start_secondary+0x8a/0x90<br /> secondary_startup_64_no_verify+0xfa/0xfb<br /> <br /> kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6<br /> <br /> allocated by task 0 on cpu 9 at 260507.901592s:<br /> sk_prot_alloc+0x35/0x140<br /> sk_clone_lock+0x1f/0x3f0<br /> inet_csk_clone_lock+0x15/0x160<br /> tcp_create_openreq_child+0x1f/0x410<br /> tcp_v6_syn_recv_sock+0x1da/0x700<br /> tcp_check_req+0x1fb/0x510<br /> tcp_v6_rcv+0x98b/0x1420<br /> ipv6_list_rcv+0x2258/0x26e0<br /> napi_complete_done+0x5b1/0x2990<br /> mlx5e_napi_poll+0x2ae/0x8d0<br /> net_rx_action+0x13e/0x590<br /> irq_exit_rcu+0xf5/0x320<br /> common_interrupt+0x80/0x90<br /> asm_common_interrupt+0x22/0x40<br /> cpuidle_enter_state+0xfb/0x273<br /> cpu_startup_entry+0x15e/0x260<br /> start_secondary+0x8a/0x90<br /> secondary_startup_64_no_verify+0xfa/0xfb<br /> <br /> freed by task 0 on cpu 9 at 260507.927527s:<br /> rcu_core_si+0x4ff/0xf10<br /> irq_exit_rcu+0xf5/0x320<br /> sysvec_apic_timer_interrupt+0x6d/0x80<br /> asm_sysvec_apic_timer_interrupt+0x16/0x20<br /> cpuidle_enter_state+0xfb/0x273<br /> cpu_startup_entry+0x15e/0x260<br /> start_secondary+0x8a/0x90<br /> secondary_startup_64_no_verify+0xfa/0xfb

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: Fix shift-out-of-bounds bug<br /> <br /> Fix a shift-out-of-bounds bug reported by UBSAN when running<br /> VM with MTE enabled host kernel.<br /> <br /> UBSAN: shift-out-of-bounds in arch/arm64/kvm/sys_regs.c:1988:14<br /> shift exponent 33 is too large for 32-bit type &amp;#39;int&amp;#39;<br /> CPU: 26 UID: 0 PID: 7629 Comm: qemu-kvm Not tainted 6.12.0-rc2 #34<br /> Hardware name: IEI NF5280R7/Mitchell MB, BIOS 00.00. 2024-10-12 09:28:54 10/14/2024<br /> Call trace:<br /> dump_backtrace+0xa0/0x128<br /> show_stack+0x20/0x38<br /> dump_stack_lvl+0x74/0x90<br /> dump_stack+0x18/0x28<br /> __ubsan_handle_shift_out_of_bounds+0xf8/0x1e0<br /> reset_clidr+0x10c/0x1c8<br /> kvm_reset_sys_regs+0x50/0x1c8<br /> kvm_reset_vcpu+0xec/0x2b0<br /> __kvm_vcpu_set_target+0x84/0x158<br /> kvm_vcpu_set_target+0x138/0x168<br /> kvm_arch_vcpu_ioctl_vcpu_init+0x40/0x2b0<br /> kvm_arch_vcpu_ioctl+0x28c/0x4b8<br /> kvm_vcpu_ioctl+0x4bc/0x7a8<br /> __arm64_sys_ioctl+0xb4/0x100<br /> invoke_syscall+0x70/0x100<br /> el0_svc_common.constprop.0+0x48/0xf0<br /> do_el0_svc+0x24/0x38<br /> el0_svc+0x3c/0x158<br /> el0t_64_sync_handler+0x120/0x130<br /> el0t_64_sync+0x194/0x198

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/core: Disable page allocation in task_tick_mm_cid()<br /> <br /> With KASAN and PREEMPT_RT enabled, calling task_work_add() in<br /> task_tick_mm_cid() may cause the following splat.<br /> <br /> [ 63.696416] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48<br /> [ 63.696416] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 610, name: modprobe<br /> [ 63.696416] preempt_count: 10001, expected: 0<br /> [ 63.696416] RCU nest depth: 1, expected: 1<br /> <br /> This problem is caused by the following call trace.<br /> <br /> sched_tick() [ acquire rq-&gt;__lock ]<br /> -&gt; task_tick_mm_cid()<br /> -&gt; task_work_add()<br /> -&gt; __kasan_record_aux_stack()<br /> -&gt; kasan_save_stack()<br /> -&gt; stack_depot_save_flags()<br /> -&gt; alloc_pages_mpol_noprof()<br /> -&gt; __alloc_pages_noprof()<br /> -&gt; get_page_from_freelist()<br /> -&gt; rmqueue()<br /> -&gt; rmqueue_pcplist()<br /> -&gt; __rmqueue_pcplist()<br /> -&gt; rmqueue_bulk()<br /> -&gt; rt_spin_lock()<br /> <br /> The rq lock is a raw_spinlock_t. We can&amp;#39;t sleep while holding<br /> it. IOW, we can&amp;#39;t call alloc_pages() in stack_depot_save_flags().<br /> <br /> The task_tick_mm_cid() function with its task_work_add() call was<br /> introduced by commit 223baf9d17f2 ("sched: Fix performance regression<br /> introduced by mm_cid") in v6.4 kernel.<br /> <br /> Fortunately, there is a kasan_record_aux_stack_noalloc() variant that<br /> calls stack_depot_save_flags() while not allowing it to allocate<br /> new pages. To allow task_tick_mm_cid() to use task_work without<br /> page allocation, a new TWAF_NO_ALLOC flag is added to enable calling<br /> kasan_record_aux_stack_noalloc() instead of kasan_record_aux_stack()<br /> if set. The task_tick_mm_cid() function is modified to add this new flag.<br /> <br /> The possible downside is the missing stack trace in a KASAN report due<br /> to new page allocation required when task_work_add_noallloc() is called<br /> which should be rare.