CVE-2026-53196

What it actually does

This is a heap-based buffer overflow in the Linux kernel USB serial io_ti driver. When a USB device handled by this driver is connected, the driver reads a manufacturer descriptor from the device-controlled I2C EEPROM. The descriptor Size field is trusted up to the maximum EEPROM image size rather than being constrained to the size of the destination kernel heap buffer. A malicious USB device can advertise an oversized descriptor and cause the kernel to copy up to roughly 16 KB into a much smaller allocation, corrupting adjacent kernel heap memory. The subsequent checksum routine may also read beyond the intended buffer. Depending on kernel configuration, heap layout, and exploit reliability, impact may range from kernel crash and denial of service to potential local kernel-code execution or privilege escalation through a malicious physical or emulated USB device.

Why it matters to the business

Systems that allow untrusted USB devices to be connected may be exposed to host crashes or possible full system compromise at the kernel level. The most realistic operational risk is a malicious peripheral, USB implant, or compromised USB-over-IP/emulation path disrupting endpoints, engineering workstations, kiosks, servers with accessible USB ports, or lab systems. EPSS is currently low and there is no known CISA KEV listing or public exploit maturity reported, but the flaw is in kernel attack surface and should be prioritized on systems where USB ports are physically accessible or USB device attachment is part of normal operations.

How an attack unfolds

An attacker prepares a USB device that identifies as hardware supported by the Linux io_ti USB serial driver and exposes a crafted I2C EEPROM descriptor. When the device is plugged into a vulnerable Linux host, the kernel enumerates the USB device and binds it to the io_ti driver. During device initialization, the driver parses the manufacturer descriptor and allocates a fixed-size buffer for the expected structure. The attacker-controlled Size field causes the driver to read far more data than the buffer can hold, corrupting kernel heap memory. A basic exploit may intentionally crash the host, while a more advanced exploit would attempt to shape heap allocations and overwritten data to gain code execution in kernel context. Successful kernel-level exploitation could allow bypass of normal user-space security controls.

How to fix it

Update the Linux kernel to a version containing the io_ti get_manuf_info() bounds-check fix. Because no product-specific fixed versions were provided, use the fixed kernel packages from the relevant Linux distribution or vendor advisory and verify that the patch rejects unexpected manufacturer descriptor lengths before reading EEPROM data. Where immediate patching is not possible, reduce exposure by disabling or blacklisting the io_ti USB serial driver if it is not required, restricting physical access to USB ports, disabling unused USB ports in firmware or operating-system policy, and blocking USB-over-IP or device redirection paths from untrusted sources. If io_ti-supported USB serial adapters are operationally required, limit use to trusted devices and controlled systems until patched.

How to confirm the fix worked

Confirm remediation by verifying the running kernel package includes the upstream fix for the io_ti get_manuf_info() descriptor length validation. Check the currently running kernel version with standard OS tooling and compare it against the vendor’s fixed kernel advisory. Confirm whether the vulnerable driver is present or loaded by checking for the io_ti module in loaded modules and under the kernel module directory. If mitigating by disabling the driver, confirm that io_ti cannot be auto-loaded when a matching USB device is attached. On test systems, validate that unexpected or malformed io_ti manufacturer descriptor lengths are rejected without a kernel warning, crash, KASAN report, or oops. Review kernel logs after connecting legitimate USB serial devices to ensure normal operation remains intact.

Typical attack path

1. Attacker obtains physical access to a target host, convinces a user to connect a malicious USB device, or reaches the host through a USB-over-IP or device-emulation path.
2. The malicious device presents USB descriptors that cause Linux to bind it to the vulnerable io_ti USB serial driver.
3. During driver initialization, the device returns a crafted manufacturer descriptor with an oversized Size field.
4. The vulnerable driver copies attacker-controlled EEPROM data into an undersized kernel heap buffer.
5. Kernel heap memory is corrupted, causing a crash or creating conditions for privilege escalation/code execution.
6. If exploitation succeeds beyond denial of service, the attacker gains kernel-level control or uses the crash to disrupt system availability.

How to detect it

To assess possible prior exploitation, review kernel logs, persistent journal entries, crash dumps, and endpoint telemetry for io_ti USB serial driver activity followed by memory corruption, KASAN reports, kernel oops, panic, unexpected reboot, or slab allocator warnings. Focus on the time window immediately after USB device connection, enumeration, or USB serial adapter initialization. Relevant sources include dmesg output, systemd-journald kernel facility logs, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dump directories, kdump/vmcore records, audit records for module loading, and EDR device-control telemetry. Look for io_ti module loading or binding, suspicious USB serial devices with unusual descriptors, repeated connect/disconnect events, and crashes containing get_manuf_info(), read_rom(), valid_csum(), or io_ti stack frames. Absence of these artifacts does not prove non-exploitation because a successful kernel exploit may suppress logs or leave only a reboot/crash artifact.

• io_ti
• get_manuf_info
• read_rom
• valid_csum
• USB: serial: io_ti
• KASAN: slab-out-of-bounds
• KASAN: heap-out-of-bounds
• BUG: KASAN
• kernel BUG at
• Oops:
• general protection fault
• slab corruption
• kmalloc-
• /sys/module/io_ti
• /lib/modules/*/kernel/drivers/usb/serial/io_ti.ko
• /lib/modules/*/kernel/drivers/usb/serial/io_ti.ko.xz
• /lib/modules/*/kernel/drivers/usb/serial/io_ti.ko.zst
• /etc/modprobe.d/blacklist-io_ti.conf

What your security team should do

• Prioritize patching Linux systems where USB ports are physically accessible, where users can attach peripherals, or where USB redirection/USB-over-IP is enabled.
• Inventory systems with the io_ti USB serial driver present or loaded, and determine whether the driver is operationally required.
• If the driver is not required, blacklist or disable the io_ti module as a compensating control until all affected kernels are updated.
• Restrict untrusted USB device use through endpoint device-control policies, BIOS/UEFI port controls, physical port blockers, or access-control procedures.
• Monitor kernel logs for USB enumeration events involving io_ti devices followed by kernel oops, panic, slab corruption, KASAN, or out-of-bounds reports.
• Treat unexplained kernel crashes shortly after USB serial device attachment as potentially security-relevant and preserve logs, crash dumps, and connected-device details.
• For high-assurance environments, test patched kernels with malicious or malformed USB descriptor fuzz cases before broad deployment.
• Track vendor kernel advisories because distribution-specific fixed package versions may differ from upstream kernel commit timing.