CVE-2026-31651

What it actually does

This is a local denial-of-service flaw in the Linux kernel vub300 MMC/USB controller driver. During device disconnect handling, the driver can drop or clear its driver-private data before the controller is fully deregistered, creating a race/order-of-operations bug that can lead to a NULL pointer dereference or use-after-free in kernel context. Successful triggering can crash the kernel or destabilize the host. The issue does not directly provide confidentiality or integrity impact, and there is no public exploit maturity reported.

Why it matters to the business

An attacker with local access capable of interacting with the affected vub300 device path could cause a Linux system crash, resulting in service interruption, failed jobs, data processing disruption, or unplanned reboot. Risk is highest on systems that load the vub300 driver and allow local users, removable devices, or automated hardware workflows to trigger device attach/detach events. EPSS is very low and the issue is not listed in CISA KEV, so broad internet-scale exploitation is not expected, but exposed multi-user or device-facing Linux systems should still be patched during normal kernel maintenance.

How an attack unfolds

An attacker first needs local ability to influence the affected hardware or driver state, such as by repeatedly connecting and disconnecting a device handled by the vub300 driver or otherwise triggering the driver disconnect path. When the vulnerable disconnect routine runs, the driver may release or null its private data before deregistering the MMC controller. Subsequent cleanup code can then dereference a NULL or stale pointer in kernel context. This causes a kernel oops, panic, or related instability, producing a denial of service. There is no indication from the supplied intelligence that this vulnerability is being exploited by named threat actors or ransomware campaigns.

How to fix it

Apply a Linux kernel update from the relevant distribution or vendor that includes the upstream fix for the vub300 disconnect handling order. No exact fixed package versions were provided, so use vendor advisories, distribution security trackers, and kernel changelogs to identify the first patched kernel for each supported release. If immediate patching is not possible and the vub300 driver is not required, mitigate by preventing the module from loading, for example by blacklisting the vub300 module through the distribution-supported modprobe configuration mechanism and rebuilding initramfs where required. Additional compensating controls include restricting local shell access, limiting access to removable USB/MMC hardware, enforcing USB device control policies, and monitoring for kernel crash events associated with vub300 or MMC device removal.

How to confirm the fix worked

Confirm the running kernel is a vendor-supported build that includes the vub300 disconnect fix. Validate exposure by checking whether the vub300 driver exists and is loaded using standard Linux tooling such as lsmod, modinfo, and distribution package inventory. If the driver is intentionally disabled, confirm it cannot be auto-loaded and is not present in the initramfs if applicable. Review kernel logs after reboot to ensure no vub300-related oops, panic, NULL pointer dereference, or use-after-free messages occur during device attach/detach testing. For production systems, avoid destructive validation that intentionally crashes the kernel; instead rely on package version verification and vendor advisory mapping.

Typical attack path

1. Identify a Linux system that has the vub300 MMC/USB controller driver present and loadable.
2. Gain local access or physical/device-level ability to trigger attach/detach behavior for hardware handled by the vub300 driver.
3. Cause the affected device disconnect path to execute, potentially repeatedly to improve reliability.
4. Trigger the incorrect cleanup sequence where driver data is dropped before the controller is deregistered.
5. Cause a kernel NULL pointer dereference or use-after-free, resulting in a crash, panic, or system instability.

How to detect it

To determine whether this was already triggered, review kernel and system logs for crashes or oops events around vub300, MMC, USB, or removable-device disconnect activity. Useful sources include journald, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dump records, kdump/vmcore repositories, systemd-coredump metadata, hardware inventory logs, and USB device attach/detach audit trails where available. Look for a sequence where a vub300 or MMC/USB device is disconnected shortly before a kernel NULL pointer dereference, use-after-free report, general protection fault, kernel oops, panic, watchdog reset, or unexplained reboot. Because this is a local denial-of-service bug, indicators are primarily host-based reliability artifacts rather than network IOCs. Repeated crash timing aligned with removable-device activity or local user sessions should be investigated.

• vub300
• BUG: kernel NULL pointer dereference
• NULL pointer dereference
• use-after-free
• kernel BUG
• kernel panic
• Oops:
• general protection fault
• Unable to handle kernel NULL pointer dereference
• mmc
• USB disconnect
• disconnect

What your security team should do

• Prioritize patching Linux systems that load the vub300 driver, support removable USB/MMC hardware, or are accessible to untrusted local users.
• If vub300 hardware is not used, disable or blacklist the vub300 kernel module as a low-risk mitigation.
• Add monitoring for kernel oops, panic, NULL pointer dereference, and use-after-free events mentioning vub300, mmc, or USB disconnect activity.
• Restrict local interactive access and physical/removable device access on systems where immediate kernel patching is delayed.
• Track vendor kernel advisories because fixed versions were not supplied, and verify that patched kernels are actually booted after installation.
• Treat unexpected kernel crashes around removable media disconnect events as potential exploitation or reliability signals and preserve logs for forensic review.