ext4: use fsdata to track inline data write state and fix race
In the Linux kernel, the following vulnerability has been resolved: ext4: use fsdata to track inline data write state and fix race Instead of checking the live inode state (ext4_has_inline_data(inode) and ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)) in the write_end handlers, use the fsdata parameter of the address space operations to explicitly pass down the state in which write_begin prepared the write. A concurrent thread (such as ext4_page_mkwrite()) can convert the inline data to an extent between write_begin and write_end. If this happens, the write_end handlers would previously miss the inline write_end path and fall through to extent-based write_end logic. However, since block buffers were never allocated in write_begin, this resulted in NULL pointer dereferences or data loss because folio_buffers(folio) was NULL. Define EXT4_WRITE_DATA_INLINE (4) as a bit flag (Bit 2), treating fsdata as bitwise flags rather than mutually exclusive enums to keep states of the write path independent. Communicate this state via fsdata: 1) ext4_write_begin() and ext4_da_write_begin() set the EXT4_WRITE_DATA_INLINE bit in *fsdata via bitwise OR when an inline write is successfully prepared. 2) On entry, ext4_write_begin() clears the EXT4_WRITE_DATA_INLINE bit to safely handle VFS retries (where generic_perform_write() bypasses the fsdata initialization on its retry jump). 3) The write_end handlers perform a bitwise AND to check if the EXT4_WRITE_DATA_INLINE bit is set and in
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 6.18.52, 7.2.6
- CVEs
- CVE-2026-92500
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 3 Nov 2026, 10:17 UTC · Revision 1
Source evidence
ext4: use fsdata to track inline data write state and fix race
core-osv · Original sourcePublished 17 Sept 2026, 16:10 UTC
In the Linux kernel, the following vulnerability has been resolved: ext4: use fsdata to track inline data write state and fix race Instead of checking the live inode state (ext4_has_inline_data(inode) and ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)) in the write_end handlers, use the fsdata parameter of the address space operations to explicitly pass down the state in which write_begin prepared the write. A concurrent thread (such as ext4_page_mkwrite()) can convert the inline data to an extent between write_begin and write_end. If this happens, the write_end handlers would previously miss the inline write_end path and fall through to extent-based write_end logic. However, since block buffers were never allocated in write_begin, this resulted in NULL pointer dereferences or data loss because folio_buffers(folio) was NULL. Define EXT4_WRITE_DATA_INLINE (4) as a bit flag (Bit 2), treating fsdata as bitwise flags rather than mutually exclusive enums to keep states of the write path independent. Communicate this state via fsdata: 1) ext4_write_begin() and ext4_da_write_begin() set the EXT4_WRITE_DATA_INLINE bit in *fsdata via bitwise OR when an inline write is successfully prepared. 2) On entry, ext4_write_begin() clears the EXT4_WRITE_DATA_INLINE bit to safely handle VFS retries (where generic_perform_write() bypasses the fsdata initialization on its retry jump). 3) The write_end handlers perform a bitwise AND to check if the EXT4_WRITE_DATA_INLINE bit is set and in
osv:CVE-2026-92500
Kernel
Fixed versions: 6.18.52, 7.2.6
Complete source record
{
"id": "b109a660fd109de4a5b4ae81dd47db62c99dbd77f0fa098d2fb3a2bedd2ff098",
"url": "https://osv.dev/vulnerability/CVE-2026-92500",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "ext4: use fsdata to track inline data write state and fix race",
"summary": "In the Linux kernel, the following vulnerability has been resolved: ext4: use fsdata to track inline data write state and fix race Instead of checking the live inode state (ext4_has_inline_data(inode) and ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)) in the write_end handlers, use the fsdata parameter of the address space operations to explicitly pass down the state in which write_begin prepared the write. A concurrent thread (such as ext4_page_mkwrite()) can convert the inline data to an extent between write_begin and write_end. If this happens, the write_end handlers would previously miss the inline write_end path and fall through to extent-based write_end logic. However, since block buffers were never allocated in write_begin, this resulted in NULL pointer dereferences or data loss because folio_buffers(folio) was NULL. Define EXT4_WRITE_DATA_INLINE (4) as a bit flag (Bit 2), treating fsdata as bitwise flags rather than mutually exclusive enums to keep states of the write path independent. Communicate this state via fsdata: 1) ext4_write_begin() and ext4_da_write_begin() set the EXT4_WRITE_DATA_INLINE bit in *fsdata via bitwise OR when an inline write is successfully prepared. 2) On entry, ext4_write_begin() clears the EXT4_WRITE_DATA_INLINE bit to safely handle VFS retries (where generic_perform_write() bypasses the fsdata initialization on its retry jump). 3) The write_end handlers perform a bitwise AND to check if the EXT4_WRITE_DATA_INLINE bit is set and in",
"evidence": "osv:CVE-2026-92500",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "6.18.52",
"evidence": "/affected/1/ranges"
},
{
"value": "7.2.6",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "CVE-2026-92500",
"aliases": [
"CVE-2026-92500"
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "3fdcfb668fd78ec92d9bc2daddf1d41e2a8a30bb"
},
{
"fixed": "bd8d74bd46d09905164255b8635fa58b45f41068"
},
{
"fixed": "439aedfd7ae868d1d7b4930afe66091cb979cd5c"
},
{
"fixed": "7edbb323bab2b2a609016014caafdb651c898249"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-92500.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "3.8.0"
},
{
"fixed": "6.18.52"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.19.0"
},
{
"fixed": "7.2.6"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-92500.json"
}
}
],
"modified": "2026-10-28T02:30:27.671392798Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/439aedfd7ae868d1d7b4930afe66091cb979cd5c",
"https://git.kernel.org/stable/c/7edbb323bab2b2a609016014caafdb651c898249",
"https://git.kernel.org/stable/c/bd8d74bd46d09905164255b8635fa58b45f41068",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/92xxx/CVE-2026-92500.json",
"https://nvd.nist.gov/vuln/detail/CVE-2026-92500",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/92xxx/CVE-2026-92500.json"
}
},
"related_cves": [
{
"value": "CVE-2026-92500",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 494443,
"published_at": "2026-09-17T16:10:14.073+00:00"
}