Description

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: HIDP: validate numbered report payloads When hidp_get_raw_report() waits for a numbered report, hidp_process_data() compares the expected report number with skb->data[0]. A connected HIDP peer can reply with only a DATA transaction header, leaving the skb empty after the header is removed. KMSAN reports an uninitialized-value use in hidp_session_run(), with the value originating in __alloc_skb() through vhci_write(). The transaction header checks remove the empty-frame reports, but this report remains until the payload check is added. The comparison can also consume a peer-controlled byte beyond the declared L2CAP PDU. A DATA | FEATURE response followed by an extra 0x01 byte made the current code accept that byte as report ID 1 and complete HIDIOCGFEATURE with a zero-byte result. With this change the malformed response is rejected with -EIO, while a subsequent valid response still succeeds. Require a payload byte before comparing a numbered report ID. Unnumbered reports continue to accept an empty payload.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-08-15T13:17:55.733Z",
  "pubdate": "2026-08-15T13:17:55.733Z",
  "executiveSummary": "A vulnerability has been identified in the Linux kernel Bluetooth subsystem involving the HIDP (Human Interface Device Protocol) implementation. The flaw specifically relates to insufficient validation of numbered report payloads received from connected HIDP peers.\nThe vulnerability manifests as an uninitialized-value use and an out-of-bounds read condition, categorized broadly as an input validation failure. An attacker with the ability to connect as a malicious HIDP peer can exploit this issue by sending specially crafted or empty frames in response to raw report requests.\nSuccessful exploitation can lead to kernel memory exposure via uninitialized values originating from kmalloc or slab allocations, or unexpected protocol handling resulting in input consumption beyond the declared L2CAP PDU boundaries. The impact includes potential information disclosure and denial of service within the affected kernel space.\nThe vulnerability affects systems running the Linux kernel with Bluetooth HIDP support enabled. Exploitation requires the attacker to be in proximity or connected via Bluetooth to establish an HIDP session and interact with the vulnerable parsing logic in the kernel.",
  "technicalDetails": "The vulnerable component is the Bluetooth HIDP implementation within the Linux kernel, specifically within the report processing logic involving hidp_get_raw_report() and hidp_process_data().\nThe root cause of the vulnerability stems from improper validation of received socket buffers (skb) when handling numbered report payloads. When hidp_get_raw_report() waits for a numbered report, hidp_process_data() attempts to compare the expected report number against skb->data[0].\nHowever, a connected malicious HIDP peer can reply with only a DATA transaction header, leaving the skb empty after the header is stripped. This results in KMSAN reporting an uninitialized-value use in hidp_session_run(), with the underlying value originating from __alloc_skb() through vhci_write() due to the lack of payload length verification.\nFurthermore, the comparison logic can consume a peer-controlled byte beyond the declared L2CAP Protocol Data Unit (PDU). For instance, a DATA | FEATURE response followed by an extra 0x01 byte caused the legacy implementation to incorrectly accept that byte as report ID 1, completing the HIDIOCGFEATURE operation with a zero-byte result.\nThe step-by-step attack flow involves the following mechanics: 1. The local system initiates a raw report request for a numbered HID report. 2. A connected malicious Bluetooth HIDP peer responds with a truncated data packet containing only a transaction header or a malformed payload with trailing bytes beyond the declared L2CAP PDU. 3. The kernel processes the packet via hidp_process_data() without validating whether a payload byte actually exists alongside the header. 4. The uninitialized byte or out-of-bounds byte is read from skb->data[0], triggering an uninitialized-value usage condition or an invalid memory consumption state, which ultimately rejects or mishandles the request while exposing kernel execution stability to anomalies."
}