CVE-2026-89498

What it actually does

A deterministic kernel double-free in the OrangeFS (orangefs) readdir downcall path. When a readdir downcall copy fails, orangefs_devreq_write_iter() vfree()s op->downcall.trailer_buf and leaves the pointer set; the waiting do_readdir() path then vfree()s the same vmalloc buffer on the error path. The result is kernel heap corruption (double-free of a trailer buffer) in process context on hosts with the orangefs module and /dev/pvfs2-req.

Why it matters to the business

On machines that actually run OrangeFS, this can panic or destabilize the kernel and take down every workload on the node—an availability incident for HPC or parallel-storage hosts. Current exploit probability is low (EPSS about 0.18%, flat over 30 days, not in CISA KEV, no known in-the-wild use or ransomware association, exploit maturity none). Exposure is limited to systems with orangefs loaded; general-purpose fleets that do not use this file system have negligible operational risk. Unpatched OrangeFS nodes should still be treated as a local denial-of-service and memory-corruption risk.

How an attack unfolds

A local actor who can open the OrangeFS userspace-kernel request device submits a readdir downcall that declares a trailer larger than the bytes actually supplied. The kernel copy-in fails, one path frees the trailer buffer, and the sleeping readdir waiter frees it again, corrupting kernel allocator state. That typically crashes the host immediately; a more capable attacker could try to turn the double-free into further kernel memory corruption. The condition is local (or equivalent access to /dev/pvfs2-req on a host with orangefs loaded); unauthenticated remote exploitation is not indicated, and no named threat actors or campaigns are associated with this issue.

How to fix it

Install a Linux kernel that includes the OrangeFS fix: after vfree() of trailer_buf on the copy-from-iter failure path in orangefs_devreq_write_iter(), the pointer is cleared so the readdir-side vfree() is a no-op. Apply the distro or vendor kernel update that backports this change and reboot into the patched kernel. If OrangeFS is not required, unload/blacklist the orangefs module, remove or restrict /dev/pvfs2-req, and drop related packages so the device cannot be opened. No specific upstream or distro version numbers were supplied with this record—track vendor kernel advisories for the orangefs trailer_buf double-free fix.

How to confirm the fix worked

Confirm the running kernel changelog or stable-commit list includes the orangefs fix that NULLs trailer_buf after the error-path vfree in orangefs_devreq_write_iter(). Verify uname -r matches a patched build, that lsmod does not show orangefs unless still required, and that /dev/pvfs2-req is absent or mode/ownership-restricted. On remaining OrangeFS hosts, review dmesg/journal for orangefs oopses after patching. Do not attempt to reproduce the copy-failure path on production systems.

Typical attack path

1. Gain local (or equivalent) access on a host where the orangefs module is loaded and /dev/pvfs2-req exists
2. Open the OrangeFS request device with sufficient privilege to write downcalls
3. Submit a readdir downcall whose declared trailer size exceeds the data actually provided
4. Cause copy-in to fail so trailer_buf is freed in the write path and freed again in the readdir waiter
5. Induce a kernel oops/panic (denial of service) or attempt to leverage the resulting heap corruption

How to detect it

This is a local kernel double-free; look for evidence it already fired rather than network callbacks. Search kernel logs (dmesg, journalctl -k, persistent /var/log/kern.log or equivalent, crash dumps, kdump/vmcore, pstore) for oops/BUG/KASAN reports whose call traces include orangefs_devreq_write_iter, do_readdir, orangefs, or vfree of trailer state, and for 'double free' or slub/vmalloc allocator BUG lines around the same timestamp. Correlate with opens/writes to /dev/pvfs2-req (audit syscall records on that path, udev, or container device mounts). Unexpected orangefs module load on hosts that should not run OrangeFS is an exposure indicator, not proof of exploitation. No remote C2 pattern or named-actor telemetry is associated with this CVE.

• /dev/pvfs2-req
• orangefs_devreq_write_iter
• do_readdir
• orangefs
• pvfs2
• double free
• BUG: Bad page state
• KASAN: double-free
• Call Trace:.*orangefs

What your security team should do

• Patch and reboot OrangeFS-enabled kernels first; this is a local kernel double-free even though EPSS is low and the CVE is not in KEV
• Inventory hosts for orangefs in lsmod, orangefs/pvfs2 packages, and the /dev/pvfs2-req node to bound blast radius
• If OrangeFS is unused, blacklist the module and remove the device node as compensating control until kernels are updated
• Restrict who can open /dev/pvfs2-req (root-only, no untrusted local users or containers with device access)
• Watch vendor kernel feeds for the exact orangefs trailer_buf NULL-after-free backport; 32 days post-publication with flat EPSS does not justify delay on known OrangeFS nodes
• Hunt historical kernel logs for orangefs double-free/oops evidence before closing the ticket