CVE-2026-64242

What it actually does

This is a Linux kernel memory-management flaw in the USB gadget net2280 driver. During a failed device probe, the driver calls cleanup logic that drops the final reference to an embedded USB gadget object; the gadget release callback then frees the enclosing net2280 structure. The same error path could subsequently free that structure again, creating a double-free condition. At a technical level, this can corrupt kernel heap state and may lead to a kernel crash, denial of service, or, in more favorable attacker-controlled conditions, potential kernel memory corruption. Practical exploitation is likely constrained because it requires the vulnerable driver to be present, loaded, and exercised through a failing probe path for the net2280 USB gadget device.

Why it matters to the business

The most likely operational impact is instability or a crash of Linux systems using the affected USB gadget net2280 driver, particularly embedded, appliance, lab, or specialized systems that expose USB gadget functionality. Because the flaw is in kernel code, a successful trigger can affect the whole host rather than only one application. There is no indication that this issue is known to be exploited in the wild, used in ransomware campaigns, or listed in CISA KEV, and the current EPSS score is low, so broad internet-scale exploitation is not currently expected; however, kernel memory corruption bugs should still be remediated during normal kernel maintenance cycles.

How an attack unfolds

An attacker would first need a target system where the vulnerable Linux kernel includes and loads the net2280 USB gadget driver. The attacker then needs a way to cause the net2280 device probe to fail after USB gadget initialization has installed the release callback but before probe completes successfully. When the driver enters the probe error path, it calls removal and reference-release routines that allow the gadget release callback to free the net2280 allocation. The vulnerable code path then attempts to free the same allocation again. That second free can corrupt kernel heap metadata or trigger kernel hardening checks, commonly resulting in a kernel warning, panic, or system crash. Turning this into reliable privilege escalation or code execution would require precise control over heap layout and timing and is not known to be publicly demonstrated.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the USB gadget net2280 double-free in the probe error path. The corrected code removes the explicit kfree() and relies on the gadget device release callback to perform the final free. Because no product-specific fixed versions were provided, use the fixed kernel packages supplied by the relevant Linux distribution, device vendor, or kernel branch maintainer. Where immediate patching is not possible, reduce exposure by disabling or blacklisting the net2280 USB gadget driver if it is not required, removing unused USB gadget functionality from custom kernel builds, and limiting physical or low-level device access to systems that require this driver. Reboot into the patched kernel after installation; merely installing kernel packages is not sufficient if the running kernel remains vulnerable.

How to confirm the fix worked

Confirm remediation by verifying that systems are running a patched kernel version from the distribution or vendor advisory, not only that patched packages are installed. Review the kernel source or vendor patch notes for the net2280 fix that removes the duplicate free in the probe error path. Check whether the vulnerable driver is present or loaded using kernel module and configuration inspection, such as looking for net2280-related modules or CONFIG_USB_NET2280-style build options depending on the distribution. Validate that the host has rebooted into the updated kernel with commands such as uname -a and package-manager kernel inventory checks. For systems where the driver is not needed, confirm that it cannot be loaded through module blacklist policy or by removing it from the kernel build.

Typical attack path

1. Identify a Linux system or appliance using a kernel build that includes the USB gadget net2280 driver.
2. Gain physical, local, or device-level interaction sufficient to influence USB gadget initialization or cause a net2280 probe failure.
3. Trigger the vulnerable probe error path after usb_initialize_gadget() has installed the gadget release callback.
4. Allow net2280_remove() and usb_put_gadget() to drop the final gadget reference, causing the release callback to free the net2280 object.
5. Reach the subsequent erroneous free of the same object, causing kernel heap corruption or a kernel crash.
6. Optionally attempt to shape kernel heap state to convert the double free into a more controlled memory-corruption primitive.

How to detect it

There are no public reports of exploitation and no network-level indicators specific to this vulnerability. Detection should focus on host telemetry from Linux systems that include the net2280 USB gadget driver. Review kernel logs, persistent journal entries, crash dumps, pstore records, and console logs for signs of net2280 probe failures followed by double-free, slab allocator, KASAN, kernel oops, panic, or unexpected reboot events. Useful sources include /var/log/kern.log, /var/log/messages, /var/log/syslog, journalctl -k output, dmesg captures, kdump/vmcore analysis, and embedded device serial console logs. Correlate any crash or memory-corruption event with recent loading, probing, or removal of the net2280 driver. Because a successful trigger may crash the kernel before detailed application logs are written, prioritize low-level kernel and boot-cycle evidence over application telemetry.

• net2280
• usb: gadget: net2280
• KASAN: double-free
• KASAN: use-after-free
• BUG: KASAN
• double free
• slab corruption
• kernel BUG
• kernel panic
• Oops:
• general protection fault
• usb_put_gadget
• gadget_release
• net2280_remove
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog

What your security team should do

• Inventory Linux systems, embedded devices, appliances, and custom kernel builds that include or load the USB gadget net2280 driver.
• Prioritize patching systems where USB gadget functionality is enabled, where untrusted users can influence device initialization, or where physical/device access is less controlled.
• Deploy vendor-provided kernel updates and reboot systems into the fixed kernel.
• If patching is delayed, disable or blacklist the net2280 driver where operationally safe.
• Monitor kernel logs for net2280 probe failures, double-free warnings, KASAN reports, slab allocator corruption, kernel oopses, or unexpected reboots.
• For products built on custom kernels, backport the upstream fix and include regression testing for net2280 probe failure cleanup paths.
• Treat unexplained crashes on systems using this driver as potentially security-relevant until logs and crash dumps confirm a benign cause.