Bug 2516262 (CVE-2026-72483) - CVE-2026-72483 kernel: usb: host: max3421: Fix shift-out-of-bounds in max3421_hub_control()
Summary: CVE-2026-72483 kernel: usb: host: max3421: Fix shift-out-of-bounds in max3421...
Keywords:
Status: NEW
Alias: CVE-2026-72483
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-08-15 06:03 UTC by OSIDB Bzimport
Modified: 2026-08-17 14:54 UTC (History)
2 users (show)

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


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-08-15 06:03:16 UTC
In the Linux kernel, the following vulnerability has been resolved:

usb: host: max3421: Fix shift-out-of-bounds in max3421_hub_control()

The `max3421_hub_control()` function handles USB hub class requests
to the virtual root hub. In the `default` branches of both the
`ClearPortFeature` and `SetPortFeature` switch statements, it modifies
`max3421_hcd->port_status` by left shifting 1 by the request's `value`
parameter. However, it does not validate whether this shift will exceed
the width of `port_status`.

So if a malicious userspace task with access to the root hub via
/dev/bus/usb/.../001 issues a USBDEVFS_CONTROL ioctl with `wValue`
greater than or equal to 32, the left shift operation invokes
shift-out-of-bounds undefined behavior. This results in arbitrary
bit corruption of `port_status`, including the normally-immutable
change bits, which can bypass internal state checks and confuse the
hub status.

Fix this by rejecting requests whose `value` exceeds the shift width
before performing the shift.

This issue was found using a KLEE-based symbolic execution tool for
kernel drivers that I'm currently developing.


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