CVE-2025-22000

What it actually does

The flaw causes a memory leak in the Linux kernel huge memory code when an after-split folio must be dropped at EOF: folio_put_refs is called with the wrong count instead of folio_nr_pages(folio), leaving page-cache references and preventing the folio from being freed on filesystems whose block size exceeds page size.

Why it matters to the business

Over time the leak can exhaust kernel memory on any system performing truncate operations against large-block filesystems, producing performance degradation, OOM kills, or crashes; the issue affects 441 downstream dependents and all distributions shipping the vulnerable kernel.

How an attack unfolds

A local attacker mounts or uses a filesystem with blocksize > page_size, creates a file large enough to produce high-order folios, then repeatedly truncates it past EOF; each truncate triggers folio split and incorrect refcounting that leaks the folio.

How to fix it

Upgrade the kernel to a version containing commit 86368616a9ce51f6b41efa251b6e066893851d67 (or later stable backport) and reboot; for Red Hat Enterprise Linux 8 apply the redis module packages fixed in 0:6.0.9-3.module+el8.4.0+10984+ed187465 if those components are in use.

How to confirm the fix worked

Confirm the running kernel contains commit 86368616a9ce51f6b41efa251b6e066893851d67, then exercise truncate on a blocksize > page_size filesystem while monitoring /proc/meminfo or slabinfo for unreleased huge-page-cache objects.

Typical attack path

1. Obtain local shell on a target system
2. Create or mount a filesystem whose block size exceeds the page size
3. Write a file that forces allocation of high-order folios
4. Issue truncate operations that cross EOF boundaries
5. Repeat to accumulate unreleased folios until memory pressure occurs

How to detect it

Review kernel slabinfo and meminfo before/after truncate workloads on large-block filesystems; look for steadily growing page-cache or hugepage entries that do not decrease after file deletion; correlate with dmesg entries mentioning folio or truncate.

What your security team should do

• Apply the fixed kernel immediately on all systems that use filesystems with blocksize larger than page size
• Prioritize patching hosts with high uptime or heavy file-system activity
• Add memory-usage alerts for page-cache and huge-page slabs until patches are deployed