GHSA-5MQJ-JPM9-CHWP
Vulnerability from github – Published: 2026-07-19 18:31 – Updated: 2026-07-19 18:31In the Linux kernel, the following vulnerability has been resolved:
usb: typec: wcove: don't write past struct pd_message in wcove_read_rx_buffer()
wcove_read_rx_buffer() copies the PD RX FIFO into the caller's struct pd_message with
for (i = 0; i < USBC_RXINFO_RXBYTES(info); i++)
regmap_read(wcove->regmap, USBC_RX_DATA + i, msg + i);
which has two problems:
USBC_RXINFO_RXBYTES() is a 5-bit field (max 31) while struct pd_message is 30 bytes (__le16 header + __le32 payload[PD_MAX_PAYLOAD], packed). The byte count latched in RXINFO is the number of bytes the port partner put on the wire, so a malicious partner that transmits a 31-byte frame can drive the loop one byte past the destination if the WCOVE BMC receiver does not enforce the PD object-count limit in hardware. The existing FIXME flagged this as unverified.
Independently, regmap_read() takes an unsigned int * and stores a full unsigned int at the destination. Passing the byte pointer msg + i means each iteration writes four bytes; the high three are zero (val_bits is 8) and are normally overwritten by the next iteration, but the final iteration's high bytes are not. With RXBYTES == 30 the i == 29 iteration already writes three zero bytes past msg, which sits on the IRQ thread's stack in wcove_typec_irq().
Clamp the loop to sizeof(struct pd_message) and read each register into a local before storing only its low byte, so the copy can never exceed the destination regardless of what RXINFO reports.
{
"affected": [],
"aliases": [
"CVE-2026-63960"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-19T16:17:14Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: wcove: don\u0027t write past struct pd_message in wcove_read_rx_buffer()\n\nwcove_read_rx_buffer() copies the PD RX FIFO into the caller\u0027s\nstruct pd_message with\n\n\tfor (i = 0; i \u003c USBC_RXINFO_RXBYTES(info); i++)\n\t\tregmap_read(wcove-\u003eregmap, USBC_RX_DATA + i, msg + i);\n\nwhich has two problems:\n\nUSBC_RXINFO_RXBYTES() is a 5-bit field (max 31) while struct pd_message\nis 30 bytes (__le16 header + __le32 payload[PD_MAX_PAYLOAD], packed).\nThe byte count latched in RXINFO is the number of bytes the port partner\nput on the wire, so a malicious partner that transmits a 31-byte frame\ncan drive the loop one byte past the destination if the WCOVE BMC\nreceiver does not enforce the PD object-count limit in hardware. The\nexisting FIXME flagged this as unverified.\n\nIndependently, regmap_read() takes an unsigned int * and stores a full\nunsigned int at the destination. Passing the byte pointer msg + i means\neach iteration writes four bytes; the high three are zero (val_bits is\n8) and are normally overwritten by the next iteration, but the final\niteration\u0027s high bytes are not. With RXBYTES == 30 the i == 29 iteration\nalready writes three zero bytes past msg, which sits on the IRQ thread\u0027s\nstack in wcove_typec_irq().\n\nClamp the loop to sizeof(struct pd_message) and read each register into\na local before storing only its low byte, so the copy can never exceed\nthe destination regardless of what RXINFO reports.",
"id": "GHSA-5mqj-jpm9-chwp",
"modified": "2026-07-19T18:31:48Z",
"published": "2026-07-19T18:31:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63960"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3e632098d0521257ea965bbd6fde807d9bee5c8a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3f9d50c8b02b4af0646aa892465080f9061fc89c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4af7ad0e6d7aa4403dbb1dac7b9659b0421efcaa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5cd0e7ac4eefbdb330f8c72694fe74e63df65552"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6899f5b6d7b83ce79a3d331dc61dd31bf73f9c22"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d0e4b8b3c6b7607a16932556eaaca5d5cf69f192"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e94933dc41b87503bf585c8c6d53d740620eceb9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f2a1edc0bd142edabc6c85d88713f2bc178dd317"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date | Other |
|---|
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.