Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: core: fix locking in regulator_resolve_supply() error path<br /> <br /> If late enabling of a supply regulator fails in<br /> regulator_resolve_supply(), the code currently triggers a lockdep<br /> warning:<br /> <br /> WARNING: drivers/regulator/core.c:2649 at _regulator_put+0x80/0xa0, CPU#6: kworker/u32:4/596<br /> ...<br /> Call trace:<br /> _regulator_put+0x80/0xa0 (P)<br /> regulator_resolve_supply+0x7cc/0xbe0<br /> regulator_register_resolve_supply+0x28/0xb8<br /> <br /> as the regulator_list_mutex must be held when calling _regulator_put().<br /> <br /> To solve this, simply switch to using regulator_put().<br /> <br /> While at it, we should also make sure that no concurrent access happens<br /> to our rdev while we clear out the supply pointer. Add appropriate<br /> locking to ensure that.<br /> <br /> While the code in question will be removed altogether in a follow-up<br /> commit, I believe it is still beneficial to have this corrected before<br /> removal for future reference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_inner: Fix IPv6 inner_thoff desync<br /> <br /> In nft_inner_parse_l2l3(), when processing inner IPv6 packets,<br /> ipv6_find_hdr() correctly computes the transport header offset<br /> traversing all extension headers, but the result is immediately<br /> overwritten with nhoff + sizeof(_ip6h) (40 bytes), which only<br /> accounts for the IPv6 base header. This creates a desync between<br /> inner_thoff (wrong — points to extension header start) and l4proto<br /> (correct — e.g., IPPROTO_TCP), enabling transport header forgery<br /> and potential firewall bypass. This issue affects stable versions<br /> from Linux 6.2.<br /> <br /> For comparison, the normal (non-inner) IPv6 path correctly<br /> preserves ipv6_find_hdr()&amp;#39;s result. Removing the incorrect overwrite<br /> ensures that ipv6_find_hdr()&amp;#39;s calculated transport header offset is<br /> preserved, thereby fixing the desynchronization.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix dc_link NULL handling in HPD init<br /> <br /> amdgpu_dm_hpd_init() may see connectors without a valid dc_link.<br /> <br /> The code already checks dc_link for the polling decision, but later<br /> unconditionally dereferences it when setting up HPD interrupts.<br /> <br /> Assign dc_link early and skip connectors where it is NULL.<br /> <br /> Fixes the below:<br /> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_irq.c:940 amdgpu_dm_hpd_init()<br /> error: we previously assumed &amp;#39;dc_link&amp;#39; could be null (see line 931)<br /> <br /> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_irq.c<br /> 923 /*<br /> 924 * Analog connectors may be hot-plugged unlike other connector<br /> 925 * types that don&amp;#39;t support HPD. Only poll analog connectors.<br /> 926 */<br /> 927 use_polling |=<br /> 928 amdgpu_dm_connector-&gt;dc_link &amp;&amp;<br /> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The patch adds this NULL check but hopefully it can be removed<br /> <br /> 929 dc_connector_supports_analog(amdgpu_dm_connector-&gt;dc_link-&gt;link_id.id);<br /> 930<br /> 931 dc_link = amdgpu_dm_connector-&gt;dc_link;<br /> <br /> dc_link assigned here.<br /> <br /> 932<br /> 933 /*<br /> 934 * Get a base driver irq reference for hpd ints for the lifetime<br /> 935 * of dm. Note that only hpd interrupt types are registered with<br /> 936 * base driver; hpd_rx types aren&amp;#39;t. IOW, amdgpu_irq_get/put on<br /> 937 * hpd_rx isn&amp;#39;t available. DM currently controls hpd_rx<br /> 938 * explicitly with dc_interrupt_set()<br /> 939 */<br /> --&gt; 940 if (dc_link-&gt;irq_source_hpd != DC_IRQ_SOURCE_INVALID) {<br /> ^^^^^^^^^^^^^^^^^^^^^^^ If it&amp;#39;s NULL then we are trouble because we dereference it here.<br /> <br /> 941 irq_type = dc_link-&gt;irq_source_hpd - DC_IRQ_SOURCE_HPD1;<br /> 942 /*<br /> 943 * TODO: There&amp;#39;s a mismatch between mode_info.num_hpd<br /> 944 * and what bios reports as the # of connectors with hpd

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> power: supply: pm8916_lbc: Fix use-after-free for extcon in IRQ handler<br /> <br /> Using the `devm_` variant for requesting IRQ _before_ the `devm_`<br /> variant for allocating/registering the `extcon` handle, means that the<br /> `extcon` handle will be deallocated/unregistered _before_ the interrupt<br /> handler (since `devm_` naturally deallocates in reverse allocation<br /> order). This means that during removal, there is a race condition where<br /> an interrupt can fire just _after_ the `extcon` handle has been<br /> freed, *but* just _before_ the corresponding unregistration of the IRQ<br /> handler has run.<br /> <br /> This will lead to the IRQ handler calling `extcon_set_state_sync()` with<br /> a freed `extcon` handle. Which usually crashes the system or otherwise<br /> silently corrupts the memory...<br /> <br /> Fix this racy use-after-free by making sure the IRQ is requested _after_<br /> the registration of the `extcon` handle.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: qcom: gfx3d: add parent to parent request map<br /> <br /> After commit d228ece36345 ("clk: divider: remove round_rate() in favor<br /> of determine_rate()") determining GFX3D clock rate crashes, because the<br /> passed parent map doesn&amp;#39;t provide the expected best_parent_hw clock<br /> (with the roundd_rate path before the offending commit the<br /> best_parent_hw was ignored).<br /> <br /> Set the field in parent_req in addition to setting it in the req,<br /> fixing the crash.<br /> <br /> clk_hw_round_rate (drivers/clk/clk.c:1764) (P)<br /> clk_divider_bestdiv (drivers/clk/clk-divider.c:336)<br /> divider_determine_rate (drivers/clk/clk-divider.c:358)<br /> clk_alpha_pll_postdiv_determine_rate (drivers/clk/qcom/clk-alpha-pll.c:1275)<br /> clk_core_determine_round_nolock (drivers/clk/clk.c:1606)<br /> clk_core_round_rate_nolock (drivers/clk/clk.c:1701)<br /> __clk_determine_rate (drivers/clk/clk.c:1741)<br /> clk_gfx3d_determine_rate (drivers/clk/qcom/clk-rcg2.c:1268)<br /> clk_core_determine_round_nolock (drivers/clk/clk.c:1606)<br /> clk_core_round_rate_nolock (drivers/clk/clk.c:1701)<br /> clk_core_round_rate_nolock (drivers/clk/clk.c:1710)<br /> clk_round_rate (drivers/clk/clk.c:1804)<br /> dev_pm_opp_set_rate (drivers/opp/core.c:1440 (discriminator 1))<br /> msm_devfreq_target (drivers/gpu/drm/msm/msm_gpu_devfreq.c:51)<br /> devfreq_set_target (drivers/devfreq/devfreq.c:360)<br /> devfreq_update_target (drivers/devfreq/devfreq.c:426)<br /> devfreq_monitor (drivers/devfreq/devfreq.c:458)<br /> process_one_work (arch/arm64/include/asm/jump_label.h:36 include/trace/events/workqueue.h:110 kernel/workqueue.c:3284)<br /> worker_thread (kernel/workqueue.c:3356 (discriminator 2) kernel/workqueue.c:3443 (discriminator 2))<br /> kthread (kernel/kthread.c:467)<br /> ret_from_fork (arch/arm64/kernel/entry.S:861)

Mercusys AC12G (EU) V1 with firmware AC12G(EU)_V1_200909 responds to version.bind CHAOS TXT queries, disclosing the DNS resolver software version (unbound 1.22.0), aiding targeted attacks against known vulnerabilities.

A Cross Site Scripting vulnerability exists in the Kimi AI v1.0 web interface&amp;#39;s &amp;#39;Preview&amp;#39; feature. The application fails to properly sanitize or encode HTML/JavaScript payloads generated by the AI model. When a user switches to the &amp;#39;Preview&amp;#39; tab to view AI-generated code, the malicious payload is rendered directly into the DOM, leading to arbitrary JavaScript execution in the victim&amp;#39;s browser session.

OP-TEE is a Trusted Execution Environment (TEE) designed as companion to a non-secure Linux kernel running on Arm; Cortex-A cores using the TrustZone technology. Starting in version 3.16.0 and prior to 4.11.0, a user-after-free (UAF) race condition exists in the shared memory teardown logic of FF-A within OP-TEE SPMC/SP flows. This only applies when OP-TEE is configured as an SPMC for S-EL0 SPs, that is, with `CFG_SECURE_PARTITION=y`. The function `sp_mem_remove()`, responsible for freeing entries in `smem-&gt;receivers` and `smem-&gt;regions`, fails to acquire the global `sp_mem_lock` before performing the `free()` operations. Concurrently, other code paths, such as `sp_mem_get_receiver()`, iterate over these same lists without holding a lock, or, like `sp_mem_is_shared()`, iterate while holding the lock but are not serialized against the unprotected `free()` in `sp_mem_remove()`. This creates a cross-thread race where a thread iterating the list can acquire a pointer to an entry (e.g., `struct sp_mem_map_region` or `struct sp_mem_receiver`), and then another thread calls `sp_mem_remove()`, freeing the object. When the first thread resumes and dereferences the pointer, it results in a Use-After-Free vulnerability. Version 4.11.0 fixes the issue.

Mercusys AC12G (EU) V1 router with firmware AC12G(EU)_V1_200909 uses a static authentication nonce that does not change between requests from the same source IP. Combined with the predictable XOR-based password encoding (securityEncode function), this allows an attacker to reverse captured authentication tokens to recover the plaintext password.

Mercusys AC12G (EU) V1 with firmware AC12G(EU)_V1_200909 transmits DDNS credentials over plaintext HTTP with only Base64 encoding. The firmware contains no TLS implementation, allowing man-in-the-middle interception of DDNS service credentials.

Mercusys AC12G (EU) V1 with firmware AC12G(EU)_V1_200909 returns 128 bytes of uninitialized buffer when receiving POST requests without SOAPAction header on UPnP port 1900, exposing internal memory to unauthenticated adjacent network attackers.

Mercusys AC12G (EU) V1 with firmware AC12G(EU)_V1_200909 enables WPS 2.0 by default with a weak lockout policy (60-second lockout after 10 attempts).