Look up another CVE · open CVE-2026-72033 in the interactive tracker
CVE-2026-72033
orangefs: keep the readdir entry size 64-bit in fill_from_part()
Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem fs/orangefs. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-72033 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixed | 6.1.180-1 | Update the kernel and reboot. Fixed in 6.1.180-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.100-1 | Update the kernel and reboot. Fixed in 6.12.100-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
fill_from_part() computes the size of a directory entry in size_t but stores it in a __u32. An entry length near U32_MAX wraps it to a small value, bypasses the bounds check, and is then used to index the entry, reading far past the directory part -- an out-of-bounds read that oopses the kernel. Compute the size as a u64 so it cannot truncate; the bounds check then rejects the entry. The trailer is supplied by the userspace client.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
fs/orangefs/dir.c
- What this is
- ORANGEFS FILESYSTEMMAINTAINERS section matched on fs/orangefs/ · devel@lists.orangefs.org · Supported
- Kernel module
- orangefs
Check it on the machine
grep -w CONFIG_ORANGEFS_FS /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w orangefsPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this as a loadable module. Every release below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded.
- bookworm, trixie, forky, sidm
- m
- a loadable module on every flavour - check lsmod, can be blacklisted
- Build switch
- CONFIG_ORANGEFS_FS
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-08-15 (2 months ago)source
- CVSS
- 9.8 critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.79%, higher than 55.5% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- fs/orangefs
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.12 | 5.10.261 | 1679780f482f |
| 4.12 | 5.15.212 | a72bbb436895 |
| 4.12 | 6.1.178 | 36723b28e329 |
| 4.12 | 6.6.145 | 07c05601a9a8 |
| 4.12 | 6.12.97 | fdf06a1b66ff |
| 4.12 | 6.18.40 | 82fc886e244c |
| 4.12 | 7.1.5 | e3d325c0bdb7 |
| 4.12 | 7.2 | 18227a6bc98b |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:NAttack vector, network
- fill_from_part() parses readdir trailer bytes relayed by pvfs2-client-core from an OrangeFS/PVFS server over the cluster network; a malicious or compromised server can supply crafted directory-entry lengths that reach the kernel during getdents on HPC client nodes without local shell access.
- AC:LAttack complexity, low
- An entry length near U32_MAX makes padlen truncate to a small __u32, reliably bypassing the bounds check and forcing the subsequent s[*len] probe; the attacker fully controls the trailer fields and no race, heap layout, or timing condition beyond readdir is required.
- PR:NPrivileges required, none
- A remote malicious OrangeFS/PVFS metadata server needs no account, capabilities, or namespaces on victim HPC compute nodes; once clients mount the filesystem, any process with directory read access can trigger parsing of attacker-supplied trailer bytes.
- UI:NUser interaction, none
- No victim interaction is required beyond normal automated directory scans (cron, parallel job launchers, monitoring); the attacker does not need a user to mount the filesystem or click anything—only pre-existing cluster mounts to the compromised server.
- S:UScope, unchanged
- The out-of-bounds read and resulting kernel oops occur entirely within the victim client's kernel address space during VFS readdir processing; there is no inherent crossing of VM, container, IOMMU, or sandbox security boundaries.
- C:HConfidentiality impact, high
- The integer truncation lets the kernel index gigabytes past the vzalloc readdir part buffer via s[*len], an unbounded out-of-bounds read over adjacent kernel memory before the fault; per CNA guidance OOB reads of this class are rated High.
- I:HIntegrity impact, high
- The bounds bypass is a memory-corruption class flaw that can reach beyond the allocated directory part into adjacent kernel heap; even though the immediate access is a read, CNA guidance rates such unchecked OOB probes as High integrity impact due to exploit chaining potential.
- A:HAvailability impact, high
- The maintainer confirmed the out-of-bounds read oopses the kernel; the inflated index can touch unmapped pages far outside the PART_SIZE-limited trailer buffer, causing a kernel fault, panic, or node crash on HPC clients during routine readdir.