Bug 2502356 (CVE-2026-63962) - CVE-2026-63962 kernel: usb: typec: tcpm: bound altmode_desc[] per iteration in svdm_consume_modes()
Summary: CVE-2026-63962 kernel: usb: typec: tcpm: bound altmode_desc[] per iteration i...
Keywords:
Status: NEW
Alias: CVE-2026-63962
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-07-19 16:03 UTC by OSIDB Bzimport
Modified: 2026-10-20 20:31 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2026:85321 0 None None None 2026-10-19 21:46:59 UTC
Red Hat Product Errata RHSA-2026:86033 0 None None None 2026-10-20 20:31:13 UTC

Description OSIDB Bzimport 2026-07-19 16:03:42 UTC
In the Linux kernel, the following vulnerability has been resolved:

usb: typec: tcpm: bound altmode_desc[] per iteration in svdm_consume_modes()

svdm_consume_modes() checks pmdata->altmodes against the array size once
before the loop over the count, but forgot to check the bound at every
point in the loop.

In the well-behaved SVDM discovery flow this is harmless because each of
at most SVID_DISCOVERY_MAX SVIDs contributes at most MODE_DISCOVERY_MAX
modes, exactly filling altmode_desc[ALTMODE_DISCOVERY_MAX].  But the
CMDT_RSP_ACK handler in tcpm_pd_svdm() does not correlate an incoming
ACK with any request the port actually sent.  Once port->partner is set,
an unsolicited Discover Modes ACK is consumed unconditionally.  A broken
or malicious port partner can therefore drive altmodes to
ALTMODE_DISCOVERY_MAX - 1 via the normal flow, and then send one extra
Discover Modes ACK with seven VDOs.  Because the pre-loop check passes,
the loop could then writes up to five entries past altmode_desc[].  For
mode_data_prime the next field in struct tcpm_port is the
partner_altmode[] pointer array, which then receives partner-chosen
SVID/VDO bytes.

Move the bound check inside the loop so the array can never be indexed
past ALTMODE_DISCOVERY_MAX regardless of how many VDOs the partner
supplies or how the function was reached.

Comment 3 Jon Orris 2026-10-19 21:46:58 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 10

Via RHSA-2026:85321 https://access.redhat.com/errata/RHSA-2026:85321

Comment 4 Jon Orris 2026-10-20 20:31:12 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9

Via RHSA-2026:86033 https://access.redhat.com/errata/RHSA-2026:86033


Note You need to log in before you can comment on or make changes to this bug.