Silent Data Loss in Linux Kernel Finally Fixed After Three Years

A one-line change in the memory management code has closed a bug that quietly discarded user data under common production conditions. The fix arrived this week in the Linux 7.3 development cycle, three years after the offending commit first appeared.

Developers discovered the problem early in September 2026. A short C program reproduced it reliably. The conditions sound narrow at first. Transparent huge pages must be active. The process must sit inside cgroup memory limits. An application calls madvise with MADV_FREE. Then it writes to the memory again. Heavy reclaim pressure follows. When those elements align, writes vanish without error or warning.

The Bug’s Reach

But the conditions aren’t that rare. Polars, a popular data analytics library written in Rust, hit the bug in real deployments. Production datasets disappeared. No stack trace. No kernel log. Just gone data. The issue dates to July 2023 and has lived in every kernel from 6.6 onward. Phoronix first reported the patch and its context on September 14, 2026.

The root cause sits inside pmd_modify(). This function updates page-middle-directory entries for huge pages. When it runs, the code masks away the hardware dirty bit. A later call to pmd_mksaveddirty tries to preserve that dirty state by moving it into a saved-dirty flag. Because the bit was stripped earlier, nothing remains to save. The page appears clean to the reclaim code even though user space wrote fresh data after the MADV_FREE hint.

And the same path affects more than anonymous memory. File-backed transparent huge pages lose writes too. NUMA balancing triggers the exact sequence. So does mprotect when it toggles permissions. The kernel’s own memory management assumed the dirty bit would survive these operations. It didn’t.

Contrast this behavior with the equivalent PTE and PUD paths. Both pte_modify and pud_modify keep the dirty bits intact. Only the PMD version dropped them. That inconsistency survived code review in 2023 and every subsequent merge. Until now.

The patch, merged through the x86/urgent tree after the 7.3-rc3 tag, restores _PAGE_DIRTY to the mask inside pmd_modify. One line. The existing saved-dirty machinery then works as intended. Stable kernel maintainers have tagged it for back-port to every supported series that contains the bug. That means 6.6 and later will receive the change soon.

Developers who maintain large-scale data pipelines should apply the update quickly. Systems running memory-constrained containers with THP enabled face the highest risk. Polars users in particular should watch for new stable releases. The library’s reliance on efficient memory handling made the bug surface in analytics workloads first.

This incident highlights a broader pattern. Modern kernels ship with increasingly sophisticated memory features. Transparent huge pages improve performance but add complexity to the page-fault and reclaim paths. MADV_FREE itself exists to let applications signal that pages can be discarded if memory gets tight. Combine the two under cgroup pressure and subtle state transitions become critical.

Yet the fix required no new infrastructure. No new flags. No complex locking. Just correct preservation of a hardware bit that should never have been masked. The simplicity of the solution makes the three-year lifespan more striking.

Recent testing of Linux 7.3-rc3 also turned up other file-system and driver fixes, but none carry the same silent failure mode. Linus Torvalds noted the rc3 release carried a larger-than-usual file-system footprint, driven mainly by XFS and SMB client work. Those changes address different classes of problems. The memory-management patch stands apart because of its potential to corrupt application state without any visible kernel error.

Enterprise operators running databases, analytics engines, or any workload that mixes large anonymous mappings with memory limits should test the patched kernel immediately. The reproduction case is public. A single process exercising the exact sequence of memset, madvise, mprotect, and reclaim pressure demonstrates the loss in minutes. Production environments with similar patterns likely encountered it already.

The kernel community continues to chase bugs introduced by its own performance features. This one slipped through because the dirty-bit handling looked correct at a glance. The pmd_modify mask simply didn’t match its PTE and PUD siblings. Now it does. Data written after MADV_FREE will stay where it belongs, even when reclaim comes knocking.