Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info work<br /> <br /> The brcmf_btcoex_detach() only shuts down the btcoex timer, if the<br /> flag timer_on is false. However, the brcmf_btcoex_timerfunc(), which<br /> runs as timer handler, sets timer_on to false. This creates critical<br /> race conditions:<br /> <br /> 1.If brcmf_btcoex_detach() is called while brcmf_btcoex_timerfunc()<br /> is executing, it may observe timer_on as false and skip the call to<br /> timer_shutdown_sync().<br /> <br /> 2.The brcmf_btcoex_timerfunc() may then reschedule the brcmf_btcoex_info<br /> worker after the cancel_work_sync() has been executed, resulting in<br /> use-after-free bugs.<br /> <br /> The use-after-free bugs occur in two distinct scenarios, depending on<br /> the timing of when the brcmf_btcoex_info struct is freed relative to<br /> the execution of its worker thread.<br /> <br /> Scenario 1: Freed before the worker is scheduled<br /> <br /> The brcmf_btcoex_info is deallocated before the worker is scheduled.<br /> A race condition can occur when schedule_work(&amp;bt_local-&gt;work) is<br /> called after the target memory has been freed. The sequence of events<br /> is detailed below:<br /> <br /> CPU0 | CPU1<br /> brcmf_btcoex_detach | brcmf_btcoex_timerfunc<br /> | bt_local-&gt;timer_on = false;<br /> if (cfg-&gt;btcoex-&gt;timer_on) |<br /> ... |<br /> cancel_work_sync(); |<br /> ... |<br /> kfree(cfg-&gt;btcoex); // FREE |<br /> | schedule_work(&amp;bt_local-&gt;work); // USE<br /> <br /> Scenario 2: Freed after the worker is scheduled<br /> <br /> The brcmf_btcoex_info is freed after the worker has been scheduled<br /> but before or during its execution. In this case, statements within<br /> the brcmf_btcoex_handler() — such as the container_of macro and<br /> subsequent dereferences of the brcmf_btcoex_info object will cause<br /> a use-after-free access. The following timeline illustrates this<br /> scenario:<br /> <br /> CPU0 | CPU1<br /> brcmf_btcoex_detach | brcmf_btcoex_timerfunc<br /> | bt_local-&gt;timer_on = false;<br /> if (cfg-&gt;btcoex-&gt;timer_on) |<br /> ... |<br /> cancel_work_sync(); |<br /> ... | schedule_work(); // Reschedule<br /> |<br /> kfree(cfg-&gt;btcoex); // FREE | brcmf_btcoex_handler() // Worker<br /> /* | btci = container_of(....); // USE<br /> The kfree() above could | ...<br /> also occur at any point | btci-&gt; // USE<br /> during the worker&amp;#39;s execution|<br /> */ |<br /> <br /> To resolve the race conditions, drop the conditional check and call<br /> timer_shutdown_sync() directly. It can deactivate the timer reliably,<br /> regardless of its current state. Once stopped, the timer_on state is<br /> then set to false.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7915: fix list corruption after hardware restart<br /> <br /> Since stations are recreated from scratch, all lists that wcids are added<br /> to must be cleared before calling ieee80211_restart_hw.<br /> Set wcid-&gt;sta = 0 for each wcid entry in order to ensure that they are<br /> not added again before they are ready.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: vhci: Prevent use-after-free by removing debugfs files early<br /> <br /> Move the creation of debugfs files into a dedicated function, and ensure<br /> they are explicitly removed during vhci_release(), before associated<br /> data structures are freed.<br /> <br /> Previously, debugfs files such as "force_suspend", "force_wakeup", and<br /> others were created under hdev-&gt;debugfs but not removed in<br /> vhci_release(). Since vhci_release() frees the backing vhci_data<br /> structure, any access to these files after release would result in<br /> use-after-free errors.<br /> <br /> Although hdev-&gt;debugfs is later freed in hci_release_dev(), user can<br /> access files after vhci_data is freed but before hdev-&gt;debugfs is<br /> released.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i40e: Fix potential invalid access when MAC list is empty<br /> <br /> list_first_entry() never returns NULL - if the list is empty, it still<br /> returns a pointer to an invalid object, leading to potential invalid<br /> memory access when dereferenced.<br /> <br /> Fix this by using list_first_entry_or_null instead of list_first_entry.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: fix one NULL pointer dereference in smc_ib_is_sg_need_sync()<br /> <br /> BUG: kernel NULL pointer dereference, address: 00000000000002ec<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] SMP PTI<br /> CPU: 28 UID: 0 PID: 343 Comm: kworker/28:1 Kdump: loaded Tainted: G OE 6.17.0-rc2+ #9 NONE<br /> Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014<br /> Workqueue: smc_hs_wq smc_listen_work [smc]<br /> RIP: 0010:smc_ib_is_sg_need_sync+0x9e/0xd0 [smc]<br /> ...<br /> Call Trace:<br /> <br /> smcr_buf_map_link+0x211/0x2a0 [smc]<br /> __smc_buf_create+0x522/0x970 [smc]<br /> smc_buf_create+0x3a/0x110 [smc]<br /> smc_find_rdma_v2_device_serv+0x18f/0x240 [smc]<br /> ? smc_vlan_by_tcpsk+0x7e/0xe0 [smc]<br /> smc_listen_find_device+0x1dd/0x2b0 [smc]<br /> smc_listen_work+0x30f/0x580 [smc]<br /> process_one_work+0x18c/0x340<br /> worker_thread+0x242/0x360<br /> kthread+0xe7/0x220<br /> ret_from_fork+0x13a/0x160<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> If the software RoCE device is used, ibdev-&gt;dma_device is a null pointer.<br /> As a result, the problem occurs. Null pointer detection is added to<br /> prevent problems.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: Fix use-after-free in l2cap_sock_cleanup_listen()<br /> <br /> syzbot reported the splat below without a repro.<br /> <br /> In the splat, a single thread calling bt_accept_dequeue() freed sk<br /> and touched it after that.<br /> <br /> The root cause would be the racy l2cap_sock_cleanup_listen() call<br /> added by the cited commit.<br /> <br /> bt_accept_dequeue() is called under lock_sock() except for<br /> l2cap_sock_release().<br /> <br /> Two threads could see the same socket during the list iteration<br /> in bt_accept_dequeue():<br /> <br /> CPU1 CPU2 (close())<br /> ---- ----<br /> sock_hold(sk) sock_hold(sk);<br /> lock_sock(sk)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/tcp: Fix socket memory leak in TCP-AO failure handling for IPv6<br /> <br /> When tcp_ao_copy_all_matching() fails in tcp_v6_syn_recv_sock() it just<br /> exits the function. This ends up causing a memory-leak:<br /> <br /> unreferenced object 0xffff0000281a8200 (size 2496):<br /> comm "softirq", pid 0, jiffies 4295174684<br /> hex dump (first 32 bytes):<br /> 7f 00 00 06 7f 00 00 06 00 00 00 00 cb a8 88 13 ................<br /> 0a 00 03 61 00 00 00 00 00 00 00 00 00 00 00 00 ...a............<br /> backtrace (crc 5ebdbe15):<br /> kmemleak_alloc+0x44/0xe0<br /> kmem_cache_alloc_noprof+0x248/0x470<br /> sk_prot_alloc+0x48/0x120<br /> sk_clone_lock+0x38/0x3b0<br /> inet_csk_clone_lock+0x34/0x150<br /> tcp_create_openreq_child+0x3c/0x4a8<br /> tcp_v6_syn_recv_sock+0x1c0/0x620<br /> tcp_check_req+0x588/0x790<br /> tcp_v6_rcv+0x5d0/0xc18<br /> ip6_protocol_deliver_rcu+0x2d8/0x4c0<br /> ip6_input_finish+0x74/0x148<br /> ip6_input+0x50/0x118<br /> ip6_sublist_rcv+0x2fc/0x3b0<br /> ipv6_list_rcv+0x114/0x170<br /> __netif_receive_skb_list_core+0x16c/0x200<br /> netif_receive_skb_list_internal+0x1f0/0x2d0<br /> <br /> This is because in tcp_v6_syn_recv_sock (and the IPv4 counterpart), when<br /> exiting upon error, inet_csk_prepare_forced_close() and tcp_done() need<br /> to be called. They make sure the newsk will end up being correctly<br /> free&amp;#39;d.<br /> <br /> tcp_v4_syn_recv_sock() makes this very clear by having the put_and_exit<br /> label that takes care of things. So, this patch here makes sure<br /> tcp_v4_syn_recv_sock and tcp_v6_syn_recv_sock have similar<br /> error-handling and thus fixes the leak for TCP-AO.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: ti: am65-cpsw-nuss: Fix null pointer dereference for ndev<br /> <br /> In the TX completion packet stage of TI SoCs with CPSW2G instance, which<br /> has single external ethernet port, ndev is accessed without being<br /> initialized if no TX packets have been processed. It results into null<br /> pointer dereference, causing kernel to crash. Fix this by having a check<br /> on the number of TX packets which have been processed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: fix NULL access of tx-&gt;in_use in ice_ll_ts_intr<br /> <br /> Recent versions of the E810 firmware have support for an extra interrupt to<br /> handle report of the "low latency" Tx timestamps coming from the<br /> specialized low latency firmware interface. Instead of polling the<br /> registers, software can wait until the low latency interrupt is fired.<br /> <br /> This logic makes use of the Tx timestamp tracking structure, ice_ptp_tx, as<br /> it uses the same "ready" bitmap to track which Tx timestamps complete.<br /> <br /> Unfortunately, the ice_ll_ts_intr() function does not check if the<br /> tracker is initialized before its first access. This results in NULL<br /> dereference or use-after-free bugs similar to the issues fixed in the<br /> ice_ptp_ts_irq() function.<br /> <br /> Fix this by only checking the in_use bitmap (and other fields) if the<br /> tracker is marked as initialized. The reset flow will clear the init field<br /> under lock before it tears the tracker down, thus preventing any<br /> use-after-free or NULL access.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: fix NULL access of tx-&gt;in_use in ice_ptp_ts_irq<br /> <br /> The E810 device has support for a "low latency" firmware interface to<br /> access and read the Tx timestamps. This interface does not use the standard<br /> Tx timestamp logic, due to the latency overhead of proxying sideband<br /> command requests over the firmware AdminQ.<br /> <br /> The logic still makes use of the Tx timestamp tracking structure,<br /> ice_ptp_tx, as it uses the same "ready" bitmap to track which Tx<br /> timestamps complete.<br /> <br /> Unfortunately, the ice_ptp_ts_irq() function does not check if the tracker<br /> is initialized before its first access. This results in NULL dereference or<br /> use-after-free bugs similar to the following:<br /> <br /> [245977.278756] BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [245977.278774] RIP: 0010:_find_first_bit+0x19/0x40<br /> [245977.278796] Call Trace:<br /> [245977.278809] ? ice_misc_intr+0x364/0x380 [ice]<br /> <br /> This can occur if a Tx timestamp interrupt races with the driver reset<br /> logic.<br /> <br /> Fix this by only checking the in_use bitmap (and other fields) if the<br /> tracker is marked as initialized. The reset flow will clear the init field<br /> under lock before it tears the tracker down, thus preventing any<br /> use-after-free or NULL access.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> eth: mlx4: Fix IS_ERR() vs NULL check bug in mlx4_en_create_rx_ring<br /> <br /> Replace NULL check with IS_ERR() check after calling page_pool_create()<br /> since this function returns error pointers (ERR_PTR).<br /> Using NULL check could lead to invalid pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ptp: ocp: fix use-after-free bugs causing by ptp_ocp_watchdog<br /> <br /> The ptp_ocp_detach() only shuts down the watchdog timer if it is<br /> pending. However, if the timer handler is already running, the<br /> timer_delete_sync() is not called. This leads to race conditions<br /> where the devlink that contains the ptp_ocp is deallocated while<br /> the timer handler is still accessing it, resulting in use-after-free<br /> bugs. The following details one of the race scenarios.<br /> <br /> (thread 1) | (thread 2)<br /> ptp_ocp_remove() |<br /> ptp_ocp_detach() | ptp_ocp_watchdog()<br /> if (timer_pending(&amp;bp-&gt;watchdog))| bp = timer_container_of()<br /> timer_delete_sync() |<br /> |<br /> devlink_free(devlink) //free |<br /> | bp-&gt; //use<br /> <br /> Resolve this by unconditionally calling timer_delete_sync() to ensure<br /> the timer is reliably deactivated, preventing any access after free.