ghsa-wp53-jh6w-3pf7
Vulnerability from github
In the Linux kernel, the following vulnerability has been resolved:
ext4: refresh inline data size before write operations
The cached ei->i_inline_size can become stale between the initial size check and when ext4_update_inline_data()/ext4_create_inline_data() use it. Although ext4_get_max_inline_size() reads the correct value at the time of the check, concurrent xattr operations can modify i_inline_size before ext4_write_lock_xattr() is acquired.
This causes ext4_update_inline_data() and ext4_create_inline_data() to work with stale capacity values, leading to a BUG_ON() crash in ext4_write_inline_data():
kernel BUG at fs/ext4/inline.c:1331! BUG_ON(pos + len > EXT4_I(inode)->i_inline_size);
The race window: 1. ext4_get_max_inline_size() reads i_inline_size = 60 (correct) 2. Size check passes for 50-byte write 3. [Another thread adds xattr, i_inline_size changes to 40] 4. ext4_write_lock_xattr() acquires lock 5. ext4_update_inline_data() uses stale i_inline_size = 60 6. Attempts to write 50 bytes but only 40 bytes actually available 7. BUG_ON() triggers
Fix this by recalculating i_inline_size via ext4_find_inline_data_nolock() immediately after acquiring xattr_sem. This ensures ext4_update_inline_data() and ext4_create_inline_data() work with current values that are protected from concurrent modifications.
This is similar to commit a54c4613dac1 ("ext4: fix race writing to an inline_data file while its xattrs are changing") which fixed i_inline_off staleness. This patch addresses the related i_inline_size staleness issue.
{
"affected": [],
"aliases": [
"CVE-2025-68264"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-16T15:15:55Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: refresh inline data size before write operations\n\nThe cached ei-\u003ei_inline_size can become stale between the initial size\ncheck and when ext4_update_inline_data()/ext4_create_inline_data() use\nit. Although ext4_get_max_inline_size() reads the correct value at the\ntime of the check, concurrent xattr operations can modify i_inline_size\nbefore ext4_write_lock_xattr() is acquired.\n\nThis causes ext4_update_inline_data() and ext4_create_inline_data() to\nwork with stale capacity values, leading to a BUG_ON() crash in\next4_write_inline_data():\n\n kernel BUG at fs/ext4/inline.c:1331!\n BUG_ON(pos + len \u003e EXT4_I(inode)-\u003ei_inline_size);\n\nThe race window:\n1. ext4_get_max_inline_size() reads i_inline_size = 60 (correct)\n2. Size check passes for 50-byte write\n3. [Another thread adds xattr, i_inline_size changes to 40]\n4. ext4_write_lock_xattr() acquires lock\n5. ext4_update_inline_data() uses stale i_inline_size = 60\n6. Attempts to write 50 bytes but only 40 bytes actually available\n7. BUG_ON() triggers\n\nFix this by recalculating i_inline_size via ext4_find_inline_data_nolock()\nimmediately after acquiring xattr_sem. This ensures ext4_update_inline_data()\nand ext4_create_inline_data() work with current values that are protected\nfrom concurrent modifications.\n\nThis is similar to commit a54c4613dac1 (\"ext4: fix race writing to an\ninline_data file while its xattrs are changing\") which fixed i_inline_off\nstaleness. This patch addresses the related i_inline_size staleness issue.",
"id": "GHSA-wp53-jh6w-3pf7",
"modified": "2025-12-16T15:30:47Z",
"published": "2025-12-16T15:30:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68264"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/210ac60a86a3ad2c76ae60e0dc71c34af6e7ea0b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/58df743faf21ceb1880f930aa5dd428e2a5e415d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/892e1cf17555735e9d021ab036c36bc7b58b0e3b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ca43ea29b4c4d2764aec8a26cffcfb677a871e6e"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.