Vulnerabilities

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 /> 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 /> 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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/x86: Move event pointer setup earlier in x86_pmu_enable()<br /> <br /> A production AMD EPYC system crashed with a NULL pointer dereference<br /> in the PMU NMI handler:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000198<br /> RIP: x86_perf_event_update+0xc/0xa0<br /> Call Trace:<br /> <br /> amd_pmu_v2_handle_irq+0x1a6/0x390<br /> perf_event_nmi_handler+0x24/0x40<br /> <br /> The faulting instruction is `cmpq $0x0, 0x198(%rdi)` with RDI=0,<br /> corresponding to the `if (unlikely(!hwc-&gt;event_base))` check in<br /> x86_perf_event_update() where hwc = &amp;event-&gt;hw and event is NULL.<br /> <br /> drgn inspection of the vmcore on CPU 106 showed a mismatch between<br /> cpuc-&gt;active_mask and cpuc-&gt;events[]:<br /> <br /> active_mask: 0x1e (bits 1, 2, 3, 4)<br /> events[1]: 0xff1100136cbd4f38 (valid)<br /> events[2]: 0x0 (NULL, but active_mask bit 2 set)<br /> events[3]: 0xff1100076fd2cf38 (valid)<br /> events[4]: 0xff1100079e990a90 (valid)<br /> <br /> The event that should occupy events[2] was found in event_list[2]<br /> with hw.idx=2 and hw.state=0x0, confirming x86_pmu_start() had run<br /> (which clears hw.state and sets active_mask) but events[2] was<br /> never populated.<br /> <br /> Another event (event_list[0]) had hw.state=0x7 (STOPPED|UPTODATE|ARCH),<br /> showing it was stopped when the PMU rescheduled events, confirming the<br /> throttle-then-reschedule sequence occurred.<br /> <br /> The root cause is commit 7e772a93eb61 ("perf/x86: Fix NULL event access<br /> and potential PEBS record loss") which moved the cpuc-&gt;events[idx]<br /> assignment out of x86_pmu_start() and into step 2 of x86_pmu_enable(),<br /> after the PERF_HES_ARCH check. This broke any path that calls<br /> pmu-&gt;start() without going through x86_pmu_enable() -- specifically<br /> the unthrottle path:<br /> <br /> perf_adjust_freq_unthr_events()<br /> -&gt; perf_event_unthrottle_group()<br /> -&gt; perf_event_unthrottle()<br /> -&gt; event-&gt;pmu-&gt;start(event, 0)<br /> -&gt; x86_pmu_start() // sets active_mask but not events[]<br /> <br /> The race sequence is:<br /> <br /> 1. A group of perf events overflows, triggering group throttle via<br /> perf_event_throttle_group(). All events are stopped: active_mask<br /> bits cleared, events[] preserved (x86_pmu_stop no longer clears<br /> events[] after commit 7e772a93eb61).<br /> <br /> 2. While still throttled (PERF_HES_STOPPED), x86_pmu_enable() runs<br /> due to other scheduling activity. Stopped events that need to<br /> move counters get PERF_HES_ARCH set and events[old_idx] cleared.<br /> In step 2 of x86_pmu_enable(), PERF_HES_ARCH causes these events<br /> to be skipped -- events[new_idx] is never set.<br /> <br /> 3. The timer tick unthrottles the group via pmu-&gt;start(). Since<br /> commit 7e772a93eb61 removed the events[] assignment from<br /> x86_pmu_start(), active_mask[new_idx] is set but events[new_idx]<br /> remains NULL.<br /> <br /> 4. A PMC overflow NMI fires. The handler iterates active counters,<br /> finds active_mask[2] set, reads events[2] which is NULL, and<br /> crashes dereferencing it.<br /> <br /> Move the cpuc-&gt;events[hwc-&gt;idx] assignment in x86_pmu_enable() to<br /> before the PERF_HES_ARCH check, so that events[] is populated even<br /> for events that are not immediately started. This ensures the<br /> unthrottle path via pmu-&gt;start() always finds a valid event pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: shaper: protect from late creation of hierarchy<br /> <br /> We look up a netdev during prep of Netlink ops (pre- callbacks)<br /> and take a ref to it. Then later in the body of the callback<br /> we take its lock or RCU which are the actual protections.<br /> <br /> The netdev may get unregistered in between the time we take<br /> the ref and the time we lock it. We may allocate the hierarchy<br /> after flush has already run, which would lead to a leak.<br /> <br /> Take the instance lock in pre- already, this saves us from the race<br /> and removes the need for dedicated lock/unlock callbacks completely.<br /> After all, if there&amp;#39;s any chance of write happening concurrently<br /> with the flush - we&amp;#39;re back to leaking the hierarchy.<br /> <br /> We may take the lock for devices which don&amp;#39;t support shapers but<br /> we&amp;#39;re only dealing with SET operations here, not taking the lock<br /> would be optimizing for an error case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: shaper: protect late read accesses to the hierarchy<br /> <br /> We look up a netdev during prep of Netlink ops (pre- callbacks)<br /> and take a ref to it. Then later in the body of the callback<br /> we take its lock or RCU which are the actual protections.<br /> <br /> This is not proper, a conversion from a ref to a locked netdev<br /> must include a liveness check (a check if the netdev hasn&amp;#39;t been<br /> unregistered already). Fix the read cases (those under RCU).<br /> Writes needs a separate change to protect from creating the<br /> hierarchy after flush has already run.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mvpp2: guard flow control update with global_tx_fc in buffer switching<br /> <br /> mvpp2_bm_switch_buffers() unconditionally calls<br /> mvpp2_bm_pool_update_priv_fc() when switching between per-cpu and<br /> shared buffer pool modes. This function programs CM3 flow control<br /> registers via mvpp2_cm3_read()/mvpp2_cm3_write(), which dereference<br /> priv-&gt;cm3_base without any NULL check.<br /> <br /> When the CM3 SRAM resource is not present in the device tree (the<br /> third reg entry added by commit 60523583b07c ("dts: marvell: add CM3<br /> SRAM memory to cp11x ethernet device tree")), priv-&gt;cm3_base remains<br /> NULL and priv-&gt;global_tx_fc is false. Any operation that triggers<br /> mvpp2_bm_switch_buffers(), for example an MTU change that crosses<br /> the jumbo frame threshold, will crash:<br /> <br /> Unable to handle kernel NULL pointer dereference at<br /> virtual address 0000000000000000<br /> Mem abort info:<br /> ESR = 0x0000000096000006<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> pc : readl+0x0/0x18<br /> lr : mvpp2_cm3_read.isra.0+0x14/0x20<br /> Call trace:<br /> readl+0x0/0x18<br /> mvpp2_bm_pool_update_fc+0x40/0x12c<br /> mvpp2_bm_pool_update_priv_fc+0x94/0xd8<br /> mvpp2_bm_switch_buffers.isra.0+0x80/0x1c0<br /> mvpp2_change_mtu+0x140/0x380<br /> __dev_set_mtu+0x1c/0x38<br /> dev_set_mtu_ext+0x78/0x118<br /> dev_set_mtu+0x48/0xa8<br /> dev_ifsioc+0x21c/0x43c<br /> dev_ioctl+0x2d8/0x42c<br /> sock_ioctl+0x314/0x378<br /> <br /> Every other flow control call site in the driver already guards<br /> hardware access with either priv-&gt;global_tx_fc or port-&gt;tx_fc.<br /> mvpp2_bm_switch_buffers() is the only place that omits this check.<br /> <br /> Add the missing priv-&gt;global_tx_fc guard to both the disable and<br /> re-enable calls in mvpp2_bm_switch_buffers(), consistent with the<br /> rest of the driver.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udp_tunnel: fix NULL deref caused by udp_sock_create6 when CONFIG_IPV6=n<br /> <br /> When CONFIG_IPV6 is disabled, the udp_sock_create6() function returns 0<br /> (success) without actually creating a socket. Callers such as<br /> fou_create() then proceed to dereference the uninitialized socket<br /> pointer, resulting in a NULL pointer dereference.<br /> <br /> The captured NULL deref crash:<br /> BUG: kernel NULL pointer dereference, address: 0000000000000018<br /> RIP: 0010:fou_nl_add_doit (net/ipv4/fou_core.c:590 net/ipv4/fou_core.c:764)<br /> [...]<br /> Call Trace:<br /> <br /> genl_family_rcv_msg_doit.constprop.0 (net/netlink/genetlink.c:1114)<br /> genl_rcv_msg (net/netlink/genetlink.c:1194 net/netlink/genetlink.c:1209)<br /> [...]<br /> netlink_rcv_skb (net/netlink/af_netlink.c:2550)<br /> genl_rcv (net/netlink/genetlink.c:1219)<br /> netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)<br /> netlink_sendmsg (net/netlink/af_netlink.c:1894)<br /> __sock_sendmsg (net/socket.c:727 (discriminator 1) net/socket.c:742 (discriminator 1))<br /> __sys_sendto (./include/linux/file.h:62 (discriminator 1) ./include/linux/file.h:83 (discriminator 1) net/socket.c:2183 (discriminator 1))<br /> __x64_sys_sendto (net/socket.c:2213 (discriminator 1) net/socket.c:2209 (discriminator 1) net/socket.c:2209 (discriminator 1))<br /> do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))<br /> entry_SYSCALL_64_after_hwframe (net/arch/x86/entry/entry_64.S:130)<br /> <br /> This patch makes udp_sock_create6 return -EPFNOSUPPORT instead, so<br /> callers correctly take their error paths. There is only one caller of<br /> the vulnerable function and only privileged users can trigger it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/sva: Fix crash in iommu_sva_unbind_device()<br /> <br /> domain-&gt;mm-&gt;iommu_mm can be freed by iommu_domain_free():<br /> iommu_domain_free()<br /> mmdrop()<br /> __mmdrop()<br /> mm_pasid_drop()<br /> After iommu_domain_free() returns, accessing domain-&gt;mm-&gt;iommu_mm may<br /> dereference a freed mm structure, leading to a crash.<br /> <br /> Fix this by moving the code that accesses domain-&gt;mm-&gt;iommu_mm to before<br /> the call to iommu_domain_free().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vmwgfx: Don&amp;#39;t overwrite KMS surface dirty tracker<br /> <br /> We were overwriting the surface&amp;#39;s dirty tracker here causing a memory leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: amlogic-spisg: Fix memory leak in aml_spisg_probe()<br /> <br /> In aml_spisg_probe(), ctlr is allocated by<br /> spi_alloc_target()/spi_alloc_host(), but fails to call<br /> spi_controller_put() in several error paths. This leads<br /> to a memory leak whenever the driver fails to probe after<br /> the initial allocation.<br /> <br /> Convert to use devm_spi_alloc_host()/devm_spi_alloc_target()<br /> to fix the memory leak.