CVE-2026-93119: usb: ljca: bound bank_num in ljca_enumerate_gpio()
In the Linux kernel, the following vulnerability has been resolved:
usb: ljca: bound banknum in ljcaenumerategpio()
ljcaenumerategpio() reads desc->banknum from the device and loops validpin[i] = getunalignedle32(...) for i < banknum. validpin[] holds only LJCAMAXGPIONUM / 32 = 2 entries.
Two checks run before the loop. The reply length must match structsize(desc, bankdesc, banknum). The product pinsperbank banknum must not exceed LJCAMAXGPIONUM. Neither one bounds banknum against the size of validpin[]. The reply is capped at LJCAMAXPAYLOADSIZE (60) bytes, so the structsize check limits banknum to 9. A device that reports banknum 9 with pinsperbank 7 still passes both checks. gpionum is 63 and the reply is 56 bytes. The loop then writes nine u32 into the two entry array and overruns validpin[] on the stack.
A broken or malicious LJCA device can therefore overflow the stack. Reject a banknum that does not fit validpin[].
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
linux kernel (USB: ljca)to a version that resolves this vulnerability.Fixed in resolvedPatch usb: ljca: bound bank_num in ljca_enumerate_gpio() - Configuration
Ensure ljca_enumerate_gpio() rejects a bank_num that does not fit valid_pin[] and bounds bank_num against the size of valid_pin[] so pins_per_bank * bank_num must not exceed LJCA_MAX_GPIO_NUM.
USB: ljca bound bank_num in ljca_enumerate_gpio() = enforce bank_num <= size of valid_pin[]
Event History
Frequently Asked Questions
Which systems are realistically exposed to this issue?
Systems using the Linux kernel LJCA USB driver are exposed when they communicate with a broken or malicious LJCA device that supplies crafted GPIO enumeration data. The issue is triggered during GPIO enumeration for that device.
What does an attacker need to exploit it?
An attacker needs control of, or the ability to present, an LJCA device that reports an oversized bank_num value while satisfying the existing reply-length and GPIO-count checks. A reported bank_num of 9 with pins_per_bank of 7 is described as passing those checks and causing the overflow.
How can I tell whether a device is attempting to trigger the vulnerable path?
The vulnerable condition occurs when an LJCA device reports more GPIO banks than fit in the driver's two-entry valid_pin array. The described malicious example reports bank_num 9, pins_per_bank 7, gpio_num 63, and a 56-byte reply.
What is the mitigation if an update cannot be applied immediately?
Avoid connecting or trusting broken or untrusted LJCA USB devices. The resolved change rejects bank_num values that do not fit in valid_pin[].