CVE-2026-31549

What it actually does

This is a local denial-of-service vulnerability in the Linux kernel cp2615 I2C USB driver. During device probe, the driver uses the USB device serial string as the I2C adapter name without first verifying that the serial string exists. A malformed or malicious USB device that omits the expected serial number can trigger a NULL-pointer dereference in kernel context, causing a kernel oops or system crash depending on kernel panic settings and system configuration. The issue affects availability only; it does not directly provide confidentiality or integrity impact.

Why it matters to the business

Systems that allow untrusted USB peripherals or USB passthrough may be crashed by attaching a specially crafted device, causing service interruption, workstation downtime, kiosk/embedded device disruption, or operational impact in environments where physical or local peripheral access is possible. Internet-scale exploitation is unlikely based on the low EPSS score, no known public exploit maturity, and absence from the Known Exploited Vulnerabilities catalog, but the impact can still be significant for Linux systems deployed in physically accessible locations or environments with weak USB device controls.

How an attack unfolds

An attacker needs local access or an equivalent ability to present a USB device to the target Linux system, such as physical USB access, USB-over-IP, hypervisor USB passthrough, or a compromised host that can emulate USB peripherals. The attacker connects or presents a malicious CP2615-like USB device that causes the kernel cp2615 driver to bind during probe while the USB serial string is absent. The vulnerable driver attempts to access the missing serial string while constructing the I2C adapter name, dereferences a NULL pointer, and triggers a kernel fault. Depending on system policy, this may kill the driver path, leave the USB/I2C subsystem unstable, or crash/reboot the host if kernel panic-on-oops is enabled.

How to fix it

Upgrade to a Linux kernel version or vendor backport that includes the cp2615 driver fix validating that the USB device has a serial number before accessing it. Because no exact fixed package versions were provided, use distribution vendor advisories and kernel changelogs to identify the first fixed kernel for each supported platform. If immediate patching is not possible and CP2615 hardware is not required, disable or blacklist the cp2615 driver/module, prevent automatic binding to untrusted USB devices, and restrict USB peripheral access using physical port controls, BIOS/UEFI settings, USB authorization policies, udev rules, or endpoint device-control tooling. For virtualized environments, disable unnecessary USB passthrough and block untrusted USB redirection into Linux guests.

How to confirm the fix worked

Confirm that the running kernel includes the upstream or vendor backported fix titled 'i2c: cp2615: fix serial string NULL-deref at probe' or equivalent logic that checks for a device serial number before using it in the cp2615 probe path. Validate package status with the distribution package manager and vendor security advisory, then confirm the active running kernel has been rebooted into the patched version. Where source or debug packages are available, inspect the cp2615 driver implementation for an explicit serial-number existence check before constructing the I2C adapter name. Also verify that mitigations are active if used: the cp2615 module is not loaded, module blacklisting is effective, USB authorization policy denies unknown devices, and USB passthrough is disabled where not required.

Typical attack path

1. Gain local physical access to the target system or the ability to present a USB device through USB passthrough, USB emulation, or peripheral redirection.
2. Prepare a malicious or malformed USB device that matches the cp2615 driver binding conditions but does not provide a valid USB serial string.
3. Attach or present the device to the Linux host.
4. The kernel loads or invokes the cp2615 driver probe routine for the device.
5. The driver accesses the missing serial string and triggers a NULL-pointer dereference in kernel context.
6. The system experiences a kernel oops, driver failure, hang, reboot, or denial of service depending on configuration.

How to detect it

To determine whether this was already triggered, review kernel and system logs around USB insertion events, unexpected crashes, reboots, or kernel oops messages. Relevant sources include journalctl kernel logs, dmesg output, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore records, pstore logs, and endpoint device-control logs showing USB attach events. Look for cp2615 driver probe activity immediately followed by NULL-pointer dereference, kernel oops, panic, reboot, or hung task messages. Correlate timestamps with physical access records, USB device inventory, hypervisor USB passthrough events, and udev logs. Because this vulnerability causes denial of service rather than persistent compromise, durable indicators may be limited to crash artifacts and device attachment records.

• cp2615
• i2c: cp2615
• BUG: kernel NULL pointer dereference
• kernel NULL pointer dereference
• Oops:
• Kernel panic - not syncing
• panic_on_oops
• usbcore: registered new interface driver cp2615
• /var/log/kern.log
• /var/log/messages
• /sys/bus/usb/drivers/cp2615
• /proc/sys/kernel/panic_on_oops

What your security team should do

• Prioritize patching Linux systems that are physically accessible, support USB redirection, run kiosks/embedded workloads, or permit USB passthrough into virtual machines.
• Identify systems with the cp2615 driver available or loaded and confirm whether CP2615-class USB audio/I2C bridge hardware is actually required.
• If the hardware is not required, blacklist or disable the cp2615 driver and enforce USB device allowlisting until all systems are patched.
• Restrict untrusted USB device access through endpoint controls, BIOS/UEFI port restrictions, udev authorization policies, and hypervisor USB passthrough policy.
• Monitor kernel logs for cp2615 probe failures, NULL-pointer dereferences, kernel oops events, or unexpected reboots following USB device insertion.
• Because EPSS remains very low and there is no KEV listing or known exploit maturity, handle this as a targeted/local availability risk rather than an internet-exposed emergency, while still patching within normal kernel maintenance cycles.