Look up another CVE · open CVE-2026-93816 in the interactive tracker
CVE-2026-93816
f2fs: validate inline dentry name lengths before conversion
Published 2026-09-24 (24 days 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-93816 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 | fixedDLA-4841-1 · 2026-10-17 · text | 6.1.190-1 | Update the kernel and reboot. DLA-4841-1 shipped the fix on 2026-10-17, in 6.1.190-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
Inline dentry conversion copies names out of the inline dentry area before checking that each recorded name length fits in the available filename slots. A corrupted image can therefore make the conversion path read past the inline filename storage while building the regular dentry block. Validate each inline dentry name length against the inline filename area before copying it.
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/inline.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 f2fsPrints 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-09-24 (24 days ago)source
- CVSS
- 7.1 high
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.13%, higher than 2.4% 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
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.7 | 5.10.271 | 6b5552449fc5 |
| 4.7 | 5.15.222 | 6343208fd73f |
| 4.7 | 6.1.189 | 4dd81faa63fd |
| 4.7 | 6.6.158 | aee4e6de71ca |
| 4.7 | 6.12.111 | 2ce0bc5853be |
| 4.7 | 6.18.53 | 7caa8a0ae94b |
| 4.7 | 7.2 | cfcd0e49a178 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4841-1 | 2026-10-17 | bookworm 6.1.190-1 | tracker |
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
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
- The oversized de->name_len is on-disk in the directory inode's inline dentry, not in a network PDU. creat/mkdir/rename reach the patched f2fs_add_inline_entries via f2fs_add_link→f2fs_add_inline_entry→do_convert_inline_dir→f2fs_move_rehashed_dirents (or f2fs_try_convert_inline_dir on same-dir rename); the syscall only supplies a normal filename that forces conversion.
- AC:LAttack complexity, low
- The image sets i_dir_level nonzero (do_read_inode copies ri->i_dir_level with no range check, so conversion uses f2fs_move_rehashed_dirents), fills the inline bitmap so f2fs_room_for_filename fails, and plants a name_len that overruns remaining filename slots. The next creat(2) or recover_dentry add then hits the memcpy with no race.
- PR:NPrivileges required, none
- Crafting the f2fs image takes no account or capability on the target. f2fs_add_inline_entries has no capable() gate; init-namespace CAP_SYS_ADMIN (f2fs_fs_type lacks FS_USERNS_MOUNT) is the victim's or automount helper's mount privilege, not the attacker's.
- UI:RUser interaction, required
- The bad name_len is only consumed after that image is mounted. A victim or trusted helper (udisks/vold) must mount it before f2fs_create/f2fs_rename or roll-forward recover_dentry→f2fs_add_dentry can call f2fs_add_inline_entries; automount does not make this a network bug.
- S:UScope, unchanged
- f2fs_update_dentry's over-read from backup_dentry and any oops stay in the host kernel that mounted the volume. This is not a KVM/Xen guest-to-host escape or an IOMMU/DMA boundary bypass.
- C:HConfidentiality impact, high
- f2fs_add_inline_entries sets fname.disk_name.len from unvalidated de->name_len and f2fs_update_dentry memcpy's that many bytes from the kmalloc'd backup_dentry filename array. A name_len that still fits a regular dentry block (GET_DENTRY_SLOTS<=NR_DENTRY_IN_BLOCK, up to 1705) reads past MAX_INLINE_DATA into adjacent slab; those bytes become the converted name.
- I:NIntegrity impact, none
- f2fs_add_regular_entry only calls f2fs_update_dentry after f2fs_room_for_filename finds GET_DENTRY_SLOTS(name_len) free dest slots, so the memcpy stays inside the new 4K dentry folio. There is no kernel OOB write, UAF, or control-flow hijack; treating any heap over-read as I:H would apply to every infoleak.
- A:HAvailability impact, high
- The same memcpy over-reads f2fs_kmalloc(MAX_INLINE_DATA) (~3KB) by up to ~1700 bytes, which can leave the slab object and oops on unmapped/poisoned memory during conversion, panicking or killing the task. A name_len whose slot count exceeds NR_DENTRY_IN_BLOCK also walks MAX_DIR_HASH_DEPTH allocating empty dir blocks before -ENOSPC.