data built 2026-10-19T13:16:53Z

Look up another CVE · open CVE-2026-72160 in the interactive tracker

CVE-2026-72160

ocfs2: reject dinodes with non-canonical i_mode type

8.8 EPSS 0.7% AV:N

Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem fs/ocfs2. Debian urgency: not yet assigned.

What to do, per Debian release

Debian's own status for CVE-2026-72160 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

ReleaseStatus VersionWhat this means
Debian 12bookwormfixed6.1.180-1Update the kernel and reboot. Fixed in 6.1.180-1. A running kernel keeps the old code until the machine restarts.
Debian 13trixiefixed6.12.100-1Update the kernel and reboot. Fixed in 6.12.100-1. A running kernel keeps the old code until the machine restarts.
Debian 14forkyfixed7.1.5-1Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesidfixed7.1.5-1Update 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

Patch series "ocfs2: harden inode validators against forged metadata", v2. This series adds three structural checks to OCFS2 dinode validation so malformed on-disk fields are rejected before ocfs2_populate_inode() copies them into the in-core inode. The checks cover: - i_mode values whose type bits do not name a canonical POSIX file type; - non-device dinodes whose id1.dev1.i_rdev field is non-zero; and - non-inline dinodes that claim non-zero i_size while i_clusters is zero, covering directories unconditionally and regular files on non-sparse volumes. The normal read path reports these through ocfs2_error(), matching the existing suballoc-slot, inline-data, chain-list, and refcount checks. The online filecheck path uses the same structural predicates but keeps its own reporting contract, returning OCFS2_FILECHECK_ERR_INVALIDINO instead of calling ocfs2_error(). This patch (of 3): ocfs2_validate_inode_block() currently accepts any non-zero i_mode value. ocfs2_populate_inode() then copies that mode verbatim into inode->i_mode and dispatches on i_mode & S_IFMT to the file/dir/symlink/special_file iops; an unrecognised type falls through to ocfs2_special_file_iops and init_special_inode(). Reject dinodes whose type bits do not name one of the seven canonical POSIX file types. Use fs_umode_to_ftype(), the same generic file-type conversion helper OCFS2 already uses for directory entries, so the accepted inode type set matches the kernel file-type vocabulary instead of open-coding a local switch. Apply the same structural check to the online filecheck read path. filecheck keeps its own error namespace, so it reports malformed i_mode through the filecheck logger and OCFS2_FILECHECK_ERR_INVALIDINO instead of calling ocfs2_error(), but it must not allow a malformed dinode to proceed into ocfs2_populate_inode().

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/ocfs2/inode.c

What this is
ORACLE CLUSTER FILESYSTEM 2 (OCFS2)MAINTAINERS section matched on fs/ocfs2/ · ocfs2-devel@lists.linux.dev · Supported
Kernel module
ocfs2

Check it on the machine

grep -w CONFIG_OCFS2_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 ocfs2

Prints 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, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.

  • bookworm, trixie, forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64
M
a module where it is built at all; some flavours do not build it
Build switch
CONFIG_OCFS2_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
8.8 high
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it
Attack vector
network (AV:N)source
EPSS
0.65%, higher than 50.2% of all CVEssource
CISA KEV
not listedthe KEV catalogue
Debian urgency
not yet assignedsource
Subsystem
fs/ocfs2

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

IntroducedFixed inCommit
2.6.295.10.2612e3aac33988e
2.6.295.15.212fb024ea29f6c
2.6.296.1.178157d31ef4503
2.6.296.6.145a5b555bcabbb
2.6.296.12.9782afe1355835
2.6.296.18.404db3b6a2a8ec
2.6.297.1.5b858f2d57cfc
2.6.297.25366a017099c

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
OCFS2 registers export_operations, so when kernel nfsd serves an OCFS2-backed NFS export on shared cluster storage, remote NFS LOOKUP/GETFH requests drive ocfs2_iget()->ocfs2_read_inode_block()->ocfs2_validate_inode_block() over the network without local syscalls on the server.
AC:LAttack complexity, low
An attacker can deterministically set a non-canonical i_mode (e.g., permission bits without S_IFMT) in a crafted OCFS2 dinode and trigger ocfs2_populate_inode() through a normal pathname lookup or NFS file handle resolution; no races or uncontrollable heap layout are required.
PR:LPrivileges required, low
Triggering the read path requires only authenticated NFS client access to an exported path containing the forged dinode, or mounting a crafted OCFS2 loop image where CAP_SYS_ADMIN is obtainable by an unprivileged user via user namespaces, matching comparable OCFS2 metadata CVEs.
UI:NUser interaction, none
No victim interaction is needed once forged dinode metadata exists on the volume: a remote NFS client or the attacker mounting a crafted local image can perform the triggering lookup themselves without any third party opening files or mounting the filesystem.
S:UScope, unchanged
Type confusion corrupts in-core inode dispatch state (i_mode/i_rdev/i_op/i_fop mismatch) on the host processing forged OCFS2 metadata; this does not cross VM, container, or IOMMU boundaries into another security authority.
C:HConfidentiality impact, high
Non-canonical i_mode passes validation and populates the inode with attacker-controlled i_rdev before falling through to init_special_inode(), creating type-confused in-core metadata that can expose kernel memory through subsequent VFS getattr and page-cache operations.
I:HIntegrity impact, high
Accepting forged i_mode installs ocfs2_special_file_iops and attacker-controlled i_rdev on an inode whose type bits are not a valid POSIX special file, leaving inconsistent i_op/i_fop/a_ops state constituting exploitable type confusion writable through further VFS operations.
A:HAvailability impact, high
The confused inode state can provoke kernel oops or panics when subsequent VFS operations (e.g., open with missing i_fop, or page-cache I/O via mismatched ocfs2_aops) are attempted on the malformed inode, denying availability until reboot.