CVE-2026-46017

What it actually does

This is a Linux kernel memory-management race condition in the interaction between folio migration, reverse-map removal, and the deferred split queue. During migration, a destination folio can become visible before it is correctly requeued for deferred splitting. A concurrent memory-management path can then observe inconsistent deferred-split state, mark the folio as partially mapped, and trigger a kernel WARN in deferred_split_folio(). On systems configured to panic on kernel warnings, or under repeated triggering, this can cause local denial of service through kernel panic or system instability. The flaw does not directly provide confidentiality or integrity impact and requires local code execution with low privileges and difficult timing conditions.

Why it matters to the business

An attacker who already has local access to a Linux system may be able to crash or destabilize the host by provoking a kernel memory-management race. The main operational risk is availability loss for affected Linux servers, workstations, appliances, or container hosts. The CVSS score is moderate and EPSS is very low, there is no known KEV listing, no ransomware association, and no reported exploit maturity, so broad internet-scale exploitation is unlikely; however, shared compute platforms, multi-user systems, and environments where kernel warnings trigger panics should treat this as more important.

How an attack unfolds

An attacker first obtains the ability to run local code on an affected Linux kernel. They then attempt to create memory-management activity that exercises folio migration, deferred splitting of large folios or transparent huge pages, reclaim/shrinker activity, and reverse-map removal concurrently. If the timing is successful, the migration path exposes the destination folio before its deferred split queue state has been restored. A competing rmap-removal or shrinker path may then operate on the folio in an inconsistent state and trigger a WARN in deferred_split_folio(). If kernel panic-on-warning is enabled, that warning can immediately crash the system; otherwise, repeated attempts may cause instability, noisy kernel logs, or degraded availability.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the deferred split queue migration race. Because no exact fixed versions were provided, remediation should be based on the affected distribution or vendor advisory for the running kernel branch. Prioritize updating kernels on multi-user systems, virtualization/container hosts, and systems configured with kernel.panic_on_warn=1 or equivalent panic-on-WARN behavior. If immediate patching is not possible, reduce risk by restricting local shell or workload execution to trusted users, limiting untrusted container workloads, reviewing whether panic-on-warning is required, and applying vendor-recommended mitigations for transparent huge pages or memory compaction only if they are documented as safe for the workload.

How to confirm the fix worked

Confirm the running kernel package or build contains the vendor backport or upstream patch that requeues the destination folio before remove_migration_ptes() and requeues folios in deferred_split_scan() when folio_trylock() fails. Validate through the operating system vendor’s package changelog, kernel commit history, or advisory metadata rather than relying only on the upstream version number, since Linux distributions commonly backport fixes. After updating, reboot into the fixed kernel and verify with uname -r and package-manager queries that the active kernel is the corrected build. Review sysctl/kernel configuration for panic-on-WARN behavior and monitor kernel logs for recurrence of deferred_split_folio warnings under memory pressure testing.

Typical attack path

1. Gain local code execution on an affected Linux system with low-privileged access.
2. Run a workload that creates memory pressure and encourages large folio or transparent huge page allocation, migration, reclaim, and splitting activity.
3. Attempt to race folio migration against reverse-map removal or deferred split queue scanning.
4. Trigger the inconsistent deferred split queue state during migrate_folio_move().
5. Cause a kernel WARN in deferred_split_folio(), potentially resulting in a kernel panic if panic_on_warn is enabled.
6. Repeat the trigger to cause denial of service or operational instability.

How to detect it

Look for evidence of prior exploitation or accidental triggering in kernel logs, persistent journal records, crash dumps, and monitoring alerts for unexpected reboots. Relevant sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, kdump/vmcore records, crash analysis output, and hypervisor or cloud host availability events. Focus on kernel WARN or panic traces that mention deferred_split_folio(), deferred_split_scan(), migrate_folio_move(), remove_migration_ptes(), folio migration, transparent huge pages, memory compaction, or shrinker activity shortly before a crash or reboot. Correlate suspicious events with local user sessions, container starts, batch jobs, memory-pressure workloads, or repeated process executions that heavily allocate memory. Absence of these strings does not prove the vulnerability was not triggered, because logs may rotate or a panic may occur before all buffers are written.

• deferred_split_folio
• WARNING: CPU:
• kernel BUG
• Kernel panic - not syncing
• panic_on_warn
• migrate_folio_move
• remove_migration_ptes
• deferred_split_scan
• folio_trylock
• split_queue
• deferred split queue
• mm: fix deferred split queue races during migration
• transparent hugepage
• memory compaction
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /proc/sys/kernel/panic_on_warn
• vmcore
• kdump

What your security team should do

• Inventory Linux systems and identify kernels affected by this memory-management race, prioritizing internet-facing infrastructure only if local code execution paths exist.
• Patch or upgrade affected kernels using distribution/vendor updates as soon as practical, with priority for shared compute, container, virtualization, CI/CD runners, HPC, and multi-user systems.
• Check whether panic-on-WARN is enabled; where business requirements allow, avoid configurations that convert kernel warnings into immediate host crashes.
• Restrict untrusted local code execution and container workloads on unpatched systems until remediation is complete.
• Monitor kernel logs for deferred_split_folio WARN traces, memory-management warnings, unexplained reboots, kernel panics, and workload-triggered host instability.
• Because EPSS is very low, there is no KEV status, and no known exploit maturity, handle through normal kernel patch management unless exposed systems support untrusted local workloads.