Bug 2516976 (CVE-2026-74507)

Summary: CVE-2026-74507 kernel: Bluetooth: HIDP: validate numbered report payloads
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: rhel-process-autobot, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in the Linux kernel's Bluetooth Human Interface Device Protocol (HIDP) component. A connected HIDP peer can send a malformed report with only a data transaction header, leading to the use of an uninitialized value in `hidp_session_run()`. This vulnerability could potentially result in a denial of service or information disclosure. Additionally, a peer-controlled byte beyond the declared L2CAP Protocol Data Unit (PDU) could be consumed, causing incorrect processing of HID feature requests.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-08-15 12:42:09 UTC 
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.
Comment 1 gkamathe 2026-08-21 08:06:10 UTC 
Upstream advisory:
https://lore.kernel.org/linux-cve-announce/2026081542-CVE-2026-74507-2e79@gregkh/T