GHSA-CPM8-MRMC-3W57

Vulnerability from github – Published: 2025-12-24 12:30 – Updated: 2025-12-24 12:30
VLAI?
Details

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.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-50709"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-24T11:15:51Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath9k: avoid uninit memory read in ath9k_htc_rx_msg()\n\nsyzbot is reporting uninit value at ath9k_htc_rx_msg() [1], for\nioctl(USB_RAW_IOCTL_EP_WRITE) can call ath9k_hif_usb_rx_stream() with\npkt_len = 0 but ath9k_hif_usb_rx_stream() uses\n__dev_alloc_skb(pkt_len + 32, GFP_ATOMIC) based on an assumption that\npkt_len is valid. As a result, ath9k_hif_usb_rx_stream() allocates skb\nwith uninitialized memory and ath9k_htc_rx_msg() is reading from\nuninitialized memory.\n\nSince bytes accessed by ath9k_htc_rx_msg() is not known until\nath9k_htc_rx_msg() is called, it would be difficult to check minimal valid\npkt_len at \"if (pkt_len \u003e 2 * MAX_RX_BUF_SIZE) {\" line in\nath9k_hif_usb_rx_stream().\n\nWe have two choices. One is to workaround by adding __GFP_ZERO so that\nath9k_htc_rx_msg() sees 0 if pkt_len is invalid. The other is to let\nath9k_htc_rx_msg() validate pkt_len before accessing. This patch chose\nthe latter.\n\nNote that I\u0027m not sure threshold condition is correct, for I can\u0027t find\ndetails on possible packet length used by this protocol.",
  "id": "GHSA-cpm8-mrmc-3w57",
  "modified": "2025-12-24T12:30:26Z",
  "published": "2025-12-24T12:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50709"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0d2649b288b7b9484e3d4380c0d6c4720a17e473"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2c485f4f2a64258acc5228e78ffb828c68d9e770"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4891a50f5ed8bfcb8f2a4b816b0676f398687783"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/84242f15f911f34aec9b22f99d1e9bff19723dbe"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9661724f6206bd606ecf13acada676a9975d230b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b1b4144508adfc585e43856b31baaf9008a3beb4"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b383e8abed41cc6ff1a3b34de75df9397fa4878c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f3d2a3b7e290d0bdbddfcee5a6c3d922e2b7e02a"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Detection rules are retrieved from Rulezet.