The Linux kernel security community has assigned CVE-2025-37834 to a recently disclosed memory-management bug in mm/vmscan that can cause a kernel oops or panic by attempting to reclaim a hardware‑poisoned (hwpoison) folio; maintainers have published small, surgical fixes in upstream stable trees and vendors are rolling backports, but operators must treat this as an availability risk for multi‑tenant and cloud hosts and apply patched kernels urgently.
Background / Overview
The defect reported as CVE-2025-37834 originates in the kernel reclaim code (mm/vmscan) and was discovered through fuzzing and regression testing. In short form, the kernel reclaim path can attempt to requeue and reclaim a folio that has been marked hwpoison, which leads to a sequence where the folio’s uptodate status is inconsistent and the kernel hits an internal assertion (VM_BUG_ON_FOLIO) during add_to_swap. The result in real-world systems is an availability event — a kernel oops or panic — visible in kernel logs and crash traces. The bug was publicly announced on May 8, 2025, and fixed upstream with a narrow change: skip hwpoisoned folios inside the folio shrink/reclaim path and ensure user mappings for such folios are unmapped at the right time. Upstream fixes landed in stable kernel trees (example fixed commits target 6.12.26, 6.14.5, and early 6.15 trees), and vendors have begun issuing advisories and backports.Technical anatomy: what actually goes wrong
The actors: folios, hwpoison, LRU and reclaim
- A folio is a page-cache unit the kernel manages for memory and filesystems.
- hwpoison is a bit used to mark pages detected as corrupted by hardware error handling; hwpoison handling attempts to quarantine such pages and avoid exposing corrupted data to processes.
- The LRU (least-recently-used) lists are where reclaimable pages/folios are tracked.
- kswapd and the reclaim paths (shrinker/shrink_folio_list / shrink_inactive_list / shrink_node) attempt to reclaim memory by walking folio lists and moving pages to swap or freeing them.
Failure sequence observed in test traces
Syzkaller-triggered reproducer traces and vendor writeups show the following condensed sequence:- A dirty swapcache page gets isolated by reclaim code and is not locked.
- A simulated or real memory failure is injected, and the page receives the hwpoison flag while its uptodate bit may be cleared by me_swapcache_dirty or related handlers.
- Due to timing, the reclaim path places the hwpoisoned folio back onto the LRU rather than fully removing and unmapping it.
- Later reclaim attempts reach add_to_swap for that folio and hit VM_BUG_ON_FOLIO(!folio_test_uptodate(folio), triggering a kernel BUG/OOPS and potentially a panic.
Where and who is affected
- Any Linux build that contains the vulnerable mm/vmscan code prior to the stable commits referenced above is potentially affected. The upstream fix was merged into supported kernel branches (examples include stable 6.12.26 and 6.14.5), so unpatched kernels in those series remain vulnerable.
- The vulnerability is local in attack vector: an attacker requires the ability to run code on the host (or inside a guest that can exercise the host reclaim paths) to trigger the condition. This makes it particularly relevant to:
- Multi‑tenant cloud hosts and hypervisor nodes.
- CI runners and shared developer infrastructure that run untrusted workloads.
- Systems that process untrusted images or filesystems where memory‑failure and swap interactions can be provoked.
- Desktop single‑user systems are lower risk unless they run tooling or workloads that trigger userfaultfd/special reclaim flows; cloud operators and hosting providers should prioritize remediation.
Severity, scoring, and divergent vendor assessments
Different trackers have assigned different scores and severity labels:- NVD’s published summary characterizes this as an availability-first bug (kernel panic) and gave a CVSS v3.1 base score consistent with an availability impact. The NVD description shows the exact BUG trace and repro steps.
- Vendor and distribution trackers sometimes assign higher numerical scores; for example, AWS ALAS labels the issue Medium/6.4 and lists per‑platform status, while other commercial databases record a score around 7.0. Score variance is common with kernel availability defects because vendors weigh local exploitability, attack surface, and operational impact differently. Treat numeric scores as guidance — prioritize remediation based on operational exposure (multi‑tenant hosts > single‑user systems).
The upstream fix — what changed in code
Kernel maintainers applied a minimal, low‑risk correction:- Skip hwpoisoned folios in shrink_folio_list so the shrinker does not attempt to reclaim folios currently marked hwpoison.
- Ensure user mappings of hwpoison folios are unmapped within shrink_folio_list if they haven’t already been cleared by hwpoison_user_mappings, thereby preventing folios from being left in LRU with inconsistent flags.
- The changes are intentionally focused and small so they can be backported to stable branches with low regression risk; the linux-cve-announce summary lists the specific stable commits that carry the fixes.
- Fixed in 6.12.26 via commit: 1c9798bf8145a92abf45aa9d38a6406d9eb8bdf0
- Fixed in 6.14.5 via commit: 912e9f0300c3564b72a8808db406e313193a37ad
- Fixed in 6.15-rc1 via commit: 1b0449544c6482179ac84530b61fc192a6527bfd
Operators should confirm these or equivalent backport commits appear in their distribution’s kernel changelog before claiming remediation.
Detection: what to look for in logs and telemetry
This bug produces clear kernel diagnostic output when triggered. Hunting guidance:- Search kernel logs (dmesg, journalctl -k, or centralized kernel telemetry) for the specific BUG/OOPS trace text:
- VM_BUG_ON_FOLIO(!folio_test_uptodate(folio)
- add_to_swap in the stack trace
- reclaim/kswapd stack traces that include shrink_folio_list and shrink_inactive_list
- Example phrases to grep for:
- "VM_BUG_ON_FOLIO"
- "add_to_swap"
- "shrink_folio_list"
- "kswapd" and a backtrace shown near a BUG/OOPS
- Capture and preserve crash dumps (kdump) and dmesg outputs when you see related traces; post‑reboot logs are often the only record of what happened and are essential for triage.
Immediate remediation and operational playbook
- Inventory and triage
- Identify hosts with kernel versions prior to the stable fixes: uname -r and map your kernel packages / vendor advisories to the fixed commits.
- Prioritize hosts that are multi‑tenant, host untrusted code, or run container/VM services where a kernel panic affects many customers.
- Patch and reboot
- The authoritative remediation is to install a kernel package that contains the upstream stable commit(s) that fix CVE‑2025‑37834 and reboot into the patched kernel. Kernel changes require reboots to take effect.
- Use vendor security trackers and kernel package changelogs to confirm that your distribution’s kernel contains the referenced commit(s).
- Staged rollout
- Pilot the updated kernel on representative hosts that exercise memory pressure and reclaim paths.
- Monitor kernel logs and workload stability during the pilot window before wider rollout.
- Short‑term mitigations if patching is delayed
- Restrict which users/processes can run untrusted workloads on at‑risk hosts.
- Isolate workloads that might trigger heavy memory‑reclaim activity (high churn of anonymous pages / swap-backed pages) onto hosts that have already been patched.
- Increase kernel‑level telemetry and alerting on OOPS/BUG patterns described above.
- Post‑patch verification
- Confirm kernel changelog/package metadata includes the upstream stable commit ID before declaring remediation.
- Reboot hosts and re‑run representative workloads; continue to monitor kernel logs for any residual traces or regressions.
Detection and response playbook — commands and checks
- Confirm current kernel:
- uname -r
- Check kernel changelog / package metadata for commit/patch:
- For RPM systems: rpm -q --changelog kernel | grep -i <commit-id or CVE>
- For Debian/Ubuntu: apt changelog linux-image-$(uname -r) (or inspect /usr/share/doc/changelog)
- Search logs:
- journalctl -k --since "YYYY-MM-DD" | grep -Ei "VM_BUG_ON_FOLIO|add_to_swap|shrink_folio_list|kswapd"
- dmesg | grep -i "VM_BUG_ON_FOLIO"
- Capture crash evidence:
- Ensure kdump/pstore is enabled where feasible and preserve vmcores for post‑mortem.
Risk analysis: strengths of the upstream response and residual caveats
Strengths- The upstream fix is small and narrowly scoped, which reduces regression risk and makes vendor backports straightforward.
- The fix addresses the core ordering and handling mistake by excluding hwpoison folios from ordinary reclaim flows and ensuring explicit unmap semantics.
- Distribution and vendor lag: Not all vendors will backport the stable commit immediately. Some vendors or enterprise kernels may decide not to backport to older life‑cycle branches; operators must verify their own package trackers. For example, Amazon Linux trackers list per‑release fix status — some older kernels may have “No Fix Planned” entries while others were patched. Always confirm with your vendor.
- Local attack vector: The bug requires code execution or controlled workload on the host (local or guest). For multi‑tenant policy, this is a high‑priority problem even if remote exploitability is not shown.
- Score variance: Different vulnerability trackers provide different CVSS numbers; these divergences reflect differing threat models and scoring heuristics. Prioritize based on the actual operational threat to your environment rather than a single numeric score.
What defenders often get wrong
- Assuming hwpoison is always handled earlier: In some timing windows, hwpoison handling and reclaim interact in ways that leave folios in LRU with inconsistent flags; the fix acknowledges that race and guards it explicitly.
- Treating CVSS numbers as the sole triage input: For kernel availability bugs, operational exposure (multi‑tenant hosts, untrusted workloads) should drive priority.
- Cherry‑picking upstream commits without vendor vetting: Kernel maintainers caution that individual commits are not tested in isolation by distributions; apply vendor packages or comprehensively test any manual backport before production rollout.
Practical checklist for sysadmins (quick reference)
- Inventory:
- Identify kernel versions: uname -r across estate.
- Flag multi‑tenant hypervisors, CI runners, and nodes that accept untrusted workloads.
- Patch:
- Find vendor kernel update that references CVE‑2025‑37834 or the upstream commit IDs and install.
- Reboot into patched kernel.
- Verify:
- Confirm kernel changelog or package metadata lists the commit/CVE.
- Reproduce representative memory pressure workloads in test environment and monitor logs.
- Monitor:
- Add SIEM rules to alert on BUG/OOPS traces referencing add_to_swap, VM_BUG_ON_FOLIO, and shrink_folio_list.
- Short‑term isolation:
- Move untrusted workloads off critical multi‑tenant nodes until patched.
Developer and maintainer notes (for kernel engineers and packagers)
- The accepted upstream approach is intentionally minimal: skip hwpoison folios in shrinker walks and unmap them when appropriate. This pattern fits kernel maintainers’ preference for surgical fixes that preserve higher‑level semantics and minimize backward‑compat concerns.
- When backporting to older kernel trees, ensure the surrounding APIs and assumptions (folio flag layout, LRU shrinker interactions) match the target branch; trivial cherry‑picks can fail silently if adjacent refactors changed calling contracts.
- Test vectors: fuzzers and syzkaller reproducer traces were the original trigger; vendors quoting those reproducer steps can use them to validate patched kernels in QA before rollout.
Conclusion
CVE‑2025‑37834 is an availability‑focused Linux kernel bug in mm/vmscan that arises from attempting to reclaim hwpoison folios under certain timing windows. Upstream maintainers implemented a small, low‑risk correction that skips hwpoisoned folios during reclaim and ensures proper unmapping; stable kernel releases and vendor advisories carry those fixes. The operational risk is highest for multi‑tenant and cloud hosts that run untrusted workloads; remediation requires installing a kernel that includes the upstream stable commits and rebooting. Operators should triage based on operational exposure, verify vendor changelogs for the referenced commits, and monitor kernel logs for the characteristic VM_BUG_ON_FOLIO/add_to_swap traces while planning staged rollouts and reboots.Important note: vulnerability trackers and vendor advisories sometimes differ in CVSS scoring and mitigation timelines — verify your vendor’s package changelog and advisory for the authoritative remediation status before declaring hosts remediated.
Source: MSRC Security Update Guide - Microsoft Security Response Center
