Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: seq: dummy: fix UMP event stack overread<br /> <br /> The dummy sequencer port forwards events by copying an incoming<br /> struct snd_seq_event into a stack temporary, rewriting source and<br /> destination, and dispatching the temporary to subscribers. That legacy<br /> event storage is smaller than struct snd_seq_ump_event.<br /> <br /> When a UMP event reaches the dummy client, the copy leaves the UMP flag<br /> set but only provides legacy-sized stack storage. The subscriber<br /> delivery path then uses snd_seq_event_packet_size() and copies a<br /> UMP-sized packet from that stack object, reading past the end of the<br /> temporary.<br /> <br /> Use the existing union __snd_seq_event storage and copy the packet size<br /> reported for the incoming event before rewriting the common routing<br /> fields. This preserves the full UMP packet for UMP events while keeping<br /> legacy event handling unchanged.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xsk: cache csum_start/csum_offset to fix TOCTOU in xsk_skb_metadata()<br /> <br /> The TX metadata area resides in the UMEM buffer which is memory-mapped<br /> and concurrently writable by userspace. In xsk_skb_metadata(),<br /> csum_start and csum_offset are read from shared memory for bounds<br /> validation, then read again for skb assignment. A malicious userspace<br /> application can race to overwrite these values between the two reads,<br /> bypassing the bounds check and causing out-of-bounds memory access<br /> during checksum computation in the transmit path.<br /> <br /> Fix this by reading csum_start and csum_offset into local variables<br /> once, then using the local copies for both validation and assignment.<br /> <br /> Note that other metadata fields (flags, launch_time) and the cached<br /> csum fields may be mutually inconsistent due to concurrent userspace<br /> writes, but this is benign: the only security-critical invariant is<br /> that each field&amp;#39;s validated value is the same one used, which local<br /> caching guarantees.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: phy: clean the sfp upstream if phy probing fails<br /> <br /> Sashiko reported that we don&amp;#39;t call sfp_bus_del_upstream() in the probe<br /> failure path, so let&amp;#39;s add it, otherwise the sfp-bus is left with a<br /> dangling &amp;#39;upstream&amp;#39; field, that may be used later on during SFP events.<br /> <br /> This issue existed before the generic phylib sfp support, back when<br /> drivers were calling phy_sfp_probe themselves.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netdev: fix double-free in netdev_nl_bind_rx_doit()<br /> <br /> Sashiko flags that genlmsg_reply() always consumes the skb.<br /> The error path calls nlmsg_free(rsp) so we can&amp;#39;t jump directly<br /> to it. Let&amp;#39;s not unbind, just propagate the error to the user.<br /> This is the typical way of handling genlmsg_reply() failures.<br /> They shouldn&amp;#39;t happen unless user does something silly like<br /> calling the kernel with an already-full rcvbuf.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: iptfs: fix use-after-free on first_skb in __input_process_payload<br /> <br /> __input_process_payload() stores first_skb into xtfs-&gt;ra_newskb under<br /> drop_lock when starting partial reassembly, then unlocks and breaks out<br /> of the processing loop. The post-loop check reads xtfs-&gt;ra_newskb<br /> without the lock to decide whether first_skb is still owned:<br /> <br /> if (first_skb &amp;&amp; first_iplen &amp;&amp; !defer &amp;&amp; first_skb != xtfs-&gt;ra_newskb)<br /> <br /> Between spin_unlock and this read, a concurrent CPU running<br /> iptfs_reassem_cont() (or the drop_timer hrtimer) can complete<br /> reassembly, NULL xtfs-&gt;ra_newskb, and free the skb. The check then<br /> evaluates first_skb != NULL as true, and pskb_trim/ip_summed/consume_skb<br /> operate on the freed skb — a use-after-free in skbuff_head_cache.<br /> <br /> Replace the unlocked read with a local bool that records whether<br /> first_skb was handed to the reassembly state in the current call. The<br /> flag is set after the existing spin_unlock, before the break, using the<br /> pointer equality that is stable at that point (first_skb == skb iff<br /> first_skb was stored in ra_newskb).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: policy: fix use-after-free on inexact bin in xfrm_policy_bysel_ctx()<br /> <br /> Fix the race by pruning the bin while still holding xfrm_policy_lock,<br /> before dropping it. Use __xfrm_policy_inexact_prune_bin() directly since<br /> the lock is already held. The wrapper xfrm_policy_inexact_prune_bin()<br /> becomes unused and is removed.<br /> <br /> Race:<br /> <br /> CPU0 (XFRM_MSG_DELPOLICY) CPU1 (XFRM_MSG_NEWSPDINFO)<br /> ========================== ==========================<br /> xfrm_policy_bysel_ctx():<br /> spin_lock_bh(xfrm_policy_lock)<br /> bin = xfrm_policy_inexact_lookup()<br /> __xfrm_policy_unlink(pol)<br /> spin_unlock_bh(xfrm_policy_lock)<br /> xfrm_policy_kill(ret)<br /> // wide window, lock not held<br /> xfrm_hash_rebuild():<br /> spin_lock_bh(xfrm_policy_lock)<br /> __xfrm_policy_inexact_flush():<br /> kfree_rcu(bin) // bin freed<br /> spin_unlock_bh(xfrm_policy_lock)<br /> xfrm_policy_inexact_prune_bin(bin)<br /> // UAF: bin is freed

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netlabel: validate unlabeled address and mask attribute lengths<br /> <br /> netlbl_unlabel_addrinfo_get() used the address attribute length to<br /> determine whether the attribute data could be read as an IPv4 or IPv6<br /> address, but did not independently validate the corresponding mask<br /> attribute length. A crafted Generic Netlink request could therefore<br /> provide a valid IPv4/IPv6 address attribute with a shorter mask<br /> attribute, which would later be read as a full struct in_addr or<br /> struct in6_addr.<br /> <br /> NLA_BINARY policy lengths are maximum lengths by default, so use<br /> NLA_POLICY_EXACT_LEN() for the unlabeled IPv4/IPv6 address and mask<br /> attributes. This rejects short attributes during policy validation and<br /> also exposes the exact length requirements through policy introspection.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: mvebu: fix NULL pointer dereference in suspend/resume<br /> <br /> mvebu_pwm_suspend() and mvebu_pwm_resume() are called for all GPIO<br /> banks during suspend/resume, but not all banks have PWM functionality.<br /> GPIO banks without PWM have mvchip-&gt;mvpwm set to NULL.<br /> <br /> Calling mvebu_pwm_suspend() with mvpwm == NULL causes a NULL pointer<br /> dereference when it tries to access mvpwm-&gt;blink_select.<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 00000020 when write<br /> [00000020] *pgd=00000000<br /> Internal error: Oops: 815 [#1] PREEMPT ARM<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 406 Comm: sh Not tainted 6.12.74-rt12-yocto-standard-g4e96f98fb7db-dirty #353<br /> Hardware name: Marvell Armada 370/XP (Device Tree)<br /> PC is at regmap_mmio_read+0x38/0x54<br /> LR is at regmap_mmio_read+0x38/0x54<br /> pc : [] lr : [] psr: 200f0013<br /> sp : f0c11d10 ip : 00000000 fp : c100d2f0<br /> r10: c14fb854 r9 : 00000000 r8 : 00000000<br /> r7 : c1799c00 r6 : 00000020 r5 : 00000020 r4 : c179c7c0<br /> r3 : f0a231a0 r2 : 00000020 r1 : 00000020 r0 : 00000000<br /> Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none<br /> Control: 10c5387d Table: 135ec059 DAC: 00000051<br /> Call trace:<br /> regmap_mmio_read from _regmap_bus_reg_read+0x78/0xac<br /> _regmap_bus_reg_read from _regmap_read+0x60/0x154<br /> _regmap_read from regmap_read+0x3c/0x60<br /> regmap_read from mvebu_gpio_suspend+0xa4/0x14c<br /> mvebu_gpio_suspend from dpm_run_callback+0x54/0x180<br /> dpm_run_callback from device_suspend+0x124/0x630<br /> device_suspend from dpm_suspend+0x124/0x270<br /> dpm_suspend from dpm_suspend_start+0x64/0x6c<br /> dpm_suspend_start from suspend_devices_and_enter+0x140/0x8e8<br /> suspend_devices_and_enter from pm_suspend+0x2fc/0x308<br /> pm_suspend from state_store+0x6c/0xc8<br /> state_store from kernfs_fop_write_iter+0x10c/0x1f8<br /> kernfs_fop_write_iter from vfs_write+0x270/0x468<br /> vfs_write from ksys_write+0x70/0xf0<br /> ksys_write from ret_fast_syscall+0x0/0x54<br /> <br /> Add a NULL check for mvchip-&gt;mvpwm before calling the PWM<br /> suspend/resume functions.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: restrict SO_ATTACH_FILTER to priv users<br /> <br /> This patch restricts the use of SO_ATTACH_FILTER (cBPF) on TCP sockets<br /> to users with CAP_NET_ADMIN capability.<br /> <br /> This blocks potential side-channel attack where an unprivileged application<br /> attaches a filter to leak TCP sequence/acknowledgment numbers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: add pskb_may_pull() to skb_gro_receive_list()<br /> <br /> skb_gro_receive_list() calls skb_pull(skb, skb_gro_offset(skb)) without<br /> first ensuring the data is in the linear area via pskb_may_pull(). When<br /> the skb arrives via napi_gro_frags(), skb_headlen can be 0 (all data in<br /> page fragments) while skb_gro_offset is non-zero (after IP+TCP header<br /> parsing). The skb_pull() then decrements skb-&gt;len by skb_gro_offset<br /> but skb-&gt;data_len stays unchanged, hitting BUG_ON(skb-&gt;len data_len)<br /> in __skb_pull().<br /> <br /> The UDP fraglist GRO path already contains this guard at<br /> udp_offload.c:749. Adding it to skb_gro_receive_list() itself provides<br /> centralized protection for all callers (TCP, UDP, and any future<br /> protocols), and ensures the precondition of skb_pull() is satisfied<br /> before it is called.<br /> <br /> On pskb_may_pull() failure, set NAPI_GRO_CB(skb)-&gt;flush = 1 so the<br /> skb is not held as a new GRO head and is instead delivered through the<br /> normal receive path, matching the UDP handling.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ibm: emac: Fix use-after-free during device removal<br /> <br /> The driver was using devm_register_netdev() which causes unregister_netdev()<br /> to be deferred until the devres cleanup phase, which runs after emac_remove()<br /> returns. This creates a use-after-free window where:<br /> <br /> 1. emac_remove() is called, which tears down hardware (cancels work, detaches<br /> modules, unregisters from MAL)<br /> 2. emac_remove() returns<br /> 3. devres cleanup runs and finally calls unregister_netdev()<br /> <br /> During step 3, the network stack might still process packets, triggering<br /> emac_irq(), emac_poll(), or other handlers that access now-freed hardware<br /> resources (dev-&gt;emacp, dev-&gt;mal, etc.).<br /> <br /> Fix this by replacing devm_register_netdev() with manual register_netdev()<br /> and calling unregister_netdev() at the beginning of emac_remove(), before<br /> any hardware teardown. This ensures the network device is fully stopped and<br /> unregistered before hardware resources are released.<br /> <br /> The change is safe because:<br /> - dev-&gt;ndev is assigned very early in probe (before any error paths that<br /> could bypass emac_remove)<br /> - platform_set_drvdata() is only called after successful registration, so<br /> emac_remove() only runs for fully registered devices<br /> - unregister_netdev() is idempotent and safe to call on any registered device

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: phy: don&amp;#39;t try to setup PHY-driven SFP cages when using genphy<br /> <br /> We don&amp;#39;t have support for PHY-driver SFP cages with the genphy code.<br /> <br /> On top of that, it was found by sashiko that running<br /> sfp_bus_add_upstream() for genphy deadlocks, as for genphy the PHY<br /> probing runs under RTNL, which isn&amp;#39;t the case for non-genphy drivers.<br /> <br /> This problem was reproduced, and does lead to a deadlock on RTNL.<br /> <br /> Before the blamed commit, the phy_sfp_probe() call was made by<br /> individual PHY drivers, so there was no way to get to the SFP probing<br /> path when using genphy.<br /> <br /> Let&amp;#39;s therefore only run phy_sfp_probe when not using genphy.