CVE-2026-90361

What it actually does

Unconditional allocation of svc_rdy_ext.mac_phy_caps during TLV parsing in ath11k_service_ready_ext_event() without a corresponding kfree on later parse errors, resulting in a kernel memory leak on the failure path.

Why it matters to the business

Gradual kernel memory exhaustion on systems using the ath11k Wi-Fi driver when repeated error conditions occur during service-ready event processing, potentially leading to performance degradation or instability over time; low exploitation likelihood given EPSS of 0.0021 with no trend and absence from KEV.

How an attack unfolds

An attacker triggers partial success in TLV parsing of the service-ready-ext event (for example via crafted firmware responses or hardware events) to allocate mac_phy_caps, then forces a subsequent parse failure so the allocation is never freed; no named threat actors or ransomware use reported.

How to fix it

Apply the upstream kernel fix that adds the missing free of mac_phy_caps on the error path in ath11k_service_ready_ext_event(); recompile and deploy updated kernels containing the resolution for all affected ath11k devices.

How to confirm the fix worked

Inspect the patched ath11k_service_ready_ext_event() source to confirm kfree(svc_rdy_ext.mac_phy_caps) exists on every error exit after allocation; test by injecting parse failures after the allocation point and verifying no net memory increase via slabinfo or kmemleak.

Typical attack path

1. Induce entry into ath11k_service_ready_ext_event() with TLV data
2. Achieve allocation of mac_phy_caps during parsing
3. Cause a later TLV parse failure
4. Exit error path without freeing the allocation
5. Repeat to accumulate leaked kernel memory

How to detect it

Review kernel logs for ath11k service-ready-ext event errors coinciding with TLV parse failures; track slab or kmemleak reports for repeated mac_phy_caps allocations without frees; no widespread exploitation artifacts expected given low EPSS and compile-tested-only status.

What your security team should do

• Patch all Linux kernels containing the ath11k driver to the fixed version as soon as available
• Monitor kernel memory statistics on wireless-enabled hosts for unexplained growth under error conditions
• Prioritize systems with high-uptime ath11k hardware given 37 days since publication