Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Don&amp;#39;t free job in TDR<br /> <br /> Freeing job in TDR is not safe as TDR can pass the run_job thread<br /> resulting in UAF. It is only safe for free job to naturally be called by<br /> the scheduler. Rather free job in TDR, add to pending list.<br /> <br /> (cherry picked from commit ea2f6a77d0c40d97f4a4dc93fee4afe15d94926d)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix possible double free in smb2_set_ea()<br /> <br /> Clang static checker(scan-build) warning：<br /> fs/smb/client/smb2ops.c:1304:2: Attempt to free released memory.<br /> 1304 | kfree(ea);<br /> | ^~~~~~~~~<br /> <br /> There is a double free in such case:<br /> &amp;#39;ea is initialized to NULL&amp;#39; -&gt; &amp;#39;first successful memory allocation for<br /> ea&amp;#39; -&gt; &amp;#39;something failed, goto sea_exit&amp;#39; -&gt; &amp;#39;first memory release for ea&amp;#39;<br /> -&gt; &amp;#39;goto replay_again&amp;#39; -&gt; &amp;#39;second goto sea_exit before allocate memory<br /> for ea&amp;#39; -&gt; &amp;#39;second memory release for ea resulted in double free&amp;#39;.<br /> <br /> Re-initialie &amp;#39;ea&amp;#39; to NULL near to the replay_again label, it can fix this<br /> double free problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Don&amp;#39;t call cleanup on profile rollback failure<br /> <br /> When profile rollback fails in mlx5e_netdev_change_profile, the netdev<br /> profile var is left set to NULL. Avoid a crash when unloading the driver<br /> by not calling profile-&gt;cleanup in such a case.<br /> <br /> This was encountered while testing, with the original trigger that<br /> the wq rescuer thread creation got interrupted (presumably due to<br /> Ctrl+C-ing modprobe), which gets converted to ENOMEM (-12) by<br /> mlx5e_priv_init, the profile rollback also fails for the same reason<br /> (signal still active) so the profile is left as NULL, leading to a crash<br /> later in _mlx5e_remove.<br /> <br /> [ 732.473932] mlx5_core 0000:08:00.1: E-Switch: Unload vfs: mode(OFFLOADS), nvfs(2), necvfs(0), active vports(2)<br /> [ 734.525513] workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR<br /> [ 734.557372] mlx5_core 0000:08:00.1: mlx5e_netdev_init_profile:6235:(pid 6086): mlx5e_priv_init failed, err=-12<br /> [ 734.559187] mlx5_core 0000:08:00.1 eth3: mlx5e_netdev_change_profile: new profile init failed, -12<br /> [ 734.560153] workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR<br /> [ 734.589378] mlx5_core 0000:08:00.1: mlx5e_netdev_init_profile:6235:(pid 6086): mlx5e_priv_init failed, err=-12<br /> [ 734.591136] mlx5_core 0000:08:00.1 eth3: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12<br /> [ 745.537492] BUG: kernel NULL pointer dereference, address: 0000000000000008<br /> [ 745.538222] #PF: supervisor read access in kernel mode<br /> <br /> [ 745.551290] Call Trace:<br /> [ 745.551590] <br /> [ 745.551866] ? __die+0x20/0x60<br /> [ 745.552218] ? page_fault_oops+0x150/0x400<br /> [ 745.555307] ? exc_page_fault+0x79/0x240<br /> [ 745.555729] ? asm_exc_page_fault+0x22/0x30<br /> [ 745.556166] ? mlx5e_remove+0x6b/0xb0 [mlx5_core]<br /> [ 745.556698] auxiliary_bus_remove+0x18/0x30<br /> [ 745.557134] device_release_driver_internal+0x1df/0x240<br /> [ 745.557654] bus_remove_device+0xd7/0x140<br /> [ 745.558075] device_del+0x15b/0x3c0<br /> [ 745.558456] mlx5_rescan_drivers_locked.part.0+0xb1/0x2f0 [mlx5_core]<br /> [ 745.559112] mlx5_unregister_device+0x34/0x50 [mlx5_core]<br /> [ 745.559686] mlx5_uninit_one+0x46/0xf0 [mlx5_core]<br /> [ 745.560203] remove_one+0x4e/0xd0 [mlx5_core]<br /> [ 745.560694] pci_device_remove+0x39/0xa0<br /> [ 745.561112] device_release_driver_internal+0x1df/0x240<br /> [ 745.561631] driver_detach+0x47/0x90<br /> [ 745.562022] bus_remove_driver+0x84/0x100<br /> [ 745.562444] pci_unregister_driver+0x3b/0x90<br /> [ 745.562890] mlx5_cleanup+0xc/0x1b [mlx5_core]<br /> [ 745.563415] __x64_sys_delete_module+0x14d/0x2f0<br /> [ 745.563886] ? kmem_cache_free+0x1b0/0x460<br /> [ 745.564313] ? lockdep_hardirqs_on_prepare+0xe2/0x190<br /> [ 745.564825] do_syscall_64+0x6d/0x140<br /> [ 745.565223] entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> [ 745.565725] RIP: 0033:0x7f1579b1288b

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().