Answer in brief
CVE-2026-72483 records a Unknown severity vulnerability in usb: host: max3421: Fix shift-out-of-bounds in max3421_hub_control(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
Answer in brief
CVE-2026-72483 records a Unknown severity vulnerability in usb: host: max3421: Fix shift-out-of-bounds in max3421_hub_control(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=2d53139f31626bad6f8983d8e519ddde2cbba921 <e5fa9d8f40746ec3447335c9642c03410f5fd3af || >=2d53139f31626bad6f8983d8e519ddde2cbba921 <08b1d4cab0230697bc74c63fc4e40170a7559c54 || >=2d53139f31626bad6f8983d8e519ddde2cbba921 <3be5f24e8270ba53b3c814d13689bb8644c86237 || >=2d53139f31626bad6f8983d8e519ddde2cbba921 <d512bdefd241b98f4d7bcb5bab5614a86411fad4 || >=2d53139f31626bad6f8983d8e519ddde2cbba921 <00dd025324b56d39d37e57a08f473dab3a660f30 || >=2d53139f31626bad6f8983d8e519ddde2cbba921 <02d03c61e8a7b016956acb48e8a2512d16d87517 || >=2d53139f31626bad6f8983d8e519ddde2cbba921 <4da073d57176d8e1c2bca34febfbc81d2560c1a5 || >=2d53139f31626bad6f8983d8e519ddde2cbba921 <cff06b03b530ae1fe8a13e93a7848f2130e00fb4 | e5fa9d8f40746ec3447335c9642c03410f5fd3af, 08b1d4cab0230697bc74c63fc4e40170a7559c54, 3be5f24e8270ba53b3c814d13689bb8644c86237, d512bdefd241b98f4d7bcb5bab5614a86411fad4, 00dd025324b56d39d37e57a08f473dab3a660f30, 02d03c61e8a7b016956acb48e8a2512d16d87517, 4da073d57176d8e1c2bca34febfbc81d2560c1a5, cff06b03b530ae1fe8a13e93a7848f2130e00fb4 |
| Linux/Linuxgeneric | 3.16 | Not reported |
Published upstream
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 15, 2026
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.
Quoted source text, attributed separately from HOL analysis.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=2d53139f31626bad6f8983d8e519ddde2cbba921 <e5fa9d8f40746ec3447335c9642c03410f5fd3af || >=2d53139f31626bad6f8983d8e519ddde2cbba921 <08b1d4cab0230697bc74c63fc4e40170a7559c54 || >=2d53139f31626bad6f8983d8e519ddde2cbba921 <3be5f24e8270ba53b3c814d13689bb8644c86237 || >=2d53139f31626bad6f8983d8e519ddde2cbba921 <d512bdefd241b98f4d7bcb5bab5614a86411fad4 || >=2d53139f31626bad6f8983d8e519ddde2cbba921 <00dd025324b56d39d37e57a08f473dab3a660f30 || >=2d53139f31626bad6f8983d8e519ddde2cbba921 <02d03c61e8a7b016956acb48e8a2512d16d87517 || >=2d53139f31626bad6f8983d8e519ddde2cbba921 <4da073d57176d8e1c2bca34febfbc81d2560c1a5 || >=2d53139f31626bad6f8983d8e519ddde2cbba921 <cff06b03b530ae1fe8a13e93a7848f2130e00fb4 | e5fa9d8f40746ec3447335c9642c03410f5fd3af, 08b1d4cab0230697bc74c63fc4e40170a7559c54, 3be5f24e8270ba53b3c814d13689bb8644c86237, d512bdefd241b98f4d7bcb5bab5614a86411fad4, 00dd025324b56d39d37e57a08f473dab3a660f30, 02d03c61e8a7b016956acb48e8a2512d16d87517, 4da073d57176d8e1c2bca34febfbc81d2560c1a5, cff06b03b530ae1fe8a13e93a7848f2130e00fb4 |
| Linux/Linuxgeneric | 3.16 | Not reported |
Published upstream
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 15, 2026
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.
Quoted source text, attributed separately from HOL analysis.