Answer in brief
CVE-2026-74507 records a Unknown severity vulnerability in Bluetooth: HIDP: validate numbered report payloads. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=0ff1731a1ae51e8e48cd559d70db536281c47f8e <b7ad105d46acd828e424454815e4cd31069e047a || >=0ff1731a1ae51e8e48cd559d70db536281c47f8e <7e7162427659b70ea17cd41b1f79e2e64c246690 || >=0ff1731a1ae51e8e48cd559d70db536281c47f8e <27cc0e603355c585f1e5da8398faa4d36d498188 || >=0ff1731a1ae51e8e48cd559d70db536281c47f8e <9c841f59e10b5d75c398a3fc6b2da448d2a2276b || >=0ff1731a1ae51e8e48cd559d70db536281c47f8e <34f53d27b81a16a02828c8fdfa4e02badc326f17 | b7ad105d46acd828e424454815e4cd31069e047a, 7e7162427659b70ea17cd41b1f79e2e64c246690, 27cc0e603355c585f1e5da8398faa4d36d498188, 9c841f59e10b5d75c398a3fc6b2da448d2a2276b, 34f53d27b81a16a02828c8fdfa4e02badc326f17 |
| Linux/Linuxgeneric | 2.6.39 | Not reported |
Published upstream
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 15, 2026
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.
Quoted source text, attributed separately from HOL analysis.
Answer in brief
CVE-2026-74507 records a Unknown severity vulnerability in Bluetooth: HIDP: validate numbered report payloads. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=0ff1731a1ae51e8e48cd559d70db536281c47f8e <b7ad105d46acd828e424454815e4cd31069e047a || >=0ff1731a1ae51e8e48cd559d70db536281c47f8e <7e7162427659b70ea17cd41b1f79e2e64c246690 || >=0ff1731a1ae51e8e48cd559d70db536281c47f8e <27cc0e603355c585f1e5da8398faa4d36d498188 || >=0ff1731a1ae51e8e48cd559d70db536281c47f8e <9c841f59e10b5d75c398a3fc6b2da448d2a2276b || >=0ff1731a1ae51e8e48cd559d70db536281c47f8e <34f53d27b81a16a02828c8fdfa4e02badc326f17 | b7ad105d46acd828e424454815e4cd31069e047a, 7e7162427659b70ea17cd41b1f79e2e64c246690, 27cc0e603355c585f1e5da8398faa4d36d498188, 9c841f59e10b5d75c398a3fc6b2da448d2a2276b, 34f53d27b81a16a02828c8fdfa4e02badc326f17 |
| Linux/Linuxgeneric | 2.6.39 | Not reported |
Published upstream
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 15, 2026
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.
Quoted source text, attributed separately from HOL analysis.