CVE-2026-64351

What it actually does

This is an out-of-bounds read in the Linux kernel Kalmia USB network driver receive path. A malicious or malfunctioning USB device can provide a short bulk-IN frame that causes the driver to underflow a receive-frame length calculation, then use device-controlled length fields to make kernel code read beyond the end of the allocated socket buffer during frame validation and trimming. The primary technical outcomes are kernel memory disclosure to the code path, kernel fault, or denial of service; practical arbitrary code execution is not indicated by the available details.

Why it matters to the business

Systems that enable the affected Kalmia USB network driver and accept untrusted USB devices can be crashed or destabilized by a crafted device. The most likely operational risk is local denial of service on laptops, workstations, kiosks, embedded Linux devices, or servers where USB peripherals can be attached. Because exploitation requires interaction with a malicious USB device or equivalent USB-emulation path, broad internet-scale exploitation is unlikely; however, environments with physical access exposure, bring-your-own-device practices, shared workstations, or field-deployed Linux systems should treat this as a hardening and availability concern.

How an attack unfolds

An attacker needs a way to present a crafted USB device that binds to the Linux Kalmia USB network driver. Once the device is connected and the driver processes received bulk-IN traffic, the device sends a malformed short receive frame or a frame sequence that leaves an undersized trailing remainder. The vulnerable receive fixup routine subtracts two framing-header lengths from a buffer that does not actually contain both headers, causing an unsigned length underflow. Because the computed USB packet length becomes very large, normal truncation logic is bypassed, and a device-supplied Ethernet packet length can drive comparisons and buffer adjustments beyond the real receive buffer. Depending on kernel configuration and memory layout, this can trigger a kernel warning, KASAN report, page fault, network-driver failure, or system crash.

How to fix it

Update to a Linux kernel version or vendor kernel package that includes the fix for the Kalmia USB network driver receive-frame length validation. If an immediate kernel update is not available, mitigate by preventing the kalmia driver from loading where it is not required, restricting physical USB access, disabling unused USB ports in firmware or operating-system policy, and enforcing controls that block untrusted USB network devices. On systems that do not need this hardware support, blacklist the kalmia module or remove it from custom kernel builds. Because no exact fixed package versions were provided, use the relevant distribution or kernel vendor advisory to identify the first patched kernel for each supported release stream.

How to confirm the fix worked

Confirm that the running kernel package contains the upstream fix that requires both start and end Kalmia framing headers to be present before length subtraction on every receive-loop iteration. Validate exposure by checking whether the kalmia module is present, loadable, or currently loaded. On Linux systems, review `lsmod`, `modinfo kalmia`, kernel configuration, and the presence of the driver object under the active kernel module tree. After remediation, verify that the updated kernel is booted, not merely installed, and that unneeded kalmia support is disabled or blocked. In test environments, malformed short Kalmia receive frames should be rejected without kernel warnings, KASAN reports, page faults, or crashes.

Typical attack path

1. Obtain physical access to a Linux system or another path to emulate/present a malicious USB device to it.
2. Present a USB device with identifiers or behavior that cause the Kalmia USB network driver to bind.
3. Send crafted bulk-IN receive data with a frame length between the minimum single-header size and the size required for both framing headers, or create a short trailing remainder in a multi-frame receive buffer.
4. Set device-controlled length fields so the driver performs receive-buffer operations using lengths that exceed the actual allocated buffer.
5. Trigger out-of-bounds kernel memory reads during packet validation and buffer trimming, potentially causing a kernel fault or denial of service.

How to detect it

To determine whether exploitation may have already occurred, review kernel and system logs for unexpected Kalmia USB device attachment, driver binding, and subsequent kernel memory errors or crashes. Useful log sources include `dmesg`, journald/kernel logs, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, crash dumps, kdump/vmcore data, KASAN reports, endpoint telemetry that records USB device insertions, and asset logs showing loaded kernel modules. Look for temporal correlation between a USB device enumeration event, loading or binding of the `kalmia` driver, and kernel warnings such as out-of-bounds reads, general protection faults, page faults, soft lockups, panics, or network-driver receive-path errors. Because this vulnerability is triggered through device-supplied USB traffic rather than a network payload, conventional network IDS is unlikely to see the exploit unless USB-over-IP or virtualization telemetry captures the malicious USB exchange. There are no public threat actors or ransomware campaigns associated with this issue in the provided data, and EPSS is low, so detection should focus on targeted physical-access or rogue-device scenarios rather than internet scanning.

• kalmia
• kalmia_rx_fixup
• drivers/net/usb/kalmia
• kalmia.ko
• BUG: KASAN: slab-out-of-bounds
• BUG: KASAN: out-of-bounds in kalmia_rx_fixup
• general protection fault
• kernel panic
• Unable to handle kernel paging request
• usbcore: registered new interface driver kalmia
• usbcore: deregistering interface driver kalmia
• cdc_ether
• usbnet
• bulk-IN

What your security team should do

• Prioritize patching Linux systems where untrusted users can attach USB devices, including shared workstations, kiosks, lab systems, field devices, and servers with accessible USB ports.
• Inventory systems for loaded or available Kalmia USB network driver support and focus remediation on systems where the driver is enabled or USB peripheral exposure exists.
• If the driver is not operationally required, blacklist or remove the kalmia module as a compensating control until patched kernels are deployed.
• Apply vendor kernel updates and reboot systems to ensure the fixed kernel is running.
• Harden endpoint and server USB policy to block unauthorized USB network adapters and modem-class devices.
• Monitor kernel logs for crashes, KASAN reports, page faults, or warnings involving the kalmia driver or `kalmia_rx_fixup`.
• Treat unexpected Kalmia USB device attachment events as suspicious, especially on systems where that hardware is not approved.