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

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

CVE-2026-63815

f2fs: bound i_inline_xattr_size for non-inline-xattr inodes

8.4 EPSS 0.1% AV:L

Published 2026-07-19 (3 months ago) by the Linux kernel CNA. Subsystem fs/f2fs. Debian urgency: not yet assigned.

What to do, per Debian release

Debian's own status for CVE-2026-63815 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 12bookwormfixedDLA-4720-1 · 2026-08-05 · text6.1.180-1Update the kernel and reboot. DLA-4720-1 shipped the fix on 2026-08-05, in 6.1.180-1. A running kernel keeps the old code until the machine restarts.
Debian 13trixiefixedDSA-6393-1 · 2026-07-21 · text6.12.96-1Update the kernel and reboot. DSA-6393-1 shipped the fix on 2026-07-21, in 6.12.96-1. A running kernel keeps the old code until the machine restarts.
Debian 14forkyfixed7.1.3-1Update the kernel and reboot. Fixed in 7.1.3-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesidfixed7.1.3-1Update the kernel and reboot. Fixed in 7.1.3-1. A running kernel keeps the old code until the machine restarts.
Debian 12bookworm · linux-6.12fixedDLA-4724-1 · 2026-08-07 · text6.12.100-1~deb12u1Update the kernel and reboot. DLA-4724-1 shipped the fix on 2026-08-07, in 6.12.100-1~deb12u1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

When the flexible_inline_xattr feature is enabled, do_read_inode() loads the on-disk i_inline_xattr_size unconditionally: if (f2fs_sb_has_flexible_inline_xattr(sbi)) fi->i_inline_xattr_size = le16_to_cpu(ri->i_inline_xattr_size); but sanity_check_inode() only range-checks it when the inode also has the FI_INLINE_XATTR flag set. An inode that carries an inline dentry or inline data but not FI_INLINE_XATTR -- the normal layout for an inline directory -- therefore keeps a fully attacker-controlled i_inline_xattr_size from a crafted image. get_inline_xattr_addrs() returns that value with no flag gating, so it feeds the inode geometry: MAX_INLINE_DATA() = 4 * (CUR_ADDRS_PER_INODE - i_inline_xattr_size - 1) NR_INLINE_DENTRY() = MAX_INLINE_DATA() * BITS_PER_BYTE / (...) addrs_per_page() = CUR_ADDRS_PER_INODE - i_inline_xattr_size A large i_inline_xattr_size drives MAX_INLINE_DATA() and NR_INLINE_DENTRY() negative, so make_dentry_ptr_inline() sets d->max (int) to a negative value. The inline directory walk then compares an unsigned long bit_pos against that negative d->max, which is promoted to a huge unsigned bound, and reads far past the inline area: while (bit_pos < d->max) /* fs/f2fs/dir.c */ ... test_bit_le(bit_pos, d->bitmap) / d->dentry[bit_pos] ... Mounting a crafted image and reading such a directory triggers an out-of-bounds read in f2fs_fill_dentries(); the same underflow also corrupts ADDRS_PER_INODE for regular files. Validate i_inline_xattr_size against MAX_INLINE_XATTR_SIZE whenever the flexible_inline_xattr feature is enabled -- i.e. whenever the value is loaded from disk and consumed -- and keep the lower MIN_INLINE_XATTR_SIZE bound gated on inodes that actually carry an inline xattr, so legitimate inodes with i_inline_xattr_size == 0 are still accepted.

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

What this is
F2FS FILE SYSTEMMAINTAINERS section matched on fs/f2fs/ · linux-f2fs-devel@lists.sourceforge.net · Maintained
Kernel module
f2fs

Check it on the machine

grep -w CONFIG_F2FS_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 f2fs

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, sid, bookworm · linux-6.12Mnot 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_F2FS_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-07-19 (3 months ago)source
CVSS
8.4 high
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it
Attack vector
local (AV:L)source
EPSS
0.14%, higher than 3.0% of all CVEssource
CISA KEV
not listedthe KEV catalogue
Debian urgency
not yet assignedsource
Subsystem
fs/f2fs

Upstream fixes

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

IntroducedFixed inCommit
4.155.10.2613c8d6b4093ae
4.155.15.212a08ee30dcbef
4.156.1.178c3e05522daae
4.156.6.14576e1a05cf6d4
4.156.12.962a9f9791653b
4.156.18.394ce2d52f680c
4.157.1.316bc237ce3c4
4.157.2378acf3cf19b

Debian advisories

AdvisoryDateShipped toDebian
DLA-4724-12026-08-07bookworm 6.12.100-1~deb12u1tracker
DLA-4723-12026-08-07bullseye 6.1.180-1~deb11u1tracker
DLA-4720-12026-08-05bookworm 6.1.180-1tracker
DLA-4717-12026-08-05bullseye 5.10.262-1tracker
DSA-6393-12026-07-21trixie 6.12.96-1tracker

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:LAttack vector, local
Exploitation requires local syscalls (mount on a block/loop device, then getdents/lookup on an inline directory); f2fs is not reachable via a network-facing in-kernel protocol handler.
AC:LAttack complexity, low
The attacker fully controls the on-disk inode fields in a crafted f2fs image and can reliably trigger the bug by mounting that image and reading the directory; no race or rare runtime state is required.
PR:NPrivileges required, none
An attacker can craft a malicious f2fs image offline with no privileges on the target system; exploitation is triggered when the image is mounted and its inline directory is read, including by privileged auto-mount services on shared/kiosk systems.
UI:NUser interaction, none
No victim user action beyond the attacker's own mount and directory read is required; an attacker with user-namespace mount capability can self-trigger without involving another user.
S:UScope, unchanged
Impact is kernel memory corruption and information disclosure within the same kernel security boundary, not a cross-boundary escape such as guest-to-host VM breakout.
C:HConfidentiality impact, high
The corrupted geometry drives out-of-bounds reads via test_bit_le(), dentry, and filename pointer accesses far beyond the inline data area, enabling kernel memory disclosure.
I:HIntegrity impact, high
Integer underflow in inode geometry also corrupts ADDRS_PER_INODE/addrs_per_page calculations for regular files, creating memory corruption that can be leveraged for out-of-bounds writes and further exploitation.
A:HAvailability impact, high
Reading far past the inline area can cause kernel oops or panic, and the corrupted address calculations can crash or destabilize the kernel during subsequent file operations.