Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix stackmap overflow check in __bpf_get_stackid()<br /> <br /> Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid()<br /> when copying stack trace data. The issue occurs when the perf trace<br /> contains more stack entries than the stack map bucket can hold,<br /> leading to an out-of-bounds write in the bucket&amp;#39;s data array.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rxe: Fix null deref on srq-&gt;rq.queue after resize failure<br /> <br /> A NULL pointer dereference can occur in rxe_srq_chk_attr() when<br /> ibv_modify_srq() is invoked twice in succession under certain error<br /> conditions. The first call may fail in rxe_queue_resize(), which leads<br /> rxe_srq_from_attr() to set srq-&gt;rq.queue = NULL. The second call then<br /> triggers a crash (null deref) when accessing<br /> srq-&gt;rq.queue-&gt;buf-&gt;index_mask.<br /> <br /> Call Trace:<br /> <br /> rxe_modify_srq+0x170/0x480 [rdma_rxe]<br /> ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe]<br /> ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs]<br /> ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs]<br /> ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs]<br /> ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs]<br /> ? tryinc_node_nr_active+0xe6/0x150<br /> ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs]<br /> ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs]<br /> ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs]<br /> ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs]<br /> ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs]<br /> ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs]<br /> ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs]<br /> ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs]<br /> ? __pfx___raw_spin_lock_irqsave+0x10/0x10<br /> ? __pfx_do_vfs_ioctl+0x10/0x10<br /> ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0<br /> ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10<br /> ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs]<br /> ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs]<br /> __x64_sys_ioctl+0x138/0x1c0<br /> do_syscall_64+0x82/0x250<br /> ? fdget_pos+0x58/0x4c0<br /> ? ksys_write+0xf3/0x1c0<br /> ? __pfx_ksys_write+0x10/0x10<br /> ? do_syscall_64+0xc8/0x250<br /> ? __pfx_vm_mmap_pgoff+0x10/0x10<br /> ? fget+0x173/0x230<br /> ? fput+0x2a/0x80<br /> ? ksys_mmap_pgoff+0x224/0x4c0<br /> ? do_syscall_64+0xc8/0x250<br /> ? do_user_addr_fault+0x37b/0xfe0<br /> ? clear_bhb_loop+0x50/0xa0<br /> ? clear_bhb_loop+0x50/0xa0<br /> ? clear_bhb_loop+0x50/0xa0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: fix peer HE MCS assignment<br /> <br /> In ath11k_wmi_send_peer_assoc_cmd(), peer&amp;#39;s transmit MCS is sent to<br /> firmware as receive MCS while peer&amp;#39;s receive MCS sent as transmit MCS,<br /> which goes against firmwire&amp;#39;s definition.<br /> <br /> While connecting to a misbehaved AP that advertises 0xffff (meaning not<br /> supported) for 160 MHz transmit MCS map, firmware crashes due to 0xffff<br /> is assigned to he_mcs-&gt;rx_mcs_set field.<br /> <br /> Ext Tag: HE Capabilities<br /> [...]<br /> Supported HE-MCS and NSS Set<br /> [...]<br /> Rx and Tx MCS Maps 160 MHz<br /> [...]<br /> Tx HE-MCS Map 160 MHz: 0xffff<br /> <br /> Swap the assignment to fix this issue.<br /> <br /> As the HE rate control mask is meant to limit our own transmit MCS, it<br /> needs to go via he_mcs-&gt;rx_mcs_set field. With the aforementioned swapping<br /> done, change is needed as well to apply it to the peer&amp;#39;s receive MCS.<br /> <br /> Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41<br /> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id<br /> <br /> Use check_add_overflow() to guard against potential integer overflows<br /> when adding the binary blob lengths and the size of an asymmetric_key_id<br /> structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a<br /> possible buffer overflow when copying data from potentially malicious<br /> X.509 certificate fields that can be arbitrarily large, such as ASN.1<br /> INTEGER serial numbers, issuer names, etc.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: aead - Fix reqsize handling<br /> <br /> Commit afddce13ce81d ("crypto: api - Add reqsize to crypto_alg")<br /> introduced cra_reqsize field in crypto_alg struct to replace type<br /> specific reqsize fields. It looks like this was introduced specifically<br /> for ahash and acomp from the commit description as subsequent commits<br /> add necessary changes in these alg frameworks.<br /> <br /> However, this is being recommended for use in all crypto algs<br /> instead of setting reqsize using crypto_*_set_reqsize(). Using<br /> cra_reqsize in aead algorithms, hence, causes memory corruptions and<br /> crashes as the underlying functions in the algorithm framework have not<br /> been updated to set the reqsize properly from cra_reqsize. [1]<br /> <br /> Add proper set_reqsize calls in the aead init function to properly<br /> initialize reqsize for these algorithms in the framework.<br /> <br /> [1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Initialize allocated memory before use<br /> <br /> KMSAN reports: Multiple uninitialized values detected:<br /> <br /> - KMSAN: uninit-value in ntfs_read_hdr (3)<br /> - KMSAN: uninit-value in bcmp (3)<br /> <br /> Memory is allocated by __getname(), which is a wrapper for<br /> kmem_cache_alloc(). This memory is used before being properly<br /> cleared. Change kmem_cache_alloc() to kmem_cache_zalloc() to<br /> properly allocate and clear memory before use.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nbd: defer config unlock in nbd_genl_connect<br /> <br /> There is one use-after-free warning when running NBD_CMD_CONNECT and<br /> NBD_CLEAR_SOCK:<br /> <br /> nbd_genl_connect<br /> nbd_alloc_and_init_config // config_refs=1<br /> nbd_start_device // config_refs=2<br /> set NBD_RT_HAS_CONFIG_REF open nbd // config_refs=3<br /> recv_work done // config_refs=2<br /> NBD_CLEAR_SOCK // config_refs=1<br /> close nbd // config_refs=0<br /> refcount_inc -&gt; uaf<br /> <br /> ------------[ cut here ]------------<br /> refcount_t: addition on 0; use-after-free.<br /> WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290<br /> nbd_genl_connect+0x16d0/0x1ab0<br /> genl_family_rcv_msg_doit+0x1f3/0x310<br /> genl_rcv_msg+0x44a/0x790<br /> <br /> The issue can be easily reproduced by adding a small delay before<br /> refcount_inc(&amp;nbd-&gt;config_refs) in nbd_genl_connect():<br /> <br /> mutex_unlock(&amp;nbd-&gt;config_lock);<br /> if (!ret) {<br /> set_bit(NBD_RT_HAS_CONFIG_REF, &amp;config-&gt;runtime_flags);<br /> + printk("before sleep\n");<br /> + mdelay(5 * 1000);<br /> + printk("after sleep\n");<br /> refcount_inc(&amp;nbd-&gt;config_refs);<br /> nbd_connect_reply(info, nbd-&gt;index);<br /> }

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse<br /> <br /> The following warning appears when running syzkaller, and this issue also<br /> exists in the mainline code.<br /> <br /> ------------[ cut here ]------------<br /> list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100.<br /> WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130<br /> Modules linked in:<br /> CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:__list_add_valid_or_report+0xf7/0x130<br /> RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282<br /> RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817<br /> RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001<br /> RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c<br /> R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100<br /> R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48<br /> FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 80000000<br /> Call Trace:<br /> <br /> input_register_handler+0xb3/0x210<br /> mac_hid_start_emulation+0x1c5/0x290<br /> mac_hid_toggle_emumouse+0x20a/0x240<br /> proc_sys_call_handler+0x4c2/0x6e0<br /> new_sync_write+0x1b1/0x2d0<br /> vfs_write+0x709/0x950<br /> ksys_write+0x12a/0x250<br /> do_syscall_64+0x5a/0x110<br /> entry_SYSCALL_64_after_hwframe+0x78/0xe2<br /> <br /> The WARNING occurs when two processes concurrently write to the mac-hid<br /> emulation sysctl, causing a race condition in mac_hid_toggle_emumouse().<br /> Both processes read old_val=0, then both try to register the input handler,<br /> leading to a double list_add of the same handler.<br /> <br /> CPU0 CPU1<br /> ------------------------- -------------------------<br /> vfs_write() //write 1 vfs_write() //write 1<br /> proc_sys_write() proc_sys_write()<br /> mac_hid_toggle_emumouse() mac_hid_toggle_emumouse()<br /> old_val = *valp // old_val=0<br /> old_val = *valp // old_val=0<br /> mutex_lock_killable()<br /> proc_dointvec() // *valp=1<br /> mac_hid_start_emulation()<br /> input_register_handler()<br /> mutex_unlock()<br /> mutex_lock_killable()<br /> proc_dointvec()<br /> mac_hid_start_emulation()<br /> input_register_handler() //Trigger Warning<br /> mutex_unlock()<br /> <br /> Fix this by moving the old_val read inside the mutex lock region.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md: init bioset in mddev_init<br /> <br /> IO operations may be needed before md_run(), such as updating metadata<br /> after writing sysfs. Without bioset, this triggers a NULL pointer<br /> dereference as below:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000020<br /> Call Trace:<br /> md_update_sb+0x658/0xe00<br /> new_level_store+0xc5/0x120<br /> md_attr_store+0xc9/0x1e0<br /> sysfs_kf_write+0x6f/0xa0<br /> kernfs_fop_write_iter+0x141/0x2a0<br /> vfs_write+0x1fc/0x5a0<br /> ksys_write+0x79/0x180<br /> __x64_sys_write+0x1d/0x30<br /> x64_sys_call+0x2818/0x2880<br /> do_syscall_64+0xa9/0x580<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> Reproducer<br /> ```<br /> mdadm -CR /dev/md0 -l1 -n2 /dev/sd[cd]<br /> echo inactive &gt; /sys/block/md0/md/array_state<br /> echo 10 &gt; /sys/block/md0/md/new_level<br /> ```<br /> <br /> mddev_init() can only be called once per mddev, no need to test if bioset<br /> has been initialized anymore.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ntfs3: init run lock for extend inode<br /> <br /> After setting the inode mode of $Extend to a regular file, executing the<br /> truncate system call will enter the do_truncate() routine, causing the<br /> run_lock uninitialized error reported by syzbot.<br /> <br /> Prior to patch 4e8011ffec79, if the inode mode of $Extend was not set to<br /> a regular file, the do_truncate() routine would not be entered.<br /> <br /> Add the run_lock initialization when loading $Extend.<br /> <br /> syzbot reported:<br /> INFO: trying to register non-static key.<br /> Call Trace:<br /> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120<br /> assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984<br /> register_lock_class+0x105/0x320 kernel/locking/lockdep.c:1299<br /> __lock_acquire+0x99/0xd20 kernel/locking/lockdep.c:5112<br /> lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868<br /> down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590<br /> ntfs_set_size+0x140/0x200 fs/ntfs3/inode.c:860<br /> ntfs_extend+0x1d9/0x970 fs/ntfs3/file.c:387<br /> ntfs_setattr+0x2e8/0xbe0 fs/ntfs3/file.c:808

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> coresight: tmc: add the handle of the event to the path<br /> <br /> The handle is essential for retrieving the AUX_EVENT of each CPU and is<br /> required in perf mode. It has been added to the coresight_path so that<br /> dependent devices can access it from the path when needed.<br /> <br /> The existing bug can be reproduced with:<br /> perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null<br /> <br /> Showing an oops as follows:<br /> Unable to handle kernel paging request at virtual address 000f6e84934ed19e<br /> <br /> Call trace:<br /> tmc_etr_get_buffer+0x30/0x80 [coresight_tmc] (P)<br /> catu_enable_hw+0xbc/0x3d0 [coresight_catu]<br /> catu_enable+0x70/0xe0 [coresight_catu]<br /> coresight_enable_path+0xb0/0x258 [coresight]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: smartpqi: Fix device resources accessed after device removal<br /> <br /> Correct possible race conditions during device removal.<br /> <br /> Previously, a scheduled work item to reset a LUN could still execute<br /> after the device was removed, leading to use-after-free and other<br /> resource access issues.<br /> <br /> This race condition occurs because the abort handler may schedule a LUN<br /> reset concurrently with device removal via sdev_destroy(), leading to<br /> use-after-free and improper access to freed resources.<br /> <br /> - Check in the device reset handler if the device is still present in<br /> the controller&amp;#39;s SCSI device list before running; if not, the reset<br /> is skipped.<br /> <br /> - Cancel any pending TMF work that has not started in sdev_destroy().<br /> <br /> - Ensure device freeing in sdev_destroy() is done while holding the<br /> LUN reset mutex to avoid races with ongoing resets.