CVE-2026-46307

What it actually does

This flaw is an out-of-bounds write in the Linux kernel ath5k wireless driver transmit-completion path. When processing transmit status, the driver can write a sentinel value to rates[ts_final_idx + 1] without first confirming that the calculated index is within the fixed ieee80211_tx_rate rates[4] array. On affected systems using ath5k-supported Atheros wireless chipsets, a crafted or abnormal wireless/driver state can cause the kernel to write past the end of the rates array into the next status field, identified in the upstream description as ack_signal. The upstream note indicates the practical overwrite is limited and likely low impact, but because the write occurs in kernel context, it is still classified as a memory-corruption issue with potential confidentiality, integrity, or stability implications depending on kernel build, hardening, surrounding memory layout, and reachable device state.

Why it matters to the business

Systems using affected Linux kernels with ath5k wireless hardware may be exposed to a kernel-level memory corruption bug reachable from the local wireless network vicinity. The most likely operational consequence is kernel instability or unreliable wireless behavior, but kernel memory corruption can carry higher risk because successful exploitation may affect the operating system itself. The issue is not listed in CISA KEV, is not reported as used in ransomware campaigns, has low EPSS probability, and has no known public exploit maturity in the provided data, so urgency is lower than actively exploited internet-facing flaws; however, wireless-enabled Linux fleets, appliances, embedded devices, and legacy endpoints should still receive kernel fixes through standard patch cycles.

How an attack unfolds

An attacker would need to be within wireless range or otherwise able to influence the ath5k/mac80211 transmit-status handling path on a system using the vulnerable ath5k driver. The attacker’s goal would be to cause the driver to process a transmit status where ts_final_idx reaches the boundary value and the code attempts to set rates[ts_final_idx + 1].idx even though that element is outside the four-entry rates array. If triggered, the write occurs inside the kernel tasklet handler ath5k_tasklet_tx and overwrites adjacent status data, specifically the ack_signal field according to the upstream analysis. In normal conditions this appears to have limited practical effect, but a determined attacker could attempt repeated triggering to cause instability, probe for side effects, or combine the memory corruption with other weaknesses. There is no provided evidence of exploitation in the wild, known threat actor use, ransomware use, or public exploit availability.

How to fix it

Apply a Linux kernel update containing the ath5k bounds-check fix. The corrected logic only writes the idx = -1 sentinel when the calculated rates array index is less than IEEE80211_TX_MAX_RATES. Because no exact affected product list or fixed package versions were provided, use the fixed kernel versions supplied by the relevant Linux distribution, appliance vendor, or kernel maintainer. Where immediate patching is not possible, reduce exposure by disabling the ath5k module if the hardware is not required, removing or disabling affected Atheros wireless adapters, blocking automatic loading of the ath5k module, or preferring wired networking until patched. Kernel hardening, UBSAN/KASAN testing in non-production builds, and standard secure boot/module integrity controls can reduce diagnostic and tampering risk but do not replace patching.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel includes the upstream ath5k bounds-check change or an equivalent vendor backport. Check the installed and running kernel package version against the distribution or vendor advisory for this issue, then reboot into the fixed kernel where required. Validate whether ath5k is present and loaded using module and hardware inventory checks such as lsmod, modinfo ath5k, lspci, and distribution package metadata. If the module is disabled as a mitigation, confirm it is not loaded after reboot and is blocked through the system’s module configuration. In test environments, exercise ath5k wireless functionality and review kernel logs to ensure the previous UBSAN array-index-out-of-bounds warning in drivers/net/wireless/ath/ath5k/base.c no longer appears.

Typical attack path

1. Identify a Linux system that uses an ath5k-supported Atheros wireless adapter and runs an affected kernel build.
2. Get within wireless range of the target device or otherwise create conditions that influence ath5k transmit status processing.
3. Trigger wireless traffic and driver transmit-completion handling involving ath5k_tasklet_tx.
4. Cause ts_final_idx to reach a boundary value where the vulnerable code writes to rates[ts_final_idx + 1] beyond the four-element rates array.
5. Leverage the resulting kernel memory corruption for instability, information exposure, state manipulation, or as part of a broader exploit chain, if a reliable exploitation technique is available.

How to detect it

There are no strong public indicators of successful exploitation provided, and exploitation would likely leave limited application-level evidence because the bug occurs inside the kernel wireless driver. Focus on kernel and system logs from hosts that load ath5k. Review dmesg, journald, syslog, kern.log, crash dumps, pstore, netconsole output, and kernel panic/oops records for UBSAN or KASAN reports naming drivers/net/wireless/ath/ath5k/base.c, ath5k_tasklet_tx, __ubsan_handle_out_of_bounds, array-index-out-of-bounds, or index 4 out of range for ieee80211_tx_rate [4]. Correlate such events with wireless activity, unexpected reboots, kernel taint, ath5k resets, network instability, or proximity to suspicious wireless activity. Because the described overwrite affects ack_signal and may not produce a crash, absence of logs does not prove non-exploitation. If suspicious kernel warnings are found, preserve logs and crash artifacts, record the running kernel version and loaded modules, capture wireless adapter details, and verify whether the system was running a vulnerable kernel at the time.

• UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath5k/base.c
• index 4 is out of range for type 'ieee80211_tx_rate [4]'
• ath5k_tasklet_tx
• __ubsan_handle_out_of_bounds
• drivers/net/wireless/ath/ath5k/base.c:1741
• tasklet_action_common
• ath5k
• ieee80211_tx_rate [4]
• ts->ts_final_idx
• ack_signal

What your security team should do

• Inventory Linux systems, embedded devices, and appliances that use ath5k-supported Atheros wireless chipsets or load the ath5k kernel module.
• Prioritize patching wireless-enabled systems in shared, public, high-density, or physically accessible locations where adjacent wireless attack conditions are easier to meet.
• Upgrade to the vendor-provided fixed kernel release and reboot systems so the corrected kernel is actually running.
• Disable or blacklist the ath5k module on systems that do not require affected wireless hardware.
• Monitor kernel logs for UBSAN, KASAN, oops, panic, or ath5k_tasklet_tx messages that could indicate triggering or attempted triggering.
• Treat detections as potential kernel-memory-corruption events and collect volatile evidence, kernel logs, module lists, wireless configuration, and recent package history before reimaging or rebooting when feasible.
• Track vendor advisories for exact fixed package versions because the provided data does not include per-distribution fixed versions.
• Maintain normal patch urgency rather than emergency KEV-driven escalation unless local exposure is high or new exploit intelligence emerges.