Cloudanix VulnDB

CVE-2026-43113

High · 8.8

CVSS

8.8

EPSS

0.4%

Published

May 6, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

Some Linux devices using a specific Wi-Fi driver can be crashed or potentially taken over by malicious activity near the wireless connection unless the operating system is updated.

Exploitation
Adjacent Network
Attacker needs
None
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

This flaw is an out-of-bounds array access in the Linux kernel wl1251 Wi-Fi driver. The transmit completion callback, wl1251_tx_packet_cb(), trusts an 8-bit packet completion ID supplied through the device firmware completion path and uses it directly as an index into the fixed 16-entry wl->tx_frames[] array. If the completion ID is 16 or greater, the driver can read or dereference memory outside the intended array. In kernel context, that can lead to memory corruption, kernel crash, or potentially arbitrary kernel memory access depending on surrounding memory layout and exploitability on a given build.

Why it matters to the business

Systems using affected Linux kernels with wl1251 Wi-Fi hardware or the wl1251 driver exposed may be vulnerable to local wireless-adjacent compromise or denial of service. A successful attack could crash affected devices, disrupt connectivity, or in the worst case allow kernel-level compromise of the device. The EPSS score is currently low and there is no CISA KEV listing or known public exploit maturity in the provided data, but the high CVSS rating means exposed embedded, mobile, industrial, or legacy Linux systems using this Wi-Fi chipset should still be prioritized for routine kernel updates.

How an attack unfolds

An attacker must be in a position to influence the wl1251 transmit completion path, most plausibly through proximity to a system using the affected Wi-Fi hardware, by interacting with the wireless device/firmware behavior, or by abusing a compromised or malicious firmware/device completion stream. The vulnerable driver receives a transmit completion block containing a raw packet ID. Instead of validating that the ID is within the 0-15 range of wl->tx_frames[], the vulnerable callback uses the value as an array index. A crafted out-of-range ID can cause the kernel to access memory beyond the transmit-frame tracking array. Depending on kernel configuration, memory layout, hardening features, and the adjacent data structures, this may result in a kernel oops/panic, corrupted driver state, disclosure of kernel memory, or a path toward code execution with kernel privileges. There are no known named threat actors or public exploitation reports in the provided data.

How to fix it

Update to a Linux kernel build that includes the wl1251 fix validating packet IDs before indexing wl->tx_frames[]. No exact fixed kernel versions were provided, so use the corrected kernel packages from the relevant Linux distribution, device vendor, or long-term-stable kernel branch. Where immediate patching is not possible, reduce exposure by disabling the wl1251 driver if not required, blacklisting the wl1251 module, disabling affected Wi-Fi interfaces, or restricting use of affected devices in untrusted wireless environments. For systems that do not use wl1251 hardware, confirm the driver is not loaded and not automatically enabled.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package includes the wl1251 transmit completion bounds-check patch. Validate with vendor advisories, kernel changelogs, or source inspection showing that wl1251_tx_packet_cb() rejects completion IDs outside the wl->tx_frames[] array before dereferencing. On systems, check whether the wl1251 module is present or loaded using tools such as lsmod, modinfo, and kernel package inventory. After patching or mitigation, confirm the device is running the updated kernel, the wl1251 module has been rebuilt or replaced as part of that kernel, and no vulnerable older kernel remains the default boot target.

Typical attack path

  1. Identify a target system running an affected Linux kernel with wl1251 Wi-Fi driver support and relevant hardware enabled.
  2. Gain wireless-adjacent positioning or another path capable of influencing wl1251 firmware/device completion behavior.
  3. Trigger transmit activity on the affected interface so wl1251 transmit completion handling is exercised.
  4. Cause or induce a transmit completion block containing a packet ID outside the valid 0-15 wl->tx_frames[] range.
  5. The kernel driver indexes outside the fixed tx_frames array during wl1251_tx_packet_cb().
  6. Leverage the resulting out-of-bounds access for denial of service, memory corruption, or further kernel-level exploitation where practical.

How to detect it

Retrospective detection is difficult because this vulnerability occurs in kernel driver memory handling and may not leave application-level artifacts. Focus on kernel and system logs, crash dumps, pstore/ramoops records, kdump vmcores, EDR kernel telemetry if available, and Wi-Fi driver reset events. Look for crashes or memory-safety reports involving wl1251_tx_packet_cb(), wl1251 transmit completion handling, tx_frames, or out-of-bounds/NULL-pointer/general-protection faults near Wi-Fi activity. KASAN, UBSAN, kernel oops, panic, or slab corruption messages referencing wl1251 are especially relevant. Correlate suspicious events with physical proximity, unusual wireless activity, interface resets, repeated association/disassociation events, or crashes that occur when the wl1251 interface is active. Because no public exploit, threat actor, or ransomware usage is identified in the provided data, absence of these artifacts does not prove the vulnerability was not attempted; it only reduces evidence of successful or crash-inducing exploitation.

  • wl1251_tx_packet_cb
  • wl1251
  • tx_frames
  • KASAN: out-of-bounds
  • BUG: kernel NULL pointer dereference
  • general protection fault
  • kernel BUG at
  • Unable to handle kernel paging request
  • Oops:
  • Kernel panic - not syncing
  • Call Trace:
  • wl1251_tx_complete
  • wl1251_tx_work
  • wl1251: firmware
  • wl1251: ERROR
  • wlan0: deauthenticated
  • wlan0: disassociated
  • ieee80211 phy

What your security team should do

  • Inventory Linux systems, embedded devices, and appliances that may use wl1251 Wi-Fi hardware or load the wl1251 kernel driver.
  • Prioritize patching systems where wl1251 is loaded, Wi-Fi is enabled, and devices operate in untrusted or physically accessible wireless environments.
  • Apply vendor kernel updates containing the wl1251 packet ID validation fix; reboot where required so the patched kernel is active.
  • If patching is delayed, disable or blacklist the wl1251 driver on systems that do not require it.
  • Monitor kernel logs for wl1251-related crashes, KASAN reports, general protection faults, or repeated Wi-Fi driver resets.
  • For high-assurance environments, treat unexplained kernel crashes in wl1251 transmit completion paths as potential exploitation attempts and preserve logs, crash dumps, and kernel versions for forensic review.
  • Track distribution advisories because fixed version numbers were not provided in the input and may differ by kernel branch or vendor-maintained backport.

The record

In the Linux kernel, the following vulnerability has been resolved: wifi: wl1251: validate packet IDs before indexing tx_frames wl1251_tx_packet_cb() uses the firmware completion ID directly to index the fixed 16-entry wl->tx_frames[] array. The ID is a raw u8 from the completion block, and the callback does not currently verify that it fits the array before dereferencing it. Reject completion IDs that fall outside wl->tx_frames[] and keep the existing NULL check in the same guard. This keeps the fix local to the trust boundary and avoids touching the rest of the completion flow.

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities