CVE-2026-64449

What it actually does

CVE-2026-64449 is a local Linux kernel buffer overflow in the staging vme_user driver. The vulnerable SLAVE read/write paths copy a user-controlled byte count into or out of a fixed 128 KiB kernel buffer without correctly limiting the operation to that buffer size when the configured VME slave window is larger than 128 KiB. A local user with access to the vme_user interface can set or use an oversized slave window and then trigger read() or write() operations that overrun the kernel allocation. Because this occurs in kernel context, successful exploitation can corrupt kernel memory and may allow denial of service, information disclosure, or privilege escalation.

Why it matters to the business

Systems that load and expose the Linux vme_user staging driver, typically specialized VME/PCI industrial, embedded, test, or lab systems, may be vulnerable to local takeover by an authenticated user or compromised low-privilege process. The operational risk is highest where VME hardware interfaces are present, where the module is loaded, or where device-node permissions allow non-administrative access. Although EPSS is currently low and the issue is not in CISA KEV, the CVSS impact is high because exploitation can compromise confidentiality, integrity, and availability of the host kernel.

How an attack unfolds

An attacker first needs local code execution or shell access on a system where the vme_user staging driver is loaded and a VME user device is accessible. The attacker configures or targets a VME SLAVE window whose size exceeds the driver's fixed 128 KiB PCI buffer. They then issue a read() or write() with an offset and count that are valid for the larger VME window but exceed the actual kernel buffer allocation. The vulnerable helper copies the requested data past the end of kern_buf, corrupting adjacent slab memory or reading beyond the allocation. A basic exploit may crash the kernel and cause a denial of service; a more advanced exploit would shape kernel heap state and overflow contents to corrupt control data, leak kernel memory, or escalate privileges.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix bounding SLAVE read/write operations to the 128 KiB kern_buf size. If no vendor-fixed package is listed yet, track the kernel vendor advisory for CVE-2026-64449 and deploy the first stable, distribution, or appliance kernel update that includes the vme_user bounds-checking patch. As interim mitigation, unload and blacklist the vme_user module if it is not required, remove or restrict access to VME user device nodes, and ensure only trusted administrative users can interact with VME control and data interfaces. On systems that require VME support, reduce exposure by enforcing strict device permissions, limiting local shell access, and monitoring module loads and VME configuration activity.

How to confirm the fix worked

Confirm the running kernel contains the fix from the vendor or upstream stable branch. Verify whether the vme_user module is loaded using standard module inventory commands and confirm whether VME user device nodes are present and accessible to non-administrative users. Validate that device permissions restrict access to trusted users only. Where safe and appropriate in a non-production test environment, attempt boundary-condition read/write tests against the SLAVE path with a configured window larger than 128 KiB and verify the operation returns a short transfer or stops at the buffer boundary rather than producing KASAN, kernel oops, or slab-out-of-bounds messages. Review kernel logs after testing to confirm no vme_user-related memory corruption reports occur.

Typical attack path

1. Gain local access to a Linux system where the vme_user staging driver is present and loaded.
2. Identify accessible VME user device nodes or processes that interact with the vme_user SLAVE interface.
3. Configure or select a VME SLAVE window larger than 128 KiB using the driver's control interface.
4. Call read() or write() with an offset and byte count that exceed the fixed kern_buf allocation while remaining within the configured VME window.
5. Trigger an out-of-bounds kernel memory read or write in the vme_user SLAVE helper path.
6. Use the memory corruption to crash the host, disclose kernel memory, or attempt local privilege escalation.

How to detect it

Look for evidence that the vme_user driver was loaded and then produced kernel memory-corruption symptoms. Primary sources are kernel logs, journald, dmesg output, crash dumps, audit logs for module loading, and file-access telemetry for VME device nodes. Search for KASAN reports, kernel oopses, panics, or BUG messages referencing vme_user_write, vme_user_read, _copy_from_user, _copy_to_user, buffer_from_user, buffer_to_user, or the vme_user module. Review auditd or EDR telemetry for suspicious local processes opening VME device nodes and performing large reads or writes shortly before a crash. If module load auditing is enabled, identify unexpected modprobe or insmod activity for vme_user or related VME bridge modules such as vme_fake in test environments. Absence of logs does not rule out exploitation, particularly on systems without KASAN or persistent kernel logging; in that case, correlate unexplained reboots, kernel panics, and recent local access to VME interfaces.

• KASAN: slab-out-of-bounds
• BUG: KASAN: slab-out-of-bounds in _copy_from_user
• BUG: KASAN: slab-out-of-bounds in _copy_to_user
• vme_user_write
• vme_user_read
• buffer_from_user
• buffer_to_user
• [vme_user]
• vme_user
• vme_fake
• VME_SET_SLAVE
• Write of size 262144
• Read of size 262144
• slab-out-of-bounds in _copy_from_user
• slab-out-of-bounds in _copy_to_user
• modprobe vme_user
• insmod vme_user

What your security team should do

• Prioritize patching or kernel upgrades on systems that load vme_user or support VME hardware interfaces, especially multi-user systems or systems reachable by untrusted operators.
• Immediately unload and blacklist vme_user on systems where VME user-space access is not required.
• Restrict VME device-node permissions to trusted administrative or service accounts only.
• Inventory Linux hosts for loaded staging drivers and VME-related modules, with particular focus on industrial, embedded, lab, and hardware-test environments.
• Monitor kernel logs for KASAN, slab-out-of-bounds, kernel oops, or panic messages involving vme_user_write, vme_user_read, buffer_to_user, or buffer_from_user.
• Treat unexpected crashes on systems using vme_user as potentially security-relevant until kernel logs and module/device access history are reviewed.
• Because the issue is not currently KEV-listed and EPSS is low, schedule broadly according to normal high-severity local kernel vulnerability SLAs, but accelerate remediation where local users or untrusted workloads have access.