Look up another CVE · open CVE-2026-72369 in the interactive tracker
CVE-2026-72369
minix: avoid overflow in bitmap block count calculation
Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem fs/minix. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-72369 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 | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| 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
minix_check_superblock() uses minix_blocks_needed() to verify that the on-disk imap and zmap block counts are large enough for the advertised inode and zone counts. The helper currently performs DIV_ROUND_UP() in unsigned int arithmetic. A Minix v3 image can set s_ninodes or s_zones near UINT_MAX so the addition inside DIV_ROUND_UP() wraps to zero. That makes a zero imap/zmap block count look valid, after which minix_fill_super() can dereference s_imap[0] or s_zmap[0] even though no bitmap buffers were allocated. Impact: mounting a crafted Minix v3 image whose s_ninodes or s_zones is near UINT_MAX makes minix_check_superblock() accept a zero bitmap-block count and minix_fill_super() dereference s_imap[0]/s_zmap[0], panicking the kernel. The divisor is the bitmap capacity in bits, blocksize * 8, which is always a power of two: minix_fill_super() obtains the block size through sb_set_blocksize(), and blk_validate_block_size() rejects any size that is not a power of two. Use DIV_ROUND_UP_POW2(), which divides before adding the round-up term and so cannot overflow for a power-of-two divisor.
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/minix/minix.h
- What this is
- FILESYSTEMS (VFS and infrastructure)MAINTAINERS section matched on fs/* · linux-fsdevel@vger.kernel.org · Maintained
Show whether Debian builds this, per release
Not established. This site could not find the build rule for the affected file in the kernel trees Debian ships, so it has no answer about whether Debian compiles this code. Read that as unknown, never as absent.
- bookworm, trixie, forky, sid?
- ?
- not established - no Makefile entry for the affected file
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
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
Signals
- Published
- 2026-08-15 (2 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.18%, higher than 6.6% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- fs/minix
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.6.128 | 6.6.145 | a11ebaab50d2 |
| 6.12.75 | 6.12.97 | 959c95340a9e |
| 6.18.16 | 6.18.40 | abe3536a4bed |
| 7.0 | 7.1.5 | 8a29e60e2176 |
| 7.0 | 7.2 | fb3e566cafc3 |
| 5.10.252 | 0 | 0 |
| 5.15.202 | 0 | 0 |
| 6.1.165 | 0 | 0 |
| 6.19.6 | 0 | 0 |
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 bug is reached only when the kernel parses a crafted Minix V3 on-disk superblock during block-device mount (mount(2)/fsopen+fsmount → get_tree_bdev → minix_fill_super); Minix is not exposed via ksmbd, nfsd, or any network protocol handler.
- AC:LAttack complexity, low
- A Minix V3 image with s_ninodes or s_zones near UINT_MAX and zero/small imap/zmap block counts deterministically makes minix_blocks_needed() wrap to zero, bypassing minix_check_superblock() every time without races or attacker-uncontrollable heap layout.
- PR:LPrivileges required, low
- may_mount() requires CAP_SYS_ADMIN in the mount namespace, which unprivileged attackers obtain inside user namespaces; syzbot reproduced this via fuzzed mounts, and a loop-backed image supplies the required block device without init-namespace root.
- UI:NUser interaction, none
- No victim action is needed when the attacker with mount capability (e.g., CAP_SYS_ADMIN in a user/mount namespace) mounts their own malicious Minix v3 loop image; exploitation does not depend on tricking another user to open a file or insert removable media.
- S:UScope, unchanged
- The flaw corrupts or crashes kernel memory during superblock initialization in the mounting context only; it does not cross VM, container, or IOMMU boundaries and matches standard in-kernel memory-corruption/DoS impact (Scope Unchanged).
- C:HConfidentiality impact, high
- With imap_blocks=1 and overflow-bypassed zmap_blocks=0, s_zmap=&map[1] performs an out-of-bounds heap read of a buffer_head pointer past the under-allocated map; s_imap[0]/s_zmap[0] dereferences on zero-block images also read uninitialized/garbage pointers before panic.
- I:HIntegrity impact, high
- After the overflow bypass, minix_set_bit(0,sbi->s_zmap[0]->b_data) uses the OOB-read pointer and can set a bit at an attacker-influenced kernel address; this is exploitable memory corruption during mount, not a guaranteed-safe NULL-only crash.
- A:HAvailability impact, high
- minix_fill_super() dereferences unallocated s_imap[0]/s_zmap[0] entries and faults the kernel (oops/panic); even the one-bit write via corrupted pointers can immediately fault, causing total loss of kernel availability on the affected system.