CVE-2024-49884: ext4: fix slab-use-after-free in ext4_split_extent_at()
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix slab-use-after-free in ext4_split_extent_at()
We hit the following use-after-free:
==================================================================
BUG: KASAN: slab-use-after-free in ext4_split_extent_at+0xba8/0xcc0
Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40
CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724
Call Trace:
<TASK>
kasan_report+0x93/0xc0
ext4_split_extent_at+0xba8/0xcc0
ext4_split_extent.isra.0+0x18f/0x500
ext4_split_convert_extents+0x275/0x750
ext4_ext_handle_unwritten_extents+0x73e/0x1580
ext4_ext_map_blocks+0xe20/0x2dc0
ext4_map_blocks+0x724/0x1700
ext4_do_writepages+0x12d6/0x2a70
[...]
Allocated by task 40:
__kmalloc_noprof+0x1ac/0x480
ext4_find_extent+0xf3b/0x1e70
ext4_ext_map_blocks+0x188/0x2dc0
ext4_map_blocks+0x724/0x1700
ext4_do_writepages+0x12d6/0x2a70
[...]
Freed by task 40:
kfree+0xf1/0x2b0
ext4_find_extent+0xa71/0x1e70
ext4_ext_insert_extent+0xa22/0x3260
ext4_split_extent_at+0x3ef/0xcc0
ext4_split_extent.isra.0+0x18f/0x500
ext4_split_convert_extents+0x275/0x750
ext4_ext_handle_unwritten_extents+0x73e/0x1580
ext4_ext_map_blocks+0xe20/0x2dc0
ext4_map_blocks+0x724/0x1700
ext4_do_writepages+0x12d6/0x2a70
[...]
==================================================================
The flow of issue triggering is as follows:
ext4_split_extent_at
path = *ppath
ext4_ext_insert_extent(ppath)
ext4_ext_create_new_leaf(ppath)
ext4_find_extent(orig_path)
path = *orig_path
read_extent_tree_block
// return -ENOMEM or -EIO
ext4_free_ext_path(path)
kfree(path)
*orig_path = NULL
a. If err is -ENOMEM:
ext4_ext_dirty(path + path->p_depth)
// path use-after-free !!!
b. If err is -EIO and we have EXT_DEBUG defined:
ext4_ext_show_leaf(path)
eh = path[depth].p_hdr
// path also use-after-free !!!
So when trying to zeroout or fix the extent length, call ext4_find_extent()
to update the path.
In addition we use *ppath directly as an ext4_ext_show_leaf() input to
avoid possible use-after-free when EXT_DEBUG is defined, and to avoid
unnecessary path updates.
Security readout for executives and security teams
Plain-English summary
A Linux ext4 filesystem flaw can access memory after it has been freed during certain write operations and error conditions. A locally authenticated, low-privileged attacker may be able to cause serious confidentiality, integrity, or availability impact. The supplied evidence does not establish active exploitation.
Executive priority
Treat this as a high-priority kernel maintenance issue, especially on shared systems offering local execution and using ext4. Schedule vendor-approved updates promptly. Emergency internet-edge action is not indicated by the local attack vector or current exploitation evidence, but delayed patching preserves a potentially high-impact kernel weakness.
Technical view
ext4_split_extent_at() can retain a stale extent path after ext4_find_extent() encounters ENOMEM or EIO, frees the path, and clears the original pointer. Later dirtying or EXT_DEBUG processing can read the freed slab object. Stable-kernel commits refresh the path and use the current pointer for debug output.
Likely exposure
Systems using ext4 on a listed affected Linux kernel branch are potential candidates. The CVSS vector indicates local, low-privileged access rather than direct network exploitation. Distribution backports may affect status, so compare the installed kernel package with vendor advisories and the applicable stable-kernel commit.
Exploitation context
The documented trigger involves ext4 writeback and unwritten-extent processing when extent lookup returns an out-of-memory or I/O error. No user interaction is required after local access. The CVE is not listed as KEV, and the supplied sources provide no evidence of active exploitation or public weaponization.
Researcher notes
KASAN demonstrated a two-byte read from a freed slab allocation. The vulnerable path follows ext4_ext_insert_extent() into ext4_find_extent(), where failure cleanup invalidates the caller's path. No CWE is supplied. The sources establish the memory-safety defect and fix, but do not demonstrate reliable privilege escalation or other exploitation.
Mitigation direction
Install a distribution kernel containing the applicable upstream stable fix, following vendor guidance.
For Debian LTS systems, consult the cited Debian security advisory before scheduling the kernel update.
Prioritize ext4 systems that permit untrusted users or workloads to execute locally.
Validation and detection
Inventory running kernel releases and identify systems mounting ext4 filesystems.
Compare each kernel package against its distribution advisory or the applicable stable fix commit.
After maintenance, confirm systems are running the updated kernel package.
Review kernel diagnostics for ext4 writeback faults or use-after-free reports.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-49884 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.