Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock()<br /> <br /> Syzkaller reported a panic in smc_tcp_syn_recv_sock() [1].<br /> <br /> smc_tcp_syn_recv_sock() is called in the TCP receive path<br /> (softirq) via icsk_af_ops-&gt;syn_recv_sock on the clcsock (TCP<br /> listening socket). It reads sk_user_data to get the smc_sock<br /> pointer. However, when the SMC listen socket is being closed<br /> concurrently, smc_close_active() sets clcsock-&gt;sk_user_data<br /> to NULL under sk_callback_lock, and then the smc_sock itself<br /> can be freed via sock_put() in smc_release().<br /> <br /> This leads to two issues:<br /> <br /> 1) NULL pointer dereference: sk_user_data is NULL when<br /> accessed.<br /> 2) Use-after-free: sk_user_data is read as non-NULL, but the<br /> smc_sock is freed before its fields (e.g., queued_smc_hs,<br /> ori_af_ops) are accessed.<br /> <br /> The race window looks like this (the syzkaller crash [1]<br /> triggers via the SYN cookie path: tcp_get_cookie_sock() -&gt;<br /> smc_tcp_syn_recv_sock(), but the normal tcp_check_req() path<br /> has the same race):<br /> <br /> CPU A (softirq) CPU B (process ctx)<br /> <br /> tcp_v4_rcv()<br /> TCP_NEW_SYN_RECV:<br /> sk = req-&gt;rsk_listener<br /> sock_hold(sk)<br /> /* No lock on listener */<br /> smc_close_active():<br /> write_lock_bh(cb_lock)<br /> sk_user_data = NULL<br /> write_unlock_bh(cb_lock)<br /> ...<br /> smc_clcsock_release()<br /> sock_put(smc-&gt;sk) x2<br /> -&gt; smc_sock freed!<br /> tcp_check_req()<br /> smc_tcp_syn_recv_sock():<br /> smc = user_data(sk)<br /> -&gt; NULL or dangling<br /> smc-&gt;queued_smc_hs<br /> -&gt; crash!<br /> <br /> Note that the clcsock and smc_sock are two independent objects<br /> with separate refcounts. TCP stack holds a reference on the<br /> clcsock, which keeps it alive, but this does NOT prevent the<br /> smc_sock from being freed.<br /> <br /> Fix this by using RCU and refcount_inc_not_zero() to safely<br /> access smc_sock. Since smc_tcp_syn_recv_sock() is called in<br /> the TCP three-way handshake path, taking read_lock_bh on<br /> sk_callback_lock is too heavy and would not survive a SYN<br /> flood attack. Using rcu_read_lock() is much more lightweight.<br /> <br /> - Set SOCK_RCU_FREE on the SMC listen socket so that<br /> smc_sock freeing is deferred until after the RCU grace<br /> period. This guarantees the memory is still valid when<br /> accessed inside rcu_read_lock().<br /> - Use rcu_read_lock() to protect reading sk_user_data.<br /> - Use refcount_inc_not_zero(&amp;smc-&gt;sk.sk_refcnt) to pin the<br /> smc_sock. If the refcount has already reached zero (close<br /> path completed), it returns false and we bail out safely.<br /> <br /> Note: smc_hs_congested() has a similar lockless read of<br /> sk_user_data without rcu_read_lock(), but it only checks for<br /> NULL and accesses the global smc_hs_wq, never dereferencing<br /> any smc_sock field, so it is not affected.<br /> <br /> Reproducer was verified with mdelay injection and smc_run,<br /> the issue no longer occurs with this patch applied.<br /> <br /> [1] https://syzkaller.appspot.com/bug?extid=827ae2bfb3a3529333e9

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bonding: prevent potential infinite loop in bond_header_parse()<br /> <br /> bond_header_parse() can loop if a stack of two bonding devices is setup,<br /> because skb-&gt;dev always points to the hierarchy top.<br /> <br /> Add new "const struct net_device *dev" parameter to<br /> (struct header_ops)-&gt;parse() method to make sure the recursion<br /> is bounded, and that the final leaf parse method is called.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ti: icssg-prueth: Fix memory leak in XDP_DROP for non-zero-copy mode<br /> <br /> Page recycling was removed from the XDP_DROP path in emac_run_xdp() to<br /> avoid conflicts with AF_XDP zero-copy mode, which uses xsk_buff_free()<br /> instead.<br /> <br /> However, this causes a memory leak when running XDP programs that drop<br /> packets in non-zero-copy mode (standard page pool mode). The pages are<br /> never returned to the page pool, leading to OOM conditions.<br /> <br /> Fix this by handling cleanup in the caller, emac_rx_packet().<br /> When emac_run_xdp() returns ICSSG_XDP_CONSUMED for XDP_DROP, the<br /> caller now recycles the page back to the page pool. The zero-copy<br /> path, emac_rx_packet_zc() already handles cleanup correctly with<br /> xsk_buff_free().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: cdc_ncm: add ndpoffset to NDP16 nframes bounds check<br /> <br /> cdc_ncm_rx_verify_ndp16() validates that the NDP header and its DPE<br /> entries fit within the skb. The first check correctly accounts for<br /> ndpoffset:<br /> <br /> if ((ndpoffset + sizeof(struct usb_cdc_ncm_ndp16)) &gt; skb_in-&gt;len)<br /> <br /> but the second check omits it:<br /> <br /> if ((sizeof(struct usb_cdc_ncm_ndp16) +<br /> ret * (sizeof(struct usb_cdc_ncm_dpe16))) &gt; skb_in-&gt;len)<br /> <br /> This validates the DPE array size against the total skb length as if<br /> the NDP were at offset 0, rather than at ndpoffset. When the NDP is<br /> placed near the end of the NTB (large wNdpIndex), the DPE entries can<br /> extend past the skb data buffer even though the check passes.<br /> cdc_ncm_rx_fixup() then reads out-of-bounds memory when iterating<br /> the DPE array.<br /> <br /> Add ndpoffset to the nframes bounds check and use struct_size_t() to<br /> express the NDP-plus-DPE-array size more clearly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> igc: fix page fault in XDP TX timestamps handling<br /> <br /> If an XDP application that requested TX timestamping is shutting down<br /> while the link of the interface in use is still up the following kernel<br /> splat is reported:<br /> <br /> [ 883.803618] [ T1554] BUG: unable to handle page fault for address: ffffcfb6200fd008<br /> ...<br /> [ 883.803650] [ T1554] Call Trace:<br /> [ 883.803652] [ T1554] <br /> [ 883.803654] [ T1554] igc_ptp_tx_tstamp_event+0xdf/0x160 [igc]<br /> [ 883.803660] [ T1554] igc_tsync_interrupt+0x2d5/0x300 [igc]<br /> ...<br /> <br /> During shutdown of the TX ring the xsk_meta pointers are left behind, so<br /> that the IRQ handler is trying to touch them.<br /> <br /> This issue is now being fixed by cleaning up the stale xsk meta data on<br /> TX shutdown. TX timestamps on other queues remain unaffected.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: cdc_ncm: add ndpoffset to NDP32 nframes bounds check<br /> <br /> The same bounds-check bug fixed for NDP16 in the previous patch also<br /> exists in cdc_ncm_rx_verify_ndp32(). The DPE array size is validated<br /> against the total skb length without accounting for ndpoffset, allowing<br /> out-of-bounds reads when the NDP32 is placed near the end of the NTB.<br /> <br /> Add ndpoffset to the nframes bounds check and use struct_size_t() to<br /> express the NDP-plus-DPE-array size more clearly.<br /> <br /> Compile-tested only.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: aqc111: Do not perform PM inside suspend callback<br /> <br /> syzbot reports "task hung in rpm_resume"<br /> <br /> This is caused by aqc111_suspend calling<br /> the PM variant of its write_cmd routine.<br /> <br /> The simplified call trace looks like this:<br /> <br /> rpm_suspend()<br /> usb_suspend_both() - here udev-&gt;dev.power.runtime_status == RPM_SUSPENDING<br /> aqc111_suspend() - called for the usb device interface<br /> aqc111_write32_cmd()<br /> usb_autopm_get_interface()<br /> pm_runtime_resume_and_get()<br /> rpm_resume() - here we call rpm_resume() on our parent<br /> rpm_resume() - Here we wait for a status change that will never happen.<br /> <br /> At this point we block another task which holds<br /> rtnl_lock and locks up the whole networking stack.<br /> <br /> Fix this by replacing the write_cmd calls with their _nopm variants

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: add NULL checks for idev in SRv6 paths<br /> <br /> __in6_dev_get() can return NULL when the device has no IPv6 configuration<br /> (e.g. MTU

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: always free skb on ieee80211_tx_prepare_skb() failure<br /> <br /> ieee80211_tx_prepare_skb() has three error paths, but only two of them<br /> free the skb. The first error path (ieee80211_tx_prepare() returning<br /> TX_DROP) does not free it, while invoke_tx_handlers() failure and the<br /> fragmentation check both do.<br /> <br /> Add kfree_skb() to the first error path so all three are consistent,<br /> and remove the now-redundant frees in callers (ath9k, mt76,<br /> mac80211_hwsim) to avoid double-free.<br /> <br /> Document the skb ownership guarantee in the function&amp;#39;s kdoc.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: processor: Fix previous acpi_processor_errata_piix4() fix<br /> <br /> After commi f132e089fe89 ("ACPI: processor: Fix NULL-pointer dereference<br /> in acpi_processor_errata_piix4()"), device pointers may be dereferenced<br /> after dropping references to the device objects pointed to by them,<br /> which may cause a use-after-free to occur.<br /> <br /> Moreover, debug messages about enabling the errata may be printed<br /> if the errata flags corresponding to them are unset.<br /> <br /> Address all of these issues by moving message printing to the points<br /> in the code where the errata flags are set.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Fix race condition during IPSec ESN update<br /> <br /> In IPSec full offload mode, the device reports an ESN (Extended<br /> Sequence Number) wrap event to the driver. The driver validates this<br /> event by querying the IPSec ASO and checking that the esn_event_arm<br /> field is 0x0, which indicates an event has occurred. After handling<br /> the event, the driver must re-arm the context by setting esn_event_arm<br /> back to 0x1.<br /> <br /> A race condition exists in this handling path. After validating the<br /> event, the driver calls mlx5_accel_esp_modify_xfrm() to update the<br /> kernel&amp;#39;s xfrm state. This function temporarily releases and<br /> re-acquires the xfrm state lock.<br /> <br /> So, need to acknowledge the event first by setting esn_event_arm to<br /> 0x1. This prevents the driver from reprocessing the same ESN update if<br /> the hardware sends events for other reason. Since the next ESN update<br /> only occurs after nearly 2^31 packets are received, there&amp;#39;s no risk of<br /> missing an update, as it will happen long after this handling has<br /> finished.<br /> <br /> Processing the event twice causes the ESN high-order bits (esn_msb) to<br /> be incremented incorrectly. The driver then programs the hardware with<br /> this invalid ESN state, which leads to anti-replay failures and a<br /> complete halt of IPSec traffic.<br /> <br /> Fix this by re-arming the ESN event immediately after it is validated,<br /> before calling mlx5_accel_esp_modify_xfrm(). This ensures that any<br /> spurious, duplicate events are correctly ignored, closing the race<br /> window.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Prevent concurrent access to IPSec ASO context<br /> <br /> The query or updating IPSec offload object is through Access ASO WQE.<br /> The driver uses a single mlx5e_ipsec_aso struct for each PF, which<br /> contains a shared DMA-mapped context for all ASO operations.<br /> <br /> A race condition exists because the ASO spinlock is released before<br /> the hardware has finished processing WQE. If a second operation is<br /> initiated immediately after, it overwrites the shared context in the<br /> DMA area.<br /> <br /> When the first operation&amp;#39;s completion is processed later, it reads<br /> this corrupted context, leading to unexpected behavior and incorrect<br /> results.<br /> <br /> This commit fixes the race by introducing a private context within<br /> each IPSec offload object. The shared ASO context is now copied to<br /> this private context while the ASO spinlock is held. Subsequent<br /> processing uses this saved, per-object context, ensuring its integrity<br /> is maintained.