CVE-2026-46280

What it actually does

This is a local Linux kernel use-after-free in the HMM selftest driver code path, specifically in the dmirror test device implementation. When a file descriptor using the dmirror interface is closed, the kernel frees the associated dmirror structure without first migrating device-private pages back to normal system memory. Those pages can retain a dangling zone_device_data pointer to freed memory. If the process later faults those pages back in, such as during core dump generation after a crash, the dmirror_devmem_fault() callback may dereference the stale pointer, causing kernel memory corruption or a kernel panic. The CVSS vector indicates local, low-complexity exploitation requiring low privileges, with potential confidentiality, integrity, and availability impact if an attacker can reach the vulnerable test interface and shape memory reuse reliably.

Why it matters to the business

The most likely operational impact is local denial of service through a kernel panic or crash on systems where the affected HMM test module/interface is present and accessible. Because this is in Linux kernel selftest support code rather than a typical production subsystem, exposure is expected to be limited; however, organizations that ship, load, or expose kernel testing modules on shared systems could face host crashes and potential privilege-escalation risk from a local user. The vulnerability is not listed in CISA KEV, has no known public exploit maturity in the provided data, and has a very low EPSS score, so urgency is lower than for internet-facing or actively exploited kernel flaws, but kernel fixes should still be incorporated into normal patch cycles.

How an attack unfolds

An attacker first needs local code execution on a system running a vulnerable kernel configuration that includes and exposes the HMM dmirror test functionality. The attacker opens and uses the dmirror test device or interface to create mappings backed by device-private pages. They then close the file descriptor, causing dmirror_fops_release() to free the dmirror object while affected pages still refer to it through zone_device_data. The attacker triggers a later page fault against those stale device-private pages, for example by causing a crash and core dump or otherwise forcing the kernel to walk and fault the mapping. When dmirror_devmem_fault() handles the fault, it dereferences the dangling pointer. In the straightforward case this crashes the kernel; in a more advanced scenario, an attacker may attempt to groom memory so the freed object is replaced with attacker-influenced data, potentially turning the use-after-free into privilege escalation or information disclosure.

How to fix it

Apply a Linux kernel update that includes the fix for this issue. The fix evicts/migrates device-private pages back to system memory in dmirror_fops_release() before freeing the dmirror structure. If no distribution-specific fixed package version is available, update to a kernel release or vendor backport containing the upstream patch described as evicting device pages on file close in lib/test_hmm. As mitigation, avoid building, loading, or exposing HMM selftest/test_hmm/dmirror functionality on production systems. Remove or unload related test modules where possible, restrict access to any associated test device nodes to trusted administrators only, and disable core dump generation for untrusted local workloads if the interface cannot be removed immediately. Because this is a local kernel issue, also maintain standard least-privilege controls for shell access, containers, and untrusted workloads.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package includes the vendor fix or an upstream commit that migrates dmirror device-private pages back to system memory during dmirror_fops_release(). Check the active kernel version with uname -r and compare it against distribution advisories once available. If kernel source or build artifacts are available, confirm that dmirror_fops_release() calls the device-page eviction routine for each devmem chunk before freeing the dmirror object. Validate exposure by checking whether HMM test functionality is built or loaded and whether any related device nodes are present and accessible to non-administrative users. After patching, rerun relevant HMM selftests, especially mm/ksft_hmm.sh, and confirm that failures or SIGABRT/core dump paths no longer produce kernel panics related to dmirror_devmem_fault or zone_device_data dereferences.

Typical attack path

1. Obtain local low-privileged access to a vulnerable Linux host.
2. Confirm that the HMM dmirror test functionality or associated kernel selftest module/interface is present and usable.
3. Create HMM dmirror mappings that place pages into device-private memory.
4. Close the relevant file descriptor so the dmirror structure is freed without evicting the device-private pages.
5. Trigger a later page fault on the stale mappings, such as through abnormal process termination and core dump generation.
6. Cause the kernel fault handler to dereference the stale zone_device_data pointer, resulting in a kernel panic or potentially exploitable memory corruption.

How to detect it

Look for evidence of prior exploitation or accidental triggering in kernel logs, crash dumps, audit logs, and system journals. Primary sources include dmesg, journald kernel entries, /var/log/kern.log, /var/log/messages, /var/log/syslog, kdump/vmcore records, apport/abrt crash artifacts, and auditd records for access to test-related device nodes. Search for kernel oops or panic traces mentioning dmirror_devmem_fault, dmirror_fops_release, test_hmm, hmm, zone_device_data, use-after-free, page fault handling, or coredump activity immediately preceding a crash. Correlate kernel crashes with local processes running HMM selftests such as mm/ksft_hmm.sh, repeated SIGABRT events, core dump generation, or access to HMM/dmirror test devices. Because there are no named threat actors, public exploit maturity, or KEV listing in the provided data, detection should focus on suspicious local triggering of the vulnerable code path and anomalous kernel instability rather than known campaign indicators.

• dmirror_devmem_fault
• dmirror_fops_release
• test_hmm
• ksft_hmm.sh
• mm/ksft_hmm.sh
• zone_device_data
• BUG: kernel NULL pointer dereference
• BUG: unable to handle page fault
• general protection fault
• kernel panic
• Oops:
• use-after-free
• SIGABRT
• Core dumped
• coredump
• hmm
• dmirror

What your security team should do

• Prioritize patching through the normal Linux kernel maintenance cycle; accelerate remediation on multi-user systems, research hosts, CI workers, container hosts, and environments where untrusted users can run local code.
• Inventory systems for loaded or available HMM selftest/test_hmm/dmirror functionality and remove it from production kernels where it is not explicitly required.
• Restrict permissions on any associated test device nodes or interfaces so only trusted administrators can access them until patched.
• Monitor kernel logs for crashes, oopses, or panics involving dmirror_devmem_fault, test_hmm, dmirror_fops_release, or HMM selftests.
• Treat unexpected kernel panics after local process crashes or core dump generation as potentially suspicious on systems where this interface is exposed.
• If maintaining custom kernels, backport the upstream fix rather than relying only on version number comparisons.
• Review local user access controls and workload isolation, because exploitation requires local privileges but may affect the entire host.