CVE-2025-68249

What it actually does

In the Linux kernel MOST USB driver, an early error path in hdm_probe() invokes put_device() on a device structure that has not yet been initialized via device_initialize(), resulting in a kernel warning and kref_put() on an uninitialized kobject; the private structure is then freed via kfree() instead of the device release path.

Why it matters to the business

Kernel oops or warning messages during USB device probe failures can cause system instability or crashes on affected Linux systems; the issue affects kernel stability rather than remote code execution and carries low exploitation likelihood.

How an attack unfolds

An attacker would need to trigger the specific error path in hdm_probe() by presenting a USB device that causes allocation or initialization failure before device_initialize() completes; the resulting improper kobject handling may produce a warning but is unlikely to yield reliable memory corruption for privilege escalation.

How to fix it

Update the Linux kernel to a version containing commit 3509c748e79435d09e730673c8c100b7f0ebc87c or later; rebuild and reboot with the patched kernel; for packaged distributions apply the vendor kernel update that incorporates this fix.

How to confirm the fix worked

Confirm the running kernel contains commit 3509c748e79435d09e730673c8c100b7f0ebc87c via git log or kernel version string; attempt to reproduce the original error path with a failing USB device and verify absence of the put_device warning.

Typical attack path

1. Attach or emulate a USB device that induces an early failure in hdm_probe()
2. Force the err_free_mdev label to execute before device_initialize()
3. Observe kernel warning from put_device() on uninitialized kobject
4. Attempt to leverage resulting state for further memory corruption or denial of service

How to detect it

Review kernel logs (dmesg, /var/log/kern.log, journalctl) for warnings referencing put_device, kobject, or hdm_probe during USB device attachment; no persistent artifacts are produced after the warning.

What your security team should do

• Prioritize kernel updates on systems exposing the MOST USB driver
• Monitor kernel logs for device initialization warnings during USB enumeration
• Apply the fixed commit or equivalent distribution kernel package within standard patching cycles given low EPSS