Vulnerabilidades

*** Pendiente de traducción *** 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

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.