Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ntfs3: Change to non-blocking allocation in ntfs_d_hash<br /> <br /> d_hash is done while under "rcu-walk" and should not sleep.<br /> __get_name() allocates using GFP_KERNEL, having the possibility<br /> to sleep when under memory pressure. Change the allocation to<br /> GFP_NOWAIT.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master Driver Due to Race Condition<br /> <br /> In the cdns_i3c_master_probe function, &amp;master-&gt;hj_work is bound with<br /> cdns_i3c_master_hj. And cdns_i3c_master_interrupt can call<br /> cnds_i3c_master_demux_ibis function to start the work.<br /> <br /> If we remove the module which will call cdns_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 /> | cdns_i3c_master_hj<br /> cdns_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<br /> the cleanup in cdns_i3c_master_remove.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Prevent tail call between progs attached to different hooks<br /> <br /> bpf progs can be attached to kernel functions, and the attached functions<br /> can take different parameters or return different return values. If<br /> prog attached to one kernel function tail calls prog attached to another<br /> kernel function, the ctx access or return value verification could be<br /> bypassed.<br /> <br /> For example, if prog1 is attached to func1 which takes only 1 parameter<br /> and prog2 is attached to func2 which takes two parameters. Since verifier<br /> assumes the bpf ctx passed to prog2 is constructed based on func2&amp;#39;s<br /> prototype, verifier allows prog2 to access the second parameter from<br /> the bpf ctx passed to it. The problem is that verifier does not prevent<br /> prog1 from passing its bpf ctx to prog2 via tail call. In this case,<br /> the bpf ctx passed to prog2 is constructed from func1 instead of func2,<br /> that is, the assumption for ctx access verification is bypassed.<br /> <br /> Another example, if BPF LSM prog1 is attached to hook file_alloc_security,<br /> and BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier<br /> knows the return value rules for these two hooks, e.g. it is legal for<br /> bpf_lsm_audit_rule_known to return positive number 1, and it is illegal<br /> for file_alloc_security to return positive number. So verifier allows<br /> prog2 to return positive number 1, but does not allow prog1 to return<br /> positive number. The problem is that verifier does not prevent prog1<br /> from calling prog2 via tail call. In this case, prog2&amp;#39;s return value 1<br /> will be used as the return value for prog1&amp;#39;s hook file_alloc_security.<br /> That is, the return value rule is bypassed.<br /> <br /> This patch adds restriction for tail call to prevent such bypasses.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ntb: ntb_hw_switchtec: Fix use after free vulnerability in switchtec_ntb_remove due to race condition<br /> <br /> In the switchtec_ntb_add function, it can call switchtec_ntb_init_sndev<br /> function, then &amp;sndev-&gt;check_link_status_work is bound with<br /> check_link_status_work. switchtec_ntb_link_notification may be called<br /> to start the work.<br /> <br /> If we remove the module which will call switchtec_ntb_remove to make<br /> cleanup, it will free sndev through kfree(sndev), while the work<br /> mentioned above will be used. The sequence of operations that may lead<br /> to a UAF bug is as follows:<br /> <br /> CPU0 CPU1<br /> <br /> | check_link_status_work<br /> switchtec_ntb_remove |<br /> kfree(sndev); |<br /> | if (sndev-&gt;link_force_down)<br /> | // use sndev<br /> <br /> Fix it by ensuring that the work is canceled before proceeding with<br /> the cleanup in switchtec_ntb_remove.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring: check if we need to reschedule during overflow flush<br /> <br /> In terms of normal application usage, this list will always be empty.<br /> And if an application does overflow a bit, it&amp;#39;ll have a few entries.<br /> However, nothing obviously prevents syzbot from running a test case<br /> that generates a ton of overflow entries, and then flushing them can<br /> take quite a while.<br /> <br /> Check for needing to reschedule while flushing, and drop our locks and<br /> do so if necessary. There&amp;#39;s no state to maintain here as overflows<br /> always prune from head-of-list, hence it&amp;#39;s fine to drop and reacquire<br /> the locks at the end of the loop.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rtrs-srv: Avoid null pointer deref during path establishment<br /> <br /> For RTRS path establishment, RTRS client initiates and completes con_num<br /> of connections. After establishing all its connections, the information<br /> is exchanged between the client and server through the info_req message.<br /> During this exchange, it is essential that all connections have been<br /> established, and the state of the RTRS srv path is CONNECTED.<br /> <br /> So add these sanity checks, to make sure we detect and abort process in<br /> error scenarios to avoid null pointer deref.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Fix increasing MSI-X on VF<br /> <br /> Increasing MSI-X value on a VF leads to invalid memory operations. This<br /> is caused by not reallocating some arrays.<br /> <br /> Reproducer:<br /> modprobe ice<br /> echo 0 &gt; /sys/bus/pci/devices/$PF_PCI/sriov_drivers_autoprobe<br /> echo 1 &gt; /sys/bus/pci/devices/$PF_PCI/sriov_numvfs<br /> echo 17 &gt; /sys/bus/pci/devices/$VF0_PCI/sriov_vf_msix_count<br /> <br /> Default MSI-X is 16, so 17 and above triggers this issue.<br /> <br /> KASAN reports:<br /> <br /> BUG: KASAN: slab-out-of-bounds in ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice]<br /> Read of size 8 at addr ffff8888b937d180 by task bash/28433<br /> (...)<br /> <br /> Call Trace:<br /> (...)<br /> ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice]<br /> kasan_report+0xed/0x120<br /> ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice]<br /> ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice]<br /> ice_vsi_cfg_def+0x3360/0x4770 [ice]<br /> ? mutex_unlock+0x83/0xd0<br /> ? __pfx_ice_vsi_cfg_def+0x10/0x10 [ice]<br /> ? __pfx_ice_remove_vsi_lkup_fltr+0x10/0x10 [ice]<br /> ice_vsi_cfg+0x7f/0x3b0 [ice]<br /> ice_vf_reconfig_vsi+0x114/0x210 [ice]<br /> ice_sriov_set_msix_vec_count+0x3d0/0x960 [ice]<br /> sriov_vf_msix_count_store+0x21c/0x300<br /> (...)<br /> <br /> Allocated by task 28201:<br /> (...)<br /> ice_vsi_cfg_def+0x1c8e/0x4770 [ice]<br /> ice_vsi_cfg+0x7f/0x3b0 [ice]<br /> ice_vsi_setup+0x179/0xa30 [ice]<br /> ice_sriov_configure+0xcaa/0x1520 [ice]<br /> sriov_numvfs_store+0x212/0x390<br /> (...)<br /> <br /> To fix it, use ice_vsi_rebuild() instead of ice_vf_reconfig_vsi(). This<br /> causes the required arrays to be reallocated taking the new queue count<br /> into account (ice_vsi_realloc_stat_arrays()). Set req_txq and req_rxq<br /> before ice_vsi_rebuild(), so that realloc uses the newly set queue<br /> count.<br /> <br /> Additionally, ice_vsi_rebuild() does not remove VSI filters<br /> (ice_fltr_remove_all()), so ice_vf_init_host_cfg() is no longer<br /> necessary.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: fix possible badness in FREE_STATEID<br /> <br /> When multiple FREE_STATEIDs are sent for the same delegation stateid,<br /> it can lead to a possible either use-after-free or counter refcount<br /> underflow errors.<br /> <br /> In nfsd4_free_stateid() under the client lock we find a delegation<br /> stateid, however the code drops the lock before calling nfs4_put_stid(),<br /> that allows another FREE_STATE to find the stateid again. The first one<br /> will proceed to then free the stateid which leads to either<br /> use-after-free or decrementing already zeroed counter.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: tipd: Free IRQ only if it was requested before<br /> <br /> In polling mode, if no IRQ was requested there is no need to free it.<br /> Call devm_free_irq() only if client-&gt;irq is set. This fixes the warning<br /> caused by the tps6598x module removal:<br /> <br /> WARNING: CPU: 2 PID: 333 at kernel/irq/devres.c:144 devm_free_irq+0x80/0x8c<br /> ...<br /> ...<br /> Call trace:<br /> devm_free_irq+0x80/0x8c<br /> tps6598x_remove+0x28/0x88 [tps6598x]<br /> i2c_device_remove+0x2c/0x9c<br /> device_remove+0x4c/0x80<br /> device_release_driver_internal+0x1cc/0x228<br /> driver_detach+0x50/0x98<br /> bus_remove_driver+0x6c/0xbc<br /> driver_unregister+0x30/0x60<br /> i2c_del_driver+0x54/0x64<br /> tps6598x_i2c_driver_exit+0x18/0xc3c [tps6598x]<br /> __arm64_sys_delete_module+0x184/0x264<br /> invoke_syscall+0x48/0x110<br /> el0_svc_common.constprop.0+0xc8/0xe8<br /> do_el0_svc+0x20/0x2c<br /> el0_svc+0x28/0x98<br /> el0t_64_sync_handler+0x13c/0x158<br /> el0t_64_sync+0x190/0x194

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> driver core: bus: Fix double free in driver API bus_register()<br /> <br /> For bus_register(), any error which happens after kset_register() will<br /> cause that @priv are freed twice, fixed by setting @priv with NULL after<br /> the first free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix UAF in async decryption<br /> <br /> Doing an async decryption (large read) crashes with a<br /> slab-use-after-free way down in the crypto API.<br /> <br /> Reproducer:<br /> # mount.cifs -o ...,seal,esize=1 //srv/share /mnt<br /> # dd if=/mnt/largefile of=/dev/null<br /> ...<br /> [ 194.196391] ==================================================================<br /> [ 194.196844] BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xc1/0x110<br /> [ 194.197269] Read of size 8 at addr ffff888112bd0448 by task kworker/u77:2/899<br /> [ 194.197707]<br /> [ 194.197818] CPU: 12 UID: 0 PID: 899 Comm: kworker/u77:2 Not tainted 6.11.0-lku-00028-gfca3ca14a17a-dirty #43<br /> [ 194.198400] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014<br /> [ 194.199046] Workqueue: smb3decryptd smb2_decrypt_offload [cifs]<br /> [ 194.200032] Call Trace:<br /> [ 194.200191] <br /> [ 194.200327] dump_stack_lvl+0x4e/0x70<br /> [ 194.200558] ? gf128mul_4k_lle+0xc1/0x110<br /> [ 194.200809] print_report+0x174/0x505<br /> [ 194.201040] ? __pfx__raw_spin_lock_irqsave+0x10/0x10<br /> [ 194.201352] ? srso_return_thunk+0x5/0x5f<br /> [ 194.201604] ? __virt_addr_valid+0xdf/0x1c0<br /> [ 194.201868] ? gf128mul_4k_lle+0xc1/0x110<br /> [ 194.202128] kasan_report+0xc8/0x150<br /> [ 194.202361] ? gf128mul_4k_lle+0xc1/0x110<br /> [ 194.202616] gf128mul_4k_lle+0xc1/0x110<br /> [ 194.202863] ghash_update+0x184/0x210<br /> [ 194.203103] shash_ahash_update+0x184/0x2a0<br /> [ 194.203377] ? __pfx_shash_ahash_update+0x10/0x10<br /> [ 194.203651] ? srso_return_thunk+0x5/0x5f<br /> [ 194.203877] ? crypto_gcm_init_common+0x1ba/0x340<br /> [ 194.204142] gcm_hash_assoc_remain_continue+0x10a/0x140<br /> [ 194.204434] crypt_message+0xec1/0x10a0 [cifs]<br /> [ 194.206489] ? __pfx_crypt_message+0x10/0x10 [cifs]<br /> [ 194.208507] ? srso_return_thunk+0x5/0x5f<br /> [ 194.209205] ? srso_return_thunk+0x5/0x5f<br /> [ 194.209925] ? srso_return_thunk+0x5/0x5f<br /> [ 194.210443] ? srso_return_thunk+0x5/0x5f<br /> [ 194.211037] decrypt_raw_data+0x15f/0x250 [cifs]<br /> [ 194.212906] ? __pfx_decrypt_raw_data+0x10/0x10 [cifs]<br /> [ 194.214670] ? srso_return_thunk+0x5/0x5f<br /> [ 194.215193] smb2_decrypt_offload+0x12a/0x6c0 [cifs]<br /> <br /> This is because TFM is being used in parallel.<br /> <br /> Fix this by allocating a new AEAD TFM for async decryption, but keep<br /> the existing one for synchronous READ cases (similar to what is done<br /> in smb3_calc_signature()).<br /> <br /> Also remove the calls to aead_request_set_callback() and<br /> crypto_wait_req() since it&amp;#39;s always going to be a synchronous operation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: uvc: Fix ERR_PTR dereference in uvc_v4l2.c<br /> <br /> Fix potential dereferencing of ERR_PTR() in find_format_by_pix()<br /> and uvc_v4l2_enum_format().<br /> <br /> Fix the following smatch errors:<br /> <br /> drivers/usb/gadget/function/uvc_v4l2.c:124 find_format_by_pix()<br /> error: &amp;#39;fmtdesc&amp;#39; dereferencing possible ERR_PTR()<br /> <br /> drivers/usb/gadget/function/uvc_v4l2.c:392 uvc_v4l2_enum_format()<br /> error: &amp;#39;fmtdesc&amp;#39; dereferencing possible ERR_PTR()<br /> <br /> Also, fix similar issue in uvc_v4l2_try_format() for potential<br /> dereferencing of ERR_PTR().