CVE-2024-49882: ext4: fix double brelse() the buffer of the extents path
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix double brelse() the buffer of the extents path
In ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has been
released, otherwise it may be released twice. An example of what triggers
this is as follows:
split2 map split1
|--------|-------|--------|
ext4_ext_map_blocks
ext4_ext_handle_unwritten_extents
ext4_split_convert_extents
// path->p_depth == 0
ext4_split_extent
// 1. do split1
ext4_split_extent_at
|ext4_ext_insert_extent
| ext4_ext_create_new_leaf
| ext4_ext_grow_indepth
| le16_add_cpu(&neh->eh_depth, 1)
| ext4_find_extent
| // return -ENOMEM
|// get error and try zeroout
|path = ext4_find_extent
| path->p_depth = 1
|ext4_ext_try_to_merge
| ext4_ext_try_to_merge_up
| path->p_depth = 0
| brelse(path[1].p_bh) ---> not set to NULL here
|// zeroout success
// 2. update path
ext4_find_extent
// 3. do split2
ext4_split_extent_at
ext4_ext_insert_extent
ext4_ext_create_new_leaf
ext4_ext_grow_indepth
le16_add_cpu(&neh->eh_depth, 1)
ext4_find_extent
path[0].p_bh = NULL;
path->p_depth = 1
read_extent_tree_block ---> return err
// path[1].p_bh is still the old value
ext4_free_ext_path
ext4_ext_drop_refs
// path->p_depth == 1
brelse(path[1].p_bh) ---> brelse a buffer twice
Finally got the following WARRNING when removing the buffer from lru:
============================================
VFS: brelse: Trying to free free buffer
WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90
CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716
RIP: 0010:__brelse+0x58/0x90
Call Trace:
<TASK>
__find_get_block+0x6e7/0x810
bdev_getblk+0x2b/0x480
__ext4_get_inode_loc+0x48a/0x1240
ext4_get_inode_loc+0xb2/0x150
ext4_reserve_inode_write+0xb7/0x230
__ext4_mark_inode_dirty+0x144/0x6a0
ext4_ext_insert_extent+0x9c8/0x3230
ext4_ext_map_blocks+0xf45/0x2dc0
ext4_map_blocks+0x724/0x1700
ext4_do_writepages+0x12d6/0x2a70
[...]
============================================
Security readout for executives and security teams
Plain-English summary
A Linux ext4 filesystem bug can release the same buffer twice during a specific error-recovery path. This may destabilize the kernel and potentially affect system security. Exploitation requires local access according to the supplied CVSS vector; the sources do not establish remote reachability or successful real-world attacks.
Executive priority
Treat this as a high-priority kernel maintenance issue, especially on multi-user or workload-hosting Linux systems using ext4. Patch through normal expedited kernel processes. The sources do not justify an emergency incident declaration because active exploitation and a practical attack chain are not established.
Technical view
During ext4 extent splitting and merge-up handling, ext4_ext_try_to_merge_up() released path[1].p_bh without clearing the pointer. A later extent-tree read failure could pass that stale pointer to ext4_ext_drop_refs(), causing a second brelse(). The kernel fix sets the pointer to NULL after its first release.
Likely exposure
Exposure is limited to Linux systems running an affected kernel and using ext4. The demonstrated path involves filesystem writes, extent manipulation, and specific allocation or block-read failures. The supplied affected-version data is ambiguous, so organizations should confirm exposure through their distribution's kernel advisories and fix backports.
Exploitation context
The supplied CVSS 3.1 score is 7.8, with local access and low privileges required. The bundle marks this CVE as absent from KEV and provides no evidence of active exploitation, a public proof of concept, or reliable privilege escalation. The demonstrated result is a kernel warning from double buffer release.
Researcher notes
The supplied trace depends on a complex sequence involving extent splitting, merge-up, allocation failure, zeroout recovery, and a later block-read error. The evidence demonstrates stale buffer-pointer reuse and a double release. It does not establish resulting code execution, confidentiality loss, filesystem corruption, or exploit reliability despite the CVSS impact ratings.
Mitigation direction
Install a vendor-supported kernel containing the applicable stable fix or distribution backport.
Reboot affected systems so the corrected kernel is actively running.
Consult distribution advisories when package versions do not match upstream kernel versions.
Prioritize shared systems where untrusted local users or workloads can write to ext4 filesystems.
Validation and detection
Inventory running kernel versions and identify systems with ext4 filesystems mounted.
Verify vendor changelogs or advisories confirm inclusion of the relevant upstream fix.
After updating and rebooting, confirm the running kernel matches the patched package.
Review kernel logs for "VFS: brelse: Trying to free free buffer" warnings.
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-49882 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.