Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: mtk_eth_soc: Reset prog ptr to old_prog in case of error in mtk_xdp_setup()<br /> <br /> Reset eBPF program pointer to old_prog and do not decrease its ref-count<br /> if mtk_open routine in mtk_xdp_setup() fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drbd: fix null-pointer dereference on local read error<br /> <br /> In drbd_request_endio(), READ_COMPLETED_WITH_ERROR is passed to<br /> __req_mod() with a NULL peer_device:<br /> <br /> __req_mod(req, what, NULL, &amp;m);<br /> <br /> The READ_COMPLETED_WITH_ERROR handler then unconditionally passes this<br /> NULL peer_device to drbd_set_out_of_sync(), which dereferences it,<br /> causing a null-pointer dereference.<br /> <br /> Fix this by obtaining the peer_device via first_peer_device(device),<br /> matching how drbd_req_destroy() handles the same situation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> atm: lec: fix null-ptr-deref in lec_arp_clear_vccs<br /> <br /> syzkaller reported a null-ptr-deref in lec_arp_clear_vccs().<br /> This issue can be easily reproduced using the syzkaller reproducer.<br /> <br /> In the ATM LANE (LAN Emulation) module, the same atm_vcc can be shared by<br /> multiple lec_arp_table entries (e.g., via entry-&gt;vcc or entry-&gt;recv_vcc).<br /> When the underlying VCC is closed, lec_vcc_close() iterates over all<br /> ARP entries and calls lec_arp_clear_vccs() for each matched entry.<br /> <br /> For example, when lec_vcc_close() iterates through the hlists in<br /> priv-&gt;lec_arp_empty_ones or other ARP tables:<br /> <br /> 1. In the first iteration, for the first matched ARP entry sharing the VCC,<br /> lec_arp_clear_vccs() frees the associated vpriv (which is vcc-&gt;user_back)<br /> and sets vcc-&gt;user_back to NULL.<br /> 2. In the second iteration, for the next matched ARP entry sharing the same<br /> VCC, lec_arp_clear_vccs() is called again. It obtains a NULL vpriv from<br /> vcc-&gt;user_back (via LEC_VCC_PRIV(vcc)) and then attempts to dereference it<br /> via `vcc-&gt;pop = vpriv-&gt;old_pop`, leading to a null-ptr-deref crash.<br /> <br /> Fix this by adding a null check for vpriv before dereferencing<br /> it. If vpriv is already NULL, it means the VCC has been cleared<br /> by a previous call, so we can safely skip the cleanup and just<br /> clear the entry&amp;#39;s vcc/recv_vcc pointers.<br /> <br /> The entire cleanup block (including vcc_release_async()) is placed inside<br /> the vpriv guard because a NULL vpriv indicates the VCC has already been<br /> fully released by a prior iteration — repeating the teardown would<br /> redundantly set flags and trigger callbacks on an already-closing socket.<br /> <br /> The Fixes tag points to the initial commit because the entry-&gt;vcc path has<br /> been vulnerable since the original code. The entry-&gt;recv_vcc path was later<br /> added by commit 8d9f73c0ad2f ("atm: fix a memory leak of vcc-&gt;user_back")<br /> with the same pattern, and both paths are fixed here.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> irqchip/sifive-plic: Fix frozen interrupt due to affinity setting<br /> <br /> PLIC ignores interrupt completion message for disabled interrupt, explained<br /> by the specification:<br /> <br /> The PLIC signals it has completed executing an interrupt handler by<br /> writing the interrupt ID it received from the claim to the<br /> claim/complete register. The PLIC does not check whether the completion<br /> ID is the same as the last claim ID for that target. If the completion<br /> ID does not match an interrupt source that is currently enabled for<br /> the target, the completion is silently ignored.<br /> <br /> This caused problems in the past, because an interrupt can be disabled<br /> while still being handled and plic_irq_eoi() had no effect. That was fixed<br /> by checking if the interrupt is disabled, and if so enable it, before<br /> sending the completion message. That check is done with irqd_irq_disabled().<br /> <br /> However, that is not sufficient because the enable bit for the handling<br /> hart can be zero despite irqd_irq_disabled(d) being false. This can happen<br /> when affinity setting is changed while a hart is still handling the<br /> interrupt.<br /> <br /> This problem is easily reproducible by dumping a large file to uart (which<br /> generates lots of interrupts) and at the same time keep changing the uart<br /> interrupt&amp;#39;s affinity setting. The uart port becomes frozen almost<br /> instantaneously.<br /> <br /> Fix this by checking PLIC&amp;#39;s enable bit instead of irqd_irq_disabled().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> IB/mthca: Add missed mthca_unmap_user_db() for mthca_create_srq()<br /> <br /> Fix a user triggerable leak on the system call failure path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/amdxdna: Prevent ubuf size overflow<br /> <br /> The ubuf size calculation may overflow, resulting in an undersized<br /> allocation and possible memory corruption.<br /> <br /> Use check_add_overflow() helpers to validate the size calculation before<br /> allocation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: fix NULL pointer dereference in mesh_rx_csa_frame()<br /> <br /> In mesh_rx_csa_frame(), elems-&gt;mesh_chansw_params_ie is dereferenced<br /> at lines 1638 and 1642 without a prior NULL check:<br /> <br /> ifmsh-&gt;chsw_ttl = elems-&gt;mesh_chansw_params_ie-&gt;mesh_ttl;<br /> ...<br /> pre_value = le16_to_cpu(elems-&gt;mesh_chansw_params_ie-&gt;mesh_pre_value);<br /> <br /> The mesh_matches_local() check above only validates the Mesh ID,<br /> Mesh Configuration, and Supported Rates IEs. It does not verify the<br /> presence of the Mesh Channel Switch Parameters IE (element ID 118).<br /> When a received CSA action frame omits that IE, ieee802_11_parse_elems()<br /> leaves elems-&gt;mesh_chansw_params_ie as NULL, and the unconditional<br /> dereference causes a kernel NULL pointer dereference.<br /> <br /> A remote mesh peer with an established peer link (PLINK_ESTAB) can<br /> trigger this by sending a crafted SPECTRUM_MGMT/CHL_SWITCH action frame<br /> that includes a matching Mesh ID and Mesh Configuration IE but omits the<br /> Mesh Channel Switch Parameters IE. No authentication beyond the default<br /> open mesh peering is required.<br /> <br /> Crash confirmed on kernel 6.17.0-5-generic via mac80211_hwsim:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> RIP: 0010:ieee80211_mesh_rx_queued_mgmt+0x143/0x2a0 [mac80211]<br /> CR2: 0000000000000000<br /> <br /> Fix by adding a NULL check for mesh_chansw_params_ie after<br /> mesh_matches_local() returns, consistent with how other optional IEs<br /> are guarded throughout the mesh code.<br /> <br /> The bug has been present since v3.13 (released 2014-01-19).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: libertas: fix use-after-free in lbs_free_adapter()<br /> <br /> The lbs_free_adapter() function uses timer_delete() (non-synchronous)<br /> for both command_timer and tx_lockup_timer before the structure is<br /> freed. This is incorrect because timer_delete() does not wait for<br /> any running timer callback to complete.<br /> <br /> If a timer callback is executing when lbs_free_adapter() is called,<br /> the callback will access freed memory since lbs_cfg_free() frees the<br /> containing structure immediately after lbs_free_adapter() returns.<br /> <br /> Both timer callbacks (lbs_cmd_timeout_handler and lbs_tx_lockup_handler)<br /> access priv-&gt;driver_lock, priv-&gt;cur_cmd, priv-&gt;dev, and other fields,<br /> which would all be use-after-free violations.<br /> <br /> Use timer_delete_sync() instead to ensure any running timer callback<br /> has completed before returning.<br /> <br /> This bug was introduced in commit 8f641d93c38a ("libertas: detect TX<br /> lockups and reset hardware") where del_timer() was used instead of<br /> del_timer_sync() in the cleanup path. The command_timer has had the<br /> same issue since the driver was first written.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix oops due to uninitialised var in smb2_unlink()<br /> <br /> If SMB2_open_init() or SMB2_close_init() fails (e.g. reconnect), the<br /> iovs set @rqst will be left uninitialised, hence calling<br /> SMB2_open_free(), SMB2_close_free() or smb2_set_related() on them will<br /> oops.<br /> <br /> Fix this by initialising @close_iov and @open_iov before setting them<br /> in @rqst.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: fp9931: Fix PM runtime reference leak in fp9931_hwmon_read()<br /> <br /> In fp9931_hwmon_read(), if regmap_read() failed, the function returned<br /> the error code without calling pm_runtime_put_autosuspend(), causing<br /> a PM reference leak.

Sending a maliciously crafted message to the kea-ctrl-agent, kea-dhcp-ddns, kea-dhcp4, or kea-dhcp6 daemons over any configured API socket or HA listener can cause the receiving daemon to exit with a stack overflow error.<br /> This issue affects Kea versions 2.6.0 through 2.6.4 and 3.0.0 through 3.0.2.

SHARP routers do not perform authentication for some web APIs. The device information may be retrieved without authentication. If the administrative password of the device is left as the initial one, the device may be taken over.