CVE-2026-63960

UnknownEPSS 0.21%

Last modified

CVE-2026-63960 is a vulnerability of currently unknown severity. In 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. EPSS estimates a 0.21% chance of exploitation in the next 30 days.

Description

In 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.

Metrics

EPSS Probability
0.21%

11.5th percentile

Probability of exploitation in the next 30 days. Learn more

Affected Software

Source: CNA advisory (CVE.org). NVD analysis pending.

VendorProductVersions
LinuxLinux>= 3c4fb9f169214290ec9a943907321e6265b36f65, < 3e632098d0521257ea965bbd6fde807d9bee5c8a; >= 3c4fb9f169214290ec9a943907321e6265b36f65, < f2a1edc0bd142edabc6c85d88713f2bc178dd317; >= 3c4fb9f169214290ec9a943907321e6265b36f65, < 6899f5b6d7b83ce79a3d331dc61dd31bf73f9c22; >= 3c4fb9f169214290ec9a943907321e6265b36f65, < 5cd0e7ac4eefbdb330f8c72694fe74e63df65552; >= 3c4fb9f169214290ec9a943907321e6265b36f65, < d0e4b8b3c6b7607a16932556eaaca5d5cf69f192; >= 3c4fb9f169214290ec9a943907321e6265b36f65, < e94933dc41b87503bf585c8c6d53d740620eceb9; >= 3c4fb9f169214290ec9a943907321e6265b36f65, < 3f9d50c8b02b4af0646aa892465080f9061fc89c; >= 3c4fb9f169214290ec9a943907321e6265b36f65, < 4af7ad0e6d7aa4403dbb1dac7b9659b0421efcaa
LinuxLinux4.15

References

Timeline

Published
Last Modified
Status
Awaiting Analysis

Frequently Asked Questions

What is CVE-2026-63960?
In 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.
How severe is CVE-2026-63960?
Severity scoring for CVE-2026-63960 is pending analysis. The EPSS model estimates a 0.21% probability of exploitation in the next 30 days.
How do I fix CVE-2026-63960?
Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

How Strix Helps

Related CVEs from 2026

Are you affected by CVE-2026-63960?

Run a free Strix scan to check your systems for this vulnerability.

Scan your code now

Source: NVD / NIST