CVE-2026-53333

What it actually does

This is a local Linux kernel availability flaw in the mm/mincore code path. On kernels built without CONFIG_SWAP but with features such as CONFIG_MIGRATION or CONFIG_MEMORY_FAILURE enabled, mincore() can encounter non-swap special page-table entries such as migration or hardware-poison entries. Because the CONFIG_SWAP guard was evaluated before those non-swap entries were handled, the kernel could spuriously trigger a WARN condition and incorrectly report affected pages as nonresident. If the system is configured to panic on kernel warnings, this can turn a local mincore() call pattern into a kernel crash; otherwise, impact is generally limited to warning/log noise and incorrect residency reporting.

Why it matters to the business

An attacker who already has local code execution or a local account may be able to disrupt affected Linux systems, especially hardened, embedded, appliance, or custom kernels built without swap support. The primary business risk is service interruption or node instability, not data theft or privilege escalation. The CVSS score is moderate, EPSS is very low, it is not in CISA KEV, and no exploit maturity is reported, so remediation should be handled through normal kernel patch cycles unless the organization runs multi-tenant or untrusted local workloads where local denial-of-service issues have higher operational impact.

How an attack unfolds

An attacker first needs the ability to execute code locally on an affected Linux system. They then target systems built without CONFIG_SWAP where migration, memory-failure, or related special memory-management entries may occur. By repeatedly invoking mincore() against memory ranges that intersect migration, hardware-poison, or shmem swap-in-error style entries, the attacker can drive execution through the vulnerable mm/mincore path. On an affected kernel, the code may treat those non-swap entries incorrectly, emit a kernel WARN, and report pages as nonresident. If kernel warnings are configured to cause a panic, the WARN can crash the host; otherwise, repeated triggering may create operational noise and degrade reliability but is unlikely to provide code execution or access to sensitive data.

How to fix it

Upgrade to a vendor-supported Linux kernel that includes the upstream fix for mm/mincore handling of non-swap entries before the !CONFIG_SWAP guard. No exact fixed package versions were provided in the input, so use the relevant distribution, appliance, cloud image, or kernel vendor advisory to identify the corrected kernel build. Prioritize custom or embedded kernels built with CONFIG_SWAP disabled and CONFIG_MIGRATION or CONFIG_MEMORY_FAILURE enabled. Where immediate patching is not possible, reduce exposure by limiting untrusted local code execution, constraining multi-tenant workloads, and ensuring kernel warnings do not automatically panic production systems unless that behavior is explicitly required. Setting panic-on-warn to a non-crashing posture can reduce outage risk but does not fix the underlying bug.

How to confirm the fix worked

Confirm the running kernel has the vendor fix that corresponds to the upstream change titled 'mm/mincore: handle non-swap entries before !CONFIG_SWAP guard.' Validate kernel package versions against distribution advisories or source patches. For custom kernels, inspect the mm/mincore implementation and verify that non-swap entries are handled before the !CONFIG_SWAP warning path. Check kernel configuration for CONFIG_SWAP, CONFIG_MIGRATION, CONFIG_MEMORY_FAILURE, and panic-on-warn behavior. After patching and rebooting into the fixed kernel, confirm the old kernel is no longer running with uname, package-manager inventory, or image metadata. In non-production test systems only, regression testing can exercise mincore() under memory migration or memory-failure scenarios and confirm no spurious WARN is produced.

Typical attack path

1. Gain local code execution through an existing account, container escape prerequisite, compromised service account, or permitted workload execution.
2. Determine that the host is running an affected Linux kernel build, particularly one compiled without CONFIG_SWAP and with CONFIG_MIGRATION or CONFIG_MEMORY_FAILURE enabled.
3. Allocate or map memory and attempt to exercise memory states involving migration, hardware-poison, or similar special page-table entries.
4. Invoke mincore() repeatedly against selected memory ranges to reach the vulnerable mm/mincore handling path.
5. Trigger a spurious kernel WARN and incorrect residency result; on systems with panic-on-warn behavior, cause a denial of service through kernel panic or reboot.

How to detect it

Look for evidence in kernel logs and system journals that the mincore path emitted warnings or that hosts unexpectedly panicked shortly after mincore activity. Relevant sources include dmesg, journald kernel facility logs, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore records, audit logs for unusual local process activity, and EDR telemetry showing processes making high volumes of mincore() calls. Focus on systems built without swap support or systems with panic-on-warn enabled. Search for kernel stack traces referencing mincore_swap, mincore_pte_range, or mm/mincore.c, and correlate timestamps with user sessions, container workloads, scheduled jobs, or recently deployed local binaries. Because the vulnerability does not create a distinctive network artifact and has no known public exploit maturity, detection is primarily host-based and forensic rather than perimeter-based.

• mincore_swap
• mincore_pte_range
• mm/mincore.c
• WARNING: CPU:
• kernel panic - not syncing
• panic_on_warn
• sys_mincore
• __x64_sys_mincore

What your security team should do

• Inventory Linux systems running custom, appliance, embedded, or minimal kernels where CONFIG_SWAP may be disabled.
• Prioritize remediation for hosts that allow untrusted local users, shared compute, container workloads, CI runners, build farms, research platforms, or other multi-tenant execution.
• Apply vendor kernel updates when available and reboot systems into the fixed kernel; verify that stale vulnerable kernels are not still active.
• For custom kernels, backport the mm/mincore fix directly if a full kernel upgrade is not feasible.
• Review kernel panic policy and avoid panic-on-warn on systems where availability is more important than immediate crash-on-warning behavior.
• Monitor kernel logs for mincore-related WARN traces, especially on no-swap kernels, to identify possible triggering or regression.
• Treat evidence of repeated mincore-related WARNs from local processes as suspicious activity or unstable workload behavior and investigate the responsible process/user.