Description

In the Linux kernel, the following vulnerability has been resolved: can: peak_usb: peak_usb_start(): fix double free of transfer buffer on URB submit error In peak_usb_start(), each RX URB transfer buffer is allocated with kmalloc() and the URB is flagged URB_FREE_BUFFER so that the final usb_free_urb() also frees the transfer buffer. If usb_submit_urb() fails, the error path frees the buffer explicitly with kfree(buf) and then calls usb_free_urb(urb). Because URB_FREE_BUFFER is set, usb_free_urb() -> urb_destroy() frees the same buffer a second time, a double free of the transfer buffer. BUG: KASAN: double-free in usb_free_urb.part.0+0x91/0xb0 Free of addr ffff8881069ccb80 by task trigger.sh/285 Call Trace: kfree+0x113/0x3c0 usb_free_urb.part.0+0x91/0xb0 Drop the redundant kfree(buf); usb_free_urb() already releases the transfer buffer. This mirrors commit 03819abbeb11 ("net: usb: lan78xx: Fix double free issue with interrupt buffer allocation").

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-15T13:17:50.227Z",
  "pubdate": "2026-08-15T13:17:50.227Z",
  "executiveSummary": "A double free vulnerability exists in the peak_usb driver of the Linux kernel, specifically within the peak_usb_start() function.\nThe vulnerability is triggered during error handling when a call to usb_submit_urb() fails after RX URB transfer buffers have been allocated.\nThe impact of this security flaw includes memory corruption, potential kernel crashes, and a possible denial of service (DoS) state.\nThe affected component is the USB CAN device driver peak_usb within the Linux kernel.\nRisk implications center around local kernel stability and integrity, as memory corruption in core kernel structures can lead to unpredictable system behavior.\nAttacker capabilities and exploitation requirements are constrained by local execution context; an attacker must typically be able to trigger the driver initialization or interface start routine, often requiring local access or physical device insertion privileges depending on the environment.",
  "technicalDetails": "The root cause of the vulnerability is a memory management flaw in the error handling path of the peak_usb_start() function within the peak_usb_related driver codebase.\nDuring initialization in peak_usb_start(), each receive RX URB transfer buffer is dynamically allocated using kmalloc().\nThe associated USB Request Block (URB) is configured with the URB_FREE_BUFFER flag, which instructs the USB core subsystem to automatically release the allocated transfer buffer when usb_free_urb() is eventually invoked.\nWhen usb_submit_urb() fails during the setup sequence, the driver error handling path explicitly invokes kfree(buf) to release the transfer buffer manually.\nImmediately following the explicit kfree(buf) call, the driver calls usb_free_urb(urb).\nBecause the URB_FREE_BUFFER flag remains set on the URB structure, the subsequent execution of usb_free_urb() routes to urb_destroy(), which attempts to free the identical transfer buffer memory address a second time.\nThis execution sequence directly precipitates a double free condition, as verified by kernel debugging tools such as KASAN (Kernel Address Sanitizer), which records a double-free trace in usb_free_urb.part.0+0x91/0xb0 following a kfree invocation.\nExploitation or accidental triggering occurs step-by-step when an asynchronous URB submission failure happens during device startup, causing the kernel to execute the flawed error path.\nThe resulting memory corruption targets kernel heap allocations managed by the SLUB/SLOB/SLAB allocator, leading to kernel panics or potential undefined memory states.\nThe vulnerable component is identified within the peak_usb driver source files, specifically handling USB transfer buffer lifecycles.\nAuthentication requirements, privilege requirements, and network exposure depend on the ability to interact with the USB subsystem or attach a compatible CAN device, typically requiring local access or root privileges to load and initialize hardware drivers."
}