Answer in brief
CVE-2026-64330 records a Unknown severity vulnerability in usb: typec: tcpm: Validate SVID index in svdm_consume_modes(). 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.
Answer in brief
CVE-2026-64330 records a Unknown severity vulnerability in usb: typec: tcpm: Validate SVID index in svdm_consume_modes(). 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 | >=4ab8c18d4d67321cc7b660559de17511d4fc0237 <89ff289cbf5d3b659a2babc5ccaae4eaf7e7cf53 || >=4ab8c18d4d67321cc7b660559de17511d4fc0237 <d638ec188e95fe60f4b01106ffd41958f8fb3c2c || >=4ab8c18d4d67321cc7b660559de17511d4fc0237 <f8163c414de8640f2ca82ce4dc93409d4cdc2fad || >=4ab8c18d4d67321cc7b660559de17511d4fc0237 <012406f89abc52d1d5f07aa5653b519ebf6d2407 || >=4ab8c18d4d67321cc7b660559de17511d4fc0237 <c6d2af3b217a525741c472f0ab45d7d274b8468f || >=4ab8c18d4d67321cc7b660559de17511d4fc0237 <3e1b1ac47e8163627f159f30d80d51b914620dd4 || >=4ab8c18d4d67321cc7b660559de17511d4fc0237 <313ca06e7e224ca1dfadd5722fe71fb8bc276b8b || >=4ab8c18d4d67321cc7b660559de17511d4fc0237 <7b681dd5fbf60b24a13c14661e5b7735759fb491 | 89ff289cbf5d3b659a2babc5ccaae4eaf7e7cf53, d638ec188e95fe60f4b01106ffd41958f8fb3c2c, f8163c414de8640f2ca82ce4dc93409d4cdc2fad, 012406f89abc52d1d5f07aa5653b519ebf6d2407, c6d2af3b217a525741c472f0ab45d7d274b8468f, 3e1b1ac47e8163627f159f30d80d51b914620dd4, 313ca06e7e224ca1dfadd5722fe71fb8bc276b8b, 7b681dd5fbf60b24a13c14661e5b7735759fb491 |
| Linux/Linuxgeneric | 4.19 | Not reported |
Published upstream
Jul 25, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 17, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 11, 2026
In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: Validate SVID index in svdm_consume_modes() In svdm_consume_modes(), the SVID value is read from pmdata->svids using pmdata->svid_index as an array index without bounds validation: paltmode->svid = pmdata->svids[pmdata->svid_index]; If pmdata->svid_index is driven beyond SVID_DISCOVERY_MAX (16), it results in an out-of-bounds read of the pmdata->svids array. Because pd_mode_data is embedded inside struct tcpm_port, indexing past svids reads into adjacent fields. In particular: - At index 16, it reads the altmodes count. - At index 18 and beyond, it reads into altmode_desc[], which contains partner-supplied SVDM Discovery Modes VDOs. By injecting a chosen SVID into altmode_desc[0].vdo and driving svid_index to 20, the partner can force paltmode->svid to be loaded with an arbitrary, partner- chosen SVID, which is then registered via typec_partner_register_altmode(). Fix this by validating that pmdata->svid_index is non-negative and strictly less than pmdata->nsvids before accessing the pmdata->svids array inside svdm_consume_modes().
Quoted source text, attributed separately from HOL analysis.
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 | >=4ab8c18d4d67321cc7b660559de17511d4fc0237 <89ff289cbf5d3b659a2babc5ccaae4eaf7e7cf53 || >=4ab8c18d4d67321cc7b660559de17511d4fc0237 <d638ec188e95fe60f4b01106ffd41958f8fb3c2c || >=4ab8c18d4d67321cc7b660559de17511d4fc0237 <f8163c414de8640f2ca82ce4dc93409d4cdc2fad || >=4ab8c18d4d67321cc7b660559de17511d4fc0237 <012406f89abc52d1d5f07aa5653b519ebf6d2407 || >=4ab8c18d4d67321cc7b660559de17511d4fc0237 <c6d2af3b217a525741c472f0ab45d7d274b8468f || >=4ab8c18d4d67321cc7b660559de17511d4fc0237 <3e1b1ac47e8163627f159f30d80d51b914620dd4 || >=4ab8c18d4d67321cc7b660559de17511d4fc0237 <313ca06e7e224ca1dfadd5722fe71fb8bc276b8b || >=4ab8c18d4d67321cc7b660559de17511d4fc0237 <7b681dd5fbf60b24a13c14661e5b7735759fb491 | 89ff289cbf5d3b659a2babc5ccaae4eaf7e7cf53, d638ec188e95fe60f4b01106ffd41958f8fb3c2c, f8163c414de8640f2ca82ce4dc93409d4cdc2fad, 012406f89abc52d1d5f07aa5653b519ebf6d2407, c6d2af3b217a525741c472f0ab45d7d274b8468f, 3e1b1ac47e8163627f159f30d80d51b914620dd4, 313ca06e7e224ca1dfadd5722fe71fb8bc276b8b, 7b681dd5fbf60b24a13c14661e5b7735759fb491 |
| Linux/Linuxgeneric | 4.19 | Not reported |
Published upstream
Jul 25, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 17, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 11, 2026
In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: Validate SVID index in svdm_consume_modes() In svdm_consume_modes(), the SVID value is read from pmdata->svids using pmdata->svid_index as an array index without bounds validation: paltmode->svid = pmdata->svids[pmdata->svid_index]; If pmdata->svid_index is driven beyond SVID_DISCOVERY_MAX (16), it results in an out-of-bounds read of the pmdata->svids array. Because pd_mode_data is embedded inside struct tcpm_port, indexing past svids reads into adjacent fields. In particular: - At index 16, it reads the altmodes count. - At index 18 and beyond, it reads into altmode_desc[], which contains partner-supplied SVDM Discovery Modes VDOs. By injecting a chosen SVID into altmode_desc[0].vdo and driving svid_index to 20, the partner can force paltmode->svid to be loaded with an arbitrary, partner- chosen SVID, which is then registered via typec_partner_register_altmode(). Fix this by validating that pmdata->svid_index is non-negative and strictly less than pmdata->nsvids before accessing the pmdata->svids array inside svdm_consume_modes().
Quoted source text, attributed separately from HOL analysis.