CVE-2025-40307
NoneCVSS
—
EPSS
0.1%
Published
Dec 8, 2025
CISA due date
—
Cloudanix analysis
A bug in Linux support for certain external storage formats could let a specially made disk overwrite its own file listings, risking data loss when the disk is plugged in.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Moderate
- Impact
- Data Tampering
- Component
- OS kernel
- Class
- Improper Input Validation
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
The flaw allows a malicious exFAT image to present an allocation bitmap whose clusters are not marked in-use; the kernel reads and trusts this bitmap without validation, permitting exfat_mkdir to zero a cluster that holds active directory entries and bitmap data, enabling reallocation of already-allocated clusters.
Why it matters to the business
Mounting untrusted removable media or images on affected kernels risks silent filesystem corruption and data loss on exFAT volumes; the issue affects any Linux deployment that handles external drives or user-supplied images, though low exploitability and absence from KEV reduce immediate enterprise urgency 322 days after publication.
How an attack unfolds
An attacker prepares an exFAT image whose allocation bitmap start cluster is marked free, mounts the image on a vulnerable kernel, triggers directory creation which zeros the bitmap cluster, and thereby reclaims already-allocated entries for reuse, resulting in metadata corruption.
How to fix it
Upgrade the Linux kernel to a version containing commit 6bc58b4c53795ab5fe00648344aa7d9d61175f90 or later; for stable trees apply the corresponding backport; avoid mounting untrusted exFAT images until patched.
How to confirm the fix worked
Confirm the running kernel contains the exfat_test_bitmap_range validation function and rejects images with unmarked bitmap clusters; test with crafted images that previously triggered the zeroing behavior.
Typical attack path
- Craft exFAT image with invalid allocation bitmap cluster bits
- Mount the image on a vulnerable kernel
- Execute mkdir or equivalent directory creation
- Observe bitmap and directory entry zeroing and reallocation
How to detect it
Review kernel logs for exfat allocation bitmap anomalies or unexpected cluster zeroing around the time of image mounts; correlate with user-space processes that create directories on newly mounted exFAT volumes.
What your security team should do
- Apply the referenced kernel commit or distribution update to all systems handling exFAT volumes
- Restrict exFAT mounting to trusted media only via mount options or policy
- Monitor kernel logs for exfat bitmap-related warnings after patching
The record
In the Linux kernel, the following vulnerability has been resolved: exfat: validate cluster allocation bits of the allocation bitmap syzbot created an exfat image with cluster bits not set for the allocation bitmap. exfat-fs reads and uses the allocation bitmap without checking this. The problem is that if the start cluster of the allocation bitmap is 6, cluster 6 can be allocated when creating a directory with mkdir. exfat zeros out this cluster in exfat_mkdir, which can delete existing entries. This can reallocate the allocated entries. In addition, the allocation bitmap is also zeroed out, so cluster 6 can be reallocated. This patch adds exfat_test_bitmap_range to validate that clusters used for the allocation bitmap are correctly marked as in-use.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|---|---|---|
| Linux | Kernel | 0 | 6.12.58 |
| Linux | Kernel | 5.7.0 | 6.12.58 |
| openSUSE:Leap 16.0 | dtb-aarch64 | 0 | 6.12.0-160000.9.1 |
| openSUSE:Leap 16.0 | kernel-64kb | 0 | 6.12.0-160000.9.1 |
| openSUSE:Leap 16.0 | kernel-azure | 0 | 6.12.0-160000.9.1 |
| openSUSE:Leap 16.0 | kernel-default | 0 | 6.12.0-160000.9.1 |
| openSUSE:Leap 16.0 | kernel-default-base | 0 | 6.12.0-160000.9.1.160000.2.6 |
| openSUSE:Leap 16.0 | kernel-docs | 0 | 6.12.0-160000.9.1 |
| openSUSE:Leap 16.0 | kernel-kvmsmall | 0 | 6.12.0-160000.9.1 |
| openSUSE:Leap 16.0 | kernel-obs-build | 0 | 6.12.0-160000.9.1 |
| openSUSE:Leap 16.0 | kernel-obs-qa | 0 | 6.12.0-160000.9.1 |
| openSUSE:Leap 16.0 | kernel-rt | 0 | 6.12.0-160000.9.1 |
| openSUSE:Leap 16.0 | kernel-source | 0 | 6.12.0-160000.9.1 |
| openSUSE:Leap 16.0 | kernel-syms | 0 | 6.12.0-160000.9.1 |
| openSUSE:Leap 16.0 | kernel-zfcpdump | 0 | 6.12.0-160000.9.1 |
Related vulnerabilities
- CVE-2026-23226 In the Linux kernel, the following vulnerability has been resolved: ksmbd: add chann_lock… Also affects Kernel
- CVE-2026-23225 In the Linux kernel, the following vulnerability has been resolved: sched/mmcid: Don't… Also affects Kernel
- CVE-2026-23230 In the Linux kernel, the following vulnerability has been resolved: smb: client: split… Also affects Kernel
- CVE-2026-23224 In the Linux kernel, the following vulnerability has been resolved: erofs: fix UAF issue… Also affects Kernel
- CVE-2026-23227 In the Linux kernel, the following vulnerability has been resolved: drm/exynos: vidi: use… Also affects Kernel
- CVE-2026-23223 In the Linux kernel, the following vulnerability has been resolved: xfs: fix UAF in… Also affects Kernel
- CVE-2026-23228 In the Linux kernel, the following vulnerability has been resolved: smb: server: fix leak… Also affects Kernel
- CVE-2026-23229 In the Linux kernel, the following vulnerability has been resolved: crypto: virtio - Add… Also affects Kernel