CVE-2026-72027

The vulnerability in CVE-2026-72027 is straightforward at the code level: compaction_free() calls free_pages_prepare() and ignores its return value. When free_pages_prepare() fails — typically because it encounters a PageHWPoison page or a page flagged by free_page_is_bad() — the page still gets added to the freelist. That contaminated page then gets allocated to whatever process requests memory next, producing silent data corruption in an arbitrary workload. The fix is a one-line return-value check. That's not what matters most. What matters is understanding why this class of bug recurs. Memory compaction operates in an environment where failure modes are hardware-dependent and configuration-dependent. A developer working on a system without poisoning infrastructure, or with different kernel configs, would never encounter these failures in practice — making the assumption that free_pages_prepare() can't fail entirely reasonable for their context. The function gained failure conditions over time (or always had them in ways that weren't exercised), but compaction_free() was never updated to handle them. This is environmental drift: correct code for the reality the author inhabited, that became dangerous as the execution environment evolved. For defenders, the priority is not just applying the patch. Audit your kernel version's compaction code path for other callers of free_pages_prepare() that might have the same blind spot. Check whether your environment triggers PageHWPoison or bad-page detection — if it does, this bug isn't theoretical. Monitor for silent data corruption symptoms in long-running processes, because the contamination vector hides in the blast radius: the failure doesn't crash compaction, it poisons the next allocation. The systemic question is whether your organization has a process to re-audit callers when helper functions gain new failure paths. The kernel's review culture treats each patch as an individual event, not a contract change that propagates through the call graph. This bug is a data point in a recurring class — get_user_pages(), copy_from_user(), and various folio paths have all exhibited the same pattern. The fix for this instance is trivial; the fix for the class requires tooling that forces caller updates when function error semantics expand, not just human discipline to remember.

Reviewed through automated stages and approved by a human before publication.