CVE-2022-50709

wifi: ath9k: avoid uninit memory read in ath9k_htc_rx_msg()

N/A
Published: December 24, 2025 at 10:55 AM UTC
Updated: June 17, 2026 at 05:24 AM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
N/A
Exploit prediction
EPSS 0.2%

Description

In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: avoid uninit memory read in ath9k_htc_rx_msg() syzbot is reporting uninit value at ath9k_htc_rx_msg() [1], for ioctl(USB_RAW_IOCTL_EP_WRITE) can call ath9k_hif_usb_rx_stream() with pkt_len = 0 but ath9k_hif_usb_rx_stream() uses __dev_alloc_skb(pkt_len + 32, GFP_ATOMIC) based on an assumption that pkt_len is valid. As a result, ath9k_hif_usb_rx_stream() allocates skb with uninitialized memory and ath9k_htc_rx_msg() is reading from uninitialized memory. Since bytes accessed by ath9k_htc_rx_msg() is not known until ath9k_htc_rx_msg() is called, it would be difficult to check minimal valid pkt_len at "if (pkt_len > 2 * MAX_RX_BUF_SIZE) {" line in ath9k_hif_usb_rx_stream(). We have two choices. One is to workaround by adding __GFP_ZERO so that ath9k_htc_rx_msg() sees 0 if pkt_len is invalid. The other is to let ath9k_htc_rx_msg() validate pkt_len before accessing. This patch chose the latter. Note that I'm not sure threshold condition is correct, for I can't find details on possible packet length used by this protocol.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

2.6.35 ≤ v < 4.14.2962.6.35 ≤ v < 4.19.2622.6.35 ≤ v < 5.10.1502.6.35 ≤ v < 5.15.752.6.35 ≤ v < 5.19.172.6.35 ≤ v < 5.4.2202.6.35 ≤ v < 6.0.32.6.35 ≤ v < 6.12.6.35fb9987d0f748c983bb795a86f47522313f701a08
Vendor states this is fixed in 0d2649b288b7b9484e3d4380c0d6c4720a17e473 (fixed)
Vendor states this is fixed in 2c485f4f2a64258acc5228e78ffb828c68d9e770 (fixed)
Vendor states this is fixed in 4891a50f5ed8bfcb8f2a4b816b0676f398687783 (fixed)
Vendor states this is fixed in 84242f15f911f34aec9b22f99d1e9bff19723dbe (fixed)
Vendor states this is fixed in 9661724f6206bd606ecf13acada676a9975d230b (fixed)
Vendor states this is fixed in b1b4144508adfc585e43856b31baaf9008a3beb4 (fixed)
Vendor states this is fixed in b383e8abed41cc6ff1a3b34de75df9397fa4878c (fixed)
Vendor states this is fixed in f3d2a3b7e290d0bdbddfcee5a6c3d922e2b7e02a (fixed)
Vendor states this is fixed in 2.6.35 (unaffected)
Vendor states this is fixed in 4.14.296 (unaffected)
Vendor states this is fixed in 4.19.262 (unaffected)
Vendor states this is fixed in 5.10.150 (unaffected)
Vendor states this is fixed in 5.15.75 (unaffected)
Vendor states this is fixed in 5.19.17 (unaffected)
Vendor states this is fixed in 5.4.220 (unaffected)
Vendor states this is fixed in 6.0.3 (unaffected)
Vendor states this is fixed in 6.1 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

Quick Info

StatusDEFERRED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card