Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: wilc1000: avoid buffer overflow in WID string configuration<br /> <br /> Fix the following copy overflow warning identified by Smatch checker.<br /> <br /> drivers/net/wireless/microchip/wilc1000/wlan_cfg.c:184 wilc_wlan_parse_response_frame()<br /> error: &amp;#39;__memcpy()&amp;#39; &amp;#39;cfg-&gt;s[i]-&gt;str&amp;#39; copy overflow (512 vs 65537)<br /> <br /> This patch introduces size check before accessing the memory buffer.<br /> The checks are base on the WID type of received data from the firmware.<br /> For WID string configuration, the size limit is determined by individual<br /> element size in &amp;#39;struct wilc_cfg_str_vals&amp;#39; that is maintained in &amp;#39;len&amp;#39; field<br /> of &amp;#39;struct wilc_cfg_str&amp;#39;.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> um: virtio_uml: Fix use-after-free after put_device in probe<br /> <br /> When register_virtio_device() fails in virtio_uml_probe(),<br /> the code sets vu_dev-&gt;registered = 1 even though<br /> the device was not successfully registered.<br /> This can lead to use-after-free or other issues.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/tcp: Fix a NULL pointer dereference when using TCP-AO with TCP_REPAIR<br /> <br /> A NULL pointer dereference can occur in tcp_ao_finish_connect() during a<br /> connect() system call on a socket with a TCP-AO key added and TCP_REPAIR<br /> enabled.<br /> <br /> The function is called with skb being NULL and attempts to dereference it<br /> on tcp_hdr(skb)-&gt;seq without a prior skb validation.<br /> <br /> Fix this by checking if skb is NULL before dereferencing it.<br /> <br /> The commentary is taken from bpf_skops_established(), which is also called<br /> in the same flow. Unlike the function being patched,<br /> bpf_skops_established() validates the skb before dereferencing it.<br /> <br /> int main(void){<br /> struct sockaddr_in sockaddr;<br /> struct tcp_ao_add tcp_ao;<br /> int sk;<br /> int one = 1;<br /> <br /> memset(&amp;sockaddr,&amp;#39;\0&amp;#39;,sizeof(sockaddr));<br /> memset(&amp;tcp_ao,&amp;#39;\0&amp;#39;,sizeof(tcp_ao));<br /> <br /> sk = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);<br /> <br /> sockaddr.sin_family = AF_INET;<br /> <br /> memcpy(tcp_ao.alg_name,"cmac(aes128)",12);<br /> memcpy(tcp_ao.key,"ABCDEFGHABCDEFGH",16);<br /> tcp_ao.keylen = 16;<br /> <br /> memcpy(&amp;tcp_ao.addr,&amp;sockaddr,sizeof(sockaddr));<br /> <br /> setsockopt(sk, IPPROTO_TCP, TCP_AO_ADD_KEY, &amp;tcp_ao,<br /> sizeof(tcp_ao));<br /> setsockopt(sk, IPPROTO_TCP, TCP_REPAIR, &amp;one, sizeof(one));<br /> <br /> sockaddr.sin_family = AF_INET;<br /> sockaddr.sin_port = htobe16(123);<br /> <br /> inet_aton("127.0.0.1", &amp;sockaddr.sin_addr);<br /> <br /> connect(sk,(struct sockaddr *)&amp;sockaddr,sizeof(sockaddr));<br /> <br /> return 0;<br /> }<br /> <br /> $ gcc tcp-ao-nullptr.c -o tcp-ao-nullptr -Wall<br /> $ unshare -Urn<br /> <br /> BUG: kernel NULL pointer dereference, address: 00000000000000b6<br /> PGD 1f648d067 P4D 1f648d067 PUD 1982e8067 PMD 0<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop<br /> Reference Platform, BIOS 6.00 11/12/2020<br /> RIP: 0010:tcp_ao_finish_connect (net/ipv4/tcp_ao.c:1182)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> qed: Don&amp;#39;t collect too many protection override GRC elements<br /> <br /> In the protection override dump path, the firmware can return far too<br /> many GRC elements, resulting in attempting to write past the end of the<br /> previously-kmalloc&amp;#39;ed dump buffer.<br /> <br /> This will result in a kernel panic with reason:<br /> <br /> BUG: unable to handle kernel paging request at ADDRESS<br /> <br /> where "ADDRESS" is just past the end of the protection override dump<br /> buffer. The start address of the buffer is:<br /> p_hwfn-&gt;cdev-&gt;dbg_features[DBG_FEATURE_PROTECTION_OVERRIDE].dump_buf<br /> and the size of the buffer is buf_size in the same data structure.<br /> <br /> The panic can be arrived at from either the qede Ethernet driver path:<br /> <br /> [exception RIP: qed_grc_dump_addr_range+0x108]<br /> qed_protection_override_dump at ffffffffc02662ed [qed]<br /> qed_dbg_protection_override_dump at ffffffffc0267792 [qed]<br /> qed_dbg_feature at ffffffffc026aa8f [qed]<br /> qed_dbg_all_data at ffffffffc026b211 [qed]<br /> qed_fw_fatal_reporter_dump at ffffffffc027298a [qed]<br /> devlink_health_do_dump at ffffffff82497f61<br /> devlink_health_report at ffffffff8249cf29<br /> qed_report_fatal_error at ffffffffc0272baf [qed]<br /> qede_sp_task at ffffffffc045ed32 [qede]<br /> process_one_work at ffffffff81d19783<br /> <br /> or the qedf storage driver path:<br /> <br /> [exception RIP: qed_grc_dump_addr_range+0x108]<br /> qed_protection_override_dump at ffffffffc068b2ed [qed]<br /> qed_dbg_protection_override_dump at ffffffffc068c792 [qed]<br /> qed_dbg_feature at ffffffffc068fa8f [qed]<br /> qed_dbg_all_data at ffffffffc0690211 [qed]<br /> qed_fw_fatal_reporter_dump at ffffffffc069798a [qed]<br /> devlink_health_do_dump at ffffffff8aa95e51<br /> devlink_health_report at ffffffff8aa9ae19<br /> qed_report_fatal_error at ffffffffc0697baf [qed]<br /> qed_hw_err_notify at ffffffffc06d32d7 [qed]<br /> qed_spq_post at ffffffffc06b1011 [qed]<br /> qed_fcoe_destroy_conn at ffffffffc06b2e91 [qed]<br /> qedf_cleanup_fcport at ffffffffc05e7597 [qedf]<br /> qedf_rport_event_handler at ffffffffc05e7bf7 [qedf]<br /> fc_rport_work at ffffffffc02da715 [libfc]<br /> process_one_work at ffffffff8a319663<br /> <br /> Resolve this by clamping the firmware&amp;#39;s return value to the maximum<br /> number of legal elements the firmware should return.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> zram: fix slot write race condition<br /> <br /> Parallel concurrent writes to the same zram index result in leaked<br /> zsmalloc handles. Schematically we can have something like this:<br /> <br /> CPU0 CPU1<br /> zram_slot_lock()<br /> zs_free(handle)<br /> zram_slot_lock()<br /> zram_slot_lock()<br /> zs_free(handle)<br /> zram_slot_lock()<br /> <br /> compress compress<br /> handle = zs_malloc() handle = zs_malloc()<br /> zram_slot_lock<br /> zram_set_handle(handle)<br /> zram_slot_lock<br /> zram_slot_lock<br /> zram_set_handle(handle)<br /> zram_slot_lock<br /> <br /> Either CPU0 or CPU1 zsmalloc handle will leak because zs_free() is done<br /> too early. In fact, we need to reset zram entry right before we set its<br /> new handle, all under the same slot lock scope.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cnic: Fix use-after-free bugs in cnic_delete_task<br /> <br /> The original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(),<br /> which does not guarantee that the delayed work item &amp;#39;delete_task&amp;#39; has<br /> fully completed if it was already running. Additionally, the delayed work<br /> item is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() only<br /> blocks and waits for work items that were already queued to the<br /> workqueue prior to its invocation. Any work items submitted after<br /> flush_workqueue() is called are not included in the set of tasks that the<br /> flush operation awaits. This means that after the cyclic work items have<br /> finished executing, a delayed work item may still exist in the workqueue.<br /> This leads to use-after-free scenarios where the cnic_dev is deallocated<br /> by cnic_free_dev(), while delete_task remains active and attempt to<br /> dereference cnic_dev in cnic_delete_task().<br /> <br /> A typical race condition is illustrated below:<br /> <br /> CPU 0 (cleanup) | CPU 1 (delayed work callback)<br /> cnic_netdev_event() |<br /> cnic_stop_hw() | cnic_delete_task()<br /> cnic_cm_stop_bnx2x_hw() | ...<br /> cancel_delayed_work() | /* the queue_delayed_work()<br /> flush_workqueue() | executes after flush_workqueue()*/<br /> | queue_delayed_work()<br /> cnic_free_dev(dev)//free | cnic_delete_task() //new instance<br /> | dev = cp-&gt;dev; //use<br /> <br /> Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure<br /> that the cyclic delayed work item is properly canceled and that any<br /> ongoing execution of the work item completes before the cnic_dev is<br /> deallocated. Furthermore, since cancel_delayed_work_sync() uses<br /> __flush_work(work, true) to synchronously wait for any currently<br /> executing instance of the work item to finish, the flush_workqueue()<br /> becomes redundant and should be removed.<br /> <br /> This bug was identified through static analysis. To reproduce the issue<br /> and validate the fix, I simulated the cnic PCI device in QEMU and<br /> introduced intentional delays — such as inserting calls to ssleep()<br /> within the cnic_delete_task() function — to increase the likelihood<br /> of triggering the bug.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: fix Rx page leak on multi-buffer frames<br /> <br /> The ice_put_rx_mbuf() function handles calling ice_put_rx_buf() for each<br /> buffer in the current frame. This function was introduced as part of<br /> handling multi-buffer XDP support in the ice driver.<br /> <br /> It works by iterating over the buffers from first_desc up to 1 plus the<br /> total number of fragments in the frame, cached from before the XDP program<br /> was executed.<br /> <br /> If the hardware posts a descriptor with a size of 0, the logic used in<br /> ice_put_rx_mbuf() breaks. Such descriptors get skipped and don&amp;#39;t get added<br /> as fragments in ice_add_xdp_frag. Since the buffer isn&amp;#39;t counted as a<br /> fragment, we do not iterate over it in ice_put_rx_mbuf(), and thus we don&amp;#39;t<br /> call ice_put_rx_buf().<br /> <br /> Because we don&amp;#39;t call ice_put_rx_buf(), we don&amp;#39;t attempt to re-use the<br /> page or free it. This leaves a stale page in the ring, as we don&amp;#39;t<br /> increment next_to_alloc.<br /> <br /> The ice_reuse_rx_page() assumes that the next_to_alloc has been incremented<br /> properly, and that it always points to a buffer with a NULL page. Since<br /> this function doesn&amp;#39;t check, it will happily recycle a page over the top<br /> of the next_to_alloc buffer, losing track of the old page.<br /> <br /> Note that this leak only occurs for multi-buffer frames. The<br /> ice_put_rx_mbuf() function always handles at least one buffer, so a<br /> single-buffer frame will always get handled correctly. It is not clear<br /> precisely why the hardware hands us descriptors with a size of 0 sometimes,<br /> but it happens somewhat regularly with "jumbo frames" used by 9K MTU.<br /> <br /> To fix ice_put_rx_mbuf(), we need to make sure to call ice_put_rx_buf() on<br /> all buffers between first_desc and next_to_clean. Borrow the logic of a<br /> similar function in i40e used for this same purpose. Use the same logic<br /> also in ice_get_pgcnts().<br /> <br /> Instead of iterating over just the number of fragments, use a loop which<br /> iterates until the current index reaches to the next_to_clean element just<br /> past the current frame. Unlike i40e, the ice_put_rx_mbuf() function does<br /> call ice_put_rx_buf() on the last buffer of the frame indicating the end of<br /> packet.<br /> <br /> For non-linear (multi-buffer) frames, we need to take care when adjusting<br /> the pagecnt_bias. An XDP program might release fragments from the tail of<br /> the frame, in which case that fragment page is already released. Only<br /> update the pagecnt_bias for the first descriptor and fragments still<br /> remaining post-XDP program. Take care to only access the shared info for<br /> fragmented buffers, as this avoids a significant cache miss.<br /> <br /> The xdp_xmit value only needs to be updated if an XDP program is run, and<br /> only once per packet. Drop the xdp_xmit pointer argument from<br /> ice_put_rx_mbuf(). Instead, set xdp_xmit in the ice_clean_rx_irq() function<br /> directly. This avoids needing to pass the argument and avoids an extra<br /> bit-wise OR for each buffer in the frame.<br /> <br /> Move the increment of the ntc local variable to ensure its updated *before*<br /> all calls to ice_get_pgcnts() or ice_put_rx_mbuf(), as the loop logic<br /> requires the index of the element just after the current frame.<br /> <br /> Now that we use an index pointer in the ring to identify the packet, we no<br /> longer need to track or cache the number of fragments in the rx_ring.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Harden uplink netdev access against device unbind<br /> <br /> The function mlx5_uplink_netdev_get() gets the uplink netdevice<br /> pointer from mdev-&gt;mlx5e_res.uplink_netdev. However, the netdevice can<br /> be removed and its pointer cleared when unbound from the mlx5_core.eth<br /> driver. This results in a NULL pointer, causing a kernel panic.<br /> <br /> BUG: unable to handle page fault for address: 0000000000001300<br /> at RIP: 0010:mlx5e_vport_rep_load+0x22a/0x270 [mlx5_core]<br /> Call Trace:<br /> <br /> mlx5_esw_offloads_rep_load+0x68/0xe0 [mlx5_core]<br /> esw_offloads_enable+0x593/0x910 [mlx5_core]<br /> mlx5_eswitch_enable_locked+0x341/0x420 [mlx5_core]<br /> mlx5_devlink_eswitch_mode_set+0x17e/0x3a0 [mlx5_core]<br /> devlink_nl_eswitch_set_doit+0x60/0xd0<br /> genl_family_rcv_msg_doit+0xe0/0x130<br /> genl_rcv_msg+0x183/0x290<br /> netlink_rcv_skb+0x4b/0xf0<br /> genl_rcv+0x24/0x40<br /> netlink_unicast+0x255/0x380<br /> netlink_sendmsg+0x1f3/0x420<br /> __sock_sendmsg+0x38/0x60<br /> __sys_sendto+0x119/0x180<br /> do_syscall_64+0x53/0x1d0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> Ensure the pointer is valid before use by checking it for NULL. If it<br /> is valid, immediately call netdev_hold() to take a reference, and<br /> preventing the netdevice from being freed while it is in use.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tls: make sure to abort the stream if headers are bogus<br /> <br /> Normally we wait for the socket to buffer up the whole record<br /> before we service it. If the socket has a tiny buffer, however,<br /> we read out the data sooner, to prevent connection stalls.<br /> Make sure that we abort the connection when we find out late<br /> that the record is actually invalid. Retrying the parsing is<br /> fine in itself but since we copy some more data each time<br /> before we parse we can overflow the allocated skb space.<br /> <br /> Constructing a scenario in which we&amp;#39;re under pressure without<br /> enough data in the socket to parse the length upfront is quite<br /> hard. syzbot figured out a way to do this by serving us the header<br /> in small OOB sends, and then filling in the recvbuf with a large<br /> normal send.<br /> <br /> Make sure that tls_rx_msg_size() aborts strp, if we reach<br /> an invalid record there&amp;#39;s really no way to recover.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-pf: Fix use-after-free bugs in otx2_sync_tstamp()<br /> <br /> The original code relies on cancel_delayed_work() in otx2_ptp_destroy(),<br /> which does not ensure that the delayed work item synctstamp_work has fully<br /> completed if it was already running. This leads to use-after-free scenarios<br /> where otx2_ptp is deallocated by otx2_ptp_destroy(), while synctstamp_work<br /> remains active and attempts to dereference otx2_ptp in otx2_sync_tstamp().<br /> Furthermore, the synctstamp_work is cyclic, the likelihood of triggering<br /> the bug is nonnegligible.<br /> <br /> A typical race condition is illustrated below:<br /> <br /> CPU 0 (cleanup) | CPU 1 (delayed work callback)<br /> otx2_remove() |<br /> otx2_ptp_destroy() | otx2_sync_tstamp()<br /> cancel_delayed_work() |<br /> kfree(ptp) |<br /> | ptp = container_of(...); //UAF<br /> | ptp-&gt; //UAF<br /> <br /> This is confirmed by a KASAN report:<br /> <br /> BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0<br /> Write of size 8 at addr ffff88800aa09a18 by task bash/136<br /> ...<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x55/0x70<br /> print_report+0xcf/0x610<br /> ? __run_timer_base.part.0+0x7d7/0x8c0<br /> kasan_report+0xb8/0xf0<br /> ? __run_timer_base.part.0+0x7d7/0x8c0<br /> __run_timer_base.part.0+0x7d7/0x8c0<br /> ? __pfx___run_timer_base.part.0+0x10/0x10<br /> ? __pfx_read_tsc+0x10/0x10<br /> ? ktime_get+0x60/0x140<br /> ? lapic_next_event+0x11/0x20<br /> ? clockevents_program_event+0x1d4/0x2a0<br /> run_timer_softirq+0xd1/0x190<br /> handle_softirqs+0x16a/0x550<br /> irq_exit_rcu+0xaf/0xe0<br /> sysvec_apic_timer_interrupt+0x70/0x80<br /> <br /> ...<br /> Allocated by task 1:<br /> kasan_save_stack+0x24/0x50<br /> kasan_save_track+0x14/0x30<br /> __kasan_kmalloc+0x7f/0x90<br /> otx2_ptp_init+0xb1/0x860<br /> otx2_probe+0x4eb/0xc30<br /> local_pci_probe+0xdc/0x190<br /> pci_device_probe+0x2fe/0x470<br /> really_probe+0x1ca/0x5c0<br /> __driver_probe_device+0x248/0x310<br /> driver_probe_device+0x44/0x120<br /> __driver_attach+0xd2/0x310<br /> bus_for_each_dev+0xed/0x170<br /> bus_add_driver+0x208/0x500<br /> driver_register+0x132/0x460<br /> do_one_initcall+0x89/0x300<br /> kernel_init_freeable+0x40d/0x720<br /> kernel_init+0x1a/0x150<br /> ret_from_fork+0x10c/0x1a0<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> Freed by task 136:<br /> kasan_save_stack+0x24/0x50<br /> kasan_save_track+0x14/0x30<br /> kasan_save_free_info+0x3a/0x60<br /> __kasan_slab_free+0x3f/0x50<br /> kfree+0x137/0x370<br /> otx2_ptp_destroy+0x38/0x80<br /> otx2_remove+0x10d/0x4c0<br /> pci_device_remove+0xa6/0x1d0<br /> device_release_driver_internal+0xf8/0x210<br /> pci_stop_bus_device+0x105/0x150<br /> pci_stop_and_remove_bus_device_locked+0x15/0x30<br /> remove_store+0xcc/0xe0<br /> kernfs_fop_write_iter+0x2c3/0x440<br /> vfs_write+0x871/0xd70<br /> ksys_write+0xee/0x1c0<br /> do_syscall_64+0xac/0x280<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> ...<br /> <br /> Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure<br /> that the delayed work item is properly canceled before the otx2_ptp is<br /> deallocated.<br /> <br /> This bug was initially identified through static analysis. To reproduce<br /> and test it, I simulated the OcteonTX2 PCI device in QEMU and introduced<br /> artificial delays within the otx2_sync_tstamp() function to increase the<br /> likelihood of triggering the bug.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: smbdirect: validate data_offset and data_length field of smb_direct_data_transfer<br /> <br /> If data_offset and data_length of smb_direct_data_transfer struct are<br /> invalid, out of bounds issue could happen.<br /> This patch validate data_offset and data_length field in recv_done.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: smbdirect: verify remaining_data_length respects max_fragmented_recv_size<br /> <br /> This is inspired by the check for data_offset + data_length.