EUVD-2026-108913
GHSA-jjvw-qjpr-6rpv
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain local privilege to modify filesystem features
-
DeliveryEnable ext4 'encrypt' on mounted filesystem
-
ExploitWrite encrypted data with large folios active
-
ExecutionNULL deref in ext4_finish_bio
-
ImpactKernel crash / denial of service
Vulnerability Assessment
| Exploitation Conditions | Requires that the ext4 'encrypt' feature be enabled on an already-mounted filesystem - which bypasses the mount-time check from commit 709f0f1f1bf5 that otherwise disables large folios when 'encrypt' is set - followed by writing encrypted data, which triggers the NULL pointer dereference. Enabling a filesystem feature on a live mount is a privileged administrative action, so exploitation is gated by local privilege (not remote). Limiting factors: local-only access, the non-default action of toggling the encrypt feature post-mount, and a narrow affected kernel range (v6.19 to v7.2); v7.3 is not affected due to refactoring, and the fix ships in 7.2.10. |
| Impact | This is a locally-exploitable, privilege-dependent kernel crash (NULL pointer dereference in ext4_finish_bio) rather than a remotely weaponizable flaw. The supplied CVSS vector (AV:L/AC:H/PR:L/UI:N, base 7.0) and its C:H/I:H/A:H impact set conflict with the actual mechanism described: the crash is a denial-of-service, and the 'Denial Of Service' tag agrees - the confidentiality and integrity impacts in the input vector are not supported by the description, which shows only a kernel oops. Exploitation status is 'no public exploit identified at time of analysis' (no KEV, no PoC reference; references are only the stable-tree fix commit and the NVD entry). EPSS is low at 0.19% (8th percentile), consistent with a local, config-triggered DoS that is not interesting for mass exploitation. The vendor priority label is 'this_week', which reflects a fix-on-normal-cadence posture, not an emergency; this aligns with the low EPSS and absence of KEV/active exploitation. Net: a real but low-urgency reliability/availability bug requiring privileged local action, not a high-real-risk network threat despite the 7.0 'High' score. |
| Exploit ScenarioDerived | A local user or process with the privilege to enable the ext4 'encrypt' feature on an already-mounted filesystem does so, bypassing the mount-time guard that would normally disable large folios, then writes encrypted data. The large-folio/encryption incompatibility triggers a NULL pointer dereference in ext4_finish_bio during I/O completion, crashing the kernel (denial of service). No public exploit code is identified for this issue. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 24, 2026
Writing encrypted data on Linux kernel 6.19 through 7.2 can trigger a NULL pointer dereference in ext4_finish_bio, crashing the kernel from the ext4-rsv-conversion workqueue. The flaw appears when the ext4 'encrypt' feature is enabled on an already-mounted filesystem, which bypasses the mount-time check that normally disables large folios for encrypted inodes; the crash path is local, requires a privileged administrative action (toggling a filesystem feature on a live mount), and affects availability only. The vendor fix ships in 7.2.10 (commit 40554d1221e3d2ff2e0d192b74a05d89eb3620e7), 7.3 is not affected due to later refactoring, EPSS is low at 0.19% (8th percentile), and no public exploit or CISA KEV entry was identified at time of analysis.
RemediationAI
Vendor-released patch: kernel 7.2.10, containing upstream commit 40554d1221e3d2ff2e0d192b74a05d89eb3620e7 (https://git.kernel.org/stable/c/40554d1221e3d2ff2e0d192b74a05d89eb3620e7), which disables large folios on encrypted inodes the same way it is already done for inodes using data journaling; upgrading to 7.3 also avoids the issue because that code was refactored. Where an immediate kernel update is not possible, the practical compensating control is procedural: do not enable the ext4 'encrypt' feature on an already-mounted filesystem - configure it at filesystem creation or mount time so the mount-time large-folio check in commit 709f0f1f1bf5 applies - since it is precisely the post-mount feature toggle that bypasses that guard; the trade-off is that encryption must be in place before the filesystem is brought into service, and any host where 'encrypt' was already enabled live should be treated as exposed to the crash until patched. Because triggering the fault requires a privileged local administrator to change the feature state and then write encrypted data, restricting who can run filesystem feature changes on mounted volumes reduces the window, but the complete fix is the updated kernel.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
ext4 gained support for large folios (multi-page folios in the page cache), and commit 709f0f1f1bf5 added mount-time checks that disable large folios when large block sizes exceed page size or when the filesystem 'encrypt' feature is set, because large folios are incompatible with those configurations. The mount-time-only nature of that guard leaves a gap: if the 'encrypt' feature is enabled on a filesystem that is already mounted, the check has already run and large folios remain active on encrypted inodes. Writing encrypted data in that state dereferences a NULL pointer at offset 0x28 inside ext4_finish_bio, reached via ext4_release_io_end / ext4_end_io_end from the ext4-rsv-conversion workqueue (ext4_end_io_rsv_work), producing a kernel BUG and loss of availability. The resolution extends the existing per-inode guard - already applied to inodes using data journaling - so large folios are disabled on encrypted inodes regardless of when the feature was enabled. No CWE identifier is supplied in the available data, and the underlying interaction between large folios and the encrypt path beyond the above is not described in the sources.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Local action requiring privilege to enable the encrypt feature on a mount (PR:H, AV:L); the NULL deref is a reliable crash (AC:L) causing only availability loss (A:H), with no confidentiality or integrity impact.
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
Lifecycle Timeline
4DescriptionCVE.org
In the Linux kernel, the following vulnerability has been resolved:
ext4: don't enable large folios on encrypted inodes
Commit 709f0f1f1bf5 ("ext4: add checks for large folio incompatibilities when BS > PS") disables large folios at mount time if the "encrypt" feature is set. However, enabling that feature on a mounted filesystem circumvents that check, and writing encrypted data results in a crash:
BUG: kernel NULL pointer dereference, address: 0000000000000028 Workqueue: ext4-rsv-conversion ext4_end_io_rsv_work RIP: 0010:ext4_finish_bio+0xf7/0x3e0 Call Trace: ext4_release_io_end+0x51/0x110 ext4_end_io_end+0x4c/0xe0 ext4_end_io_rsv_work+0xb3/0x100
Fix this by disabling large folios on encrypted inodes, as is already done for inodes that use data journaling.
This affects all kernels between v6.19 and v7.2, but it is not needed in v7.3, where the code was significantly refactored.
Executive ViewAI
CVE-2026-98941 is a high-severity availability flaw in the Linux kernel's ext4 filesystem that can cause a system crash when the encryption feature is enabled on a live mount. While exploitation requires privileged access and no public exploit exists, the vulnerability affects all Linux systems running kernels 6.19 through 7.2 with ext4 encryption enabled, potentially disrupting critical services and operations. Leadership should prioritize patching to maintain system uptime and avoid business interruption.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
Exploit-DB