Description
In the Linux kernel, the following vulnerability has been resolved:

wifi: ath5k: do not access array OOB

Vincent reports:
> The ath5k driver seems to do an array-index-out-of-bounds access as
> shown by the UBSAN kernel message:
> UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath5k/base.c:1741:20
> index 4 is out of range for type 'ieee80211_tx_rate [4]'
> ...
> Call Trace:
> <TASK>
> dump_stack_lvl+0x5d/0x80
> ubsan_epilogue+0x5/0x2b
> __ubsan_handle_out_of_bounds.cold+0x46/0x4b
> ath5k_tasklet_tx+0x4e0/0x560 [ath5k]
> tasklet_action_common+0xb5/0x1c0

It is real. 'ts->ts_final_idx' can be 3 on 5212, so:
info->status.rates[ts->ts_final_idx + 1].idx = -1;
with the array defined as:
struct ieee80211_tx_rate rates[IEEE80211_TX_MAX_RATES];
while the size is:
#define IEEE80211_TX_MAX_RATES 4
is indeed bogus.

Set this 'idx = -1' sentinel only if the array index is less than the
array size. As mac80211 will not look at rates beyond the size
(IEEE80211_TX_MAX_RATES).

Note: The effect of the OOB write is negligible. It just overwrites the
next member of info->status, i.e. ack_signal.
Published: 2026-06-08
Score: n/a
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The ath5k wireless driver performs an array‑index out‑of‑bounds write: the index 4 is written into a four‑element array, overwriting the following buffer member. The write alters a status field (ack_signal) but does not trigger a denial of service or obvious information leakage. Because the driver runs in kernel space, the flaw constitutes a memory corruption condition that could theoretically be manipulated with crafted wireless frames, although no proven exploit currently exists. The security impact is limited to potential data integrity issues within the driver’s state structures.

Affected Systems

Affected systems are all Linux distributions that ship a kernel containing the ath5k driver. The vulnerability is present in any build that has not applied the commit that adds a bounds check before the write. No specific kernel version range is listed, so all kernels prior to the fixed release are susceptible.

Risk and Exploitability

The CVSS score is not supplied and the EPSS score is unavailable, indicating that exploitation likelihood is unknown but likely low. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. The attack requires local or remote control of the wireless traffic processed by the ath5k driver; an attacker would need to craft frames that trigger the out‑of‑bounds write. In the absence of a public exploit, the risk is considered moderate but not critical.

Generated by OpenCVE AI on June 8, 2026 at 18:39 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Update the Linux kernel to the latest stable version that includes the ath5k out‑of‑bounds bounds check patch
  • If the kernel cannot be updated immediately, disable the ath5k driver via modprobe or udev rules to prevent the vulnerable code from loading
  • Consider switching to an alternative wireless driver or hardware if the ath5k driver is required and the system remains on an older kernel

Generated by OpenCVE AI on June 8, 2026 at 18:39 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Mon, 08 Jun 2026 19:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-188
CWE-20

Mon, 08 Jun 2026 17:00:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: wifi: ath5k: do not access array OOB Vincent reports: > The ath5k driver seems to do an array-index-out-of-bounds access as > shown by the UBSAN kernel message: > UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath5k/base.c:1741:20 > index 4 is out of range for type 'ieee80211_tx_rate [4]' > ... > Call Trace: > <TASK> > dump_stack_lvl+0x5d/0x80 > ubsan_epilogue+0x5/0x2b > __ubsan_handle_out_of_bounds.cold+0x46/0x4b > ath5k_tasklet_tx+0x4e0/0x560 [ath5k] > tasklet_action_common+0xb5/0x1c0 It is real. 'ts->ts_final_idx' can be 3 on 5212, so: info->status.rates[ts->ts_final_idx + 1].idx = -1; with the array defined as: struct ieee80211_tx_rate rates[IEEE80211_TX_MAX_RATES]; while the size is: #define IEEE80211_TX_MAX_RATES 4 is indeed bogus. Set this 'idx = -1' sentinel only if the array index is less than the array size. As mac80211 will not look at rates beyond the size (IEEE80211_TX_MAX_RATES). Note: The effect of the OOB write is negligible. It just overwrites the next member of info->status, i.e. ack_signal.
Title wifi: ath5k: do not access array OOB
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-06-08T15:46:35.059Z

Reserved: 2026-05-13T15:03:33.111Z

Link: CVE-2026-46307

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-06-08T17:16:49.547

Modified: 2026-06-08T17:16:49.547

Link: CVE-2026-46307

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-06-08T18:45:26Z

Weaknesses