CVE-2026-53333: Linux Kernel mincore Memory Residency Reporting Flaw

Technical summary

The mincore_swap() function in mm/mincore.c processes migration, hardware poison, and shmem swap-in error entries alongside traditional swap entries. On !CONFIG_SWAP kernel builds where CONFIG_MIGRATION or CONFIG_MEMORY_FAILURE is enabled, the !IS_ENABLED(CONFIG_SWAP) guard precedes the early return for non-swap entries. This causes mincore_pte_range() to spuriously trigger WARN_ON conditions and misreport pages as non-resident. The vulnerability is resolved by relocating the CONFIG_SWAP guard to occur after the non-swap-entry type check, allowing migration and hardware poison entries to follow the existing uptodate/non-shmem code path rather than failing the guard.

Business impact

Systems relying on mincore() for accurate memory residency reporting—such as page prefetching optimizations, memory pressure analysis, or workload characterization tools—may receive incorrect data on affected kernel configurations. This can lead to suboptimal memory management decisions, false performance troubleshooting, and unreliable telemetry. The severity is contained by the guard's specificity: only non-swap kernel builds with migration or fault-tolerance features enabled are affected, limiting broad production impact but potentially affecting specialized deployments.

Affected systems

Linux kernel versions prior to the fix. The vulnerability manifests only on systems compiled with CONFIG_SWAP disabled while CONFIG_MIGRATION or CONFIG_MEMORY_FAILURE is enabled—a configuration used in specialized embedded, real-time, or fault-tolerant environments. Mainstream distributions with standard kernel configurations are less likely to encounter this combination.

Exploitability

This is not a remotely exploitable vulnerability. It requires local access to invoke mincore() calls and interpret their results. An unprivileged local process can trigger the false WARN messages, but exploitation is passive: it reveals incorrect memory information rather than enabling code execution or privilege escalation. The primary impact is data integrity (incorrect mincore output) rather than availability or confidentiality.

Remediation

Update to a patched Linux kernel version that includes the mincore guard reordering fix. Verify the specific kernel version carrying this patch against your distributor's security advisories. For systems where immediate patching is infeasible, limit the scope of mincore() system call availability if policy permits, though this may disable legitimate memory analysis tools.

Patch guidance

Consult your Linux distribution's security advisory for the specific kernel version containing this fix. Mainstream distributions (Ubuntu, Red Hat, Debian, SUSE) typically backport mincore fixes to their supported kernel branches. Test the updated kernel in a staging environment before production deployment, particularly if your workload depends on mincore() for memory optimization or monitoring. Verify kernel configuration confirms the fix is present (check LOCALVERSION or dmesg for build information).

Detection guidance

Review system logs for mincore-related WARN_ON messages (typically appearing in dmesg or kernel logs). Monitor systems with CONFIG_MIGRATION or CONFIG_MEMORY_FAILURE enabled and !CONFIG_SWAP disabled to identify candidates for testing. Tools using mincore() (such as some memory profilers or page cache analyzers) may produce inconsistent or suspicious results on affected kernels; cross-reference their output with /proc/[pid]/maps or page-types to validate accuracy. Kernel version and build configuration checks (via /proc/version or uname -a) can help identify at-risk deployments.

Why prioritize this

Medium severity reflects the local-access-only requirement and the specific kernel configuration combination needed to trigger the issue. However, for systems matching the configuration profile, patching should be prioritized because mincore() reliability underpins memory-aware application tuning and system diagnostics. The fix is straightforward and carries low regression risk.

Risk score, explained

CVSS 5.5 (Medium) reflects an availability impact (A:H) with local attack vector, low complexity, and low privilege requirement. The score appropriately captures the kernel warning and data integrity concern while accounting for the restricted configuration scope and lack of remote or privilege-escalation pathways.

Frequently asked questions