CVE-2022-50709

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.

This change fixes an uninitialized memory read in ath9k_htc_rx_msg() by validating the received message length before accessing headers and message-specific structures. The issue can be triggered by supplying an invalid/too-short packet length, leading the parser to read uninitialized bytes from an skb. The realistic impact is limited (mostly robustness / potential minor info exposure), and not a direct memory-corruption primitive.

The CVSS score(s) listed for this vulnerability do not reflect the associated product's status, and are included for informational purposes to better understand the severity of this vulnerability.