CVE-2026-63960

What the bug is

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.

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

drivers/usb/typec/tcpm/wcove.c

What this is

USB TYPEC CLASSMAINTAINERS section matched on drivers/usb/typec/ · linux-usb@vger.kernel.org · Maintained

Kernel module

none to look for. The file would have gone into typec_wcove, and Debian does not compile it into that module, so finding typec_wcove in lsmod would say nothing about this CVE.

Check it on the machine

grep -wE 'CONFIG_OF|CONFIG_PCI|CONFIG_TYPEC|CONFIG_TYPEC_TCPM|CONFIG_TYPEC_WCOVE|CONFIG_USB|CONFIG_USB_GADGET|CONFIG_USB_PHY|CONFIG_USB_SUPPORT' /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

Show whether Debian builds this, per release

Debian does not build this code. In 4 releases below, every kernel flavour Debian publishes has the switch off, so the vulnerable file is compiled into no kernel binary Debian ships.

• bookworm, trixie, forky, sidn

n

not enabled on any flavour - this release does not build the code

Build switches

CONFIG_OF, CONFIG_PCI, CONFIG_TYPEC, CONFIG_TYPEC_TCPM, CONFIG_TYPEC_WCOVE, CONFIG_USB, CONFIG_USB_GADGET, CONFIG_USB_PHY, CONFIG_USB_SUPPORT

Reads as

all on means the file is compiled; any one off means it is not.

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Signals

Published

2026-07-19 (3 months ago)source

CVSS

no vector published, unrated

Attack vector

not published

EPSS

0.21%, higher than 10.6% of all CVEssource

CISA KEV

not listedthe KEV catalogue

Debian urgency

not yet assignedsource

Subsystem

drivers/usb

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
4.15	5.10.259	3e632098d052
4.15	5.15.210	f2a1edc0bd14
4.15	6.1.176	6899f5b6d7b8
4.15	6.6.143	5cd0e7ac4eef
4.15	6.12.93	d0e4b8b3c6b7
4.15	6.18.35	e94933dc41b8
4.15	7.0.12	3f9d50c8b02b
4.15	7.1	4af7ad0e6d7a