ext4: don't zero the entire extent if EXT4_EXT_DATA_PARTIAL_VALID1
In the Linux kernel, the following vulnerability has been resolved: ext4: don't zero the entire extent if EXT4_EXT_DATA_PARTIAL_VALID1 When allocating initialized blocks from a large unwritten extent, or when splitting an unwritten extent during end I/O and converting it to initialized, there is currently a potential issue of stale data if the extent needs to be split in the middle. 0 A B N [UUUUUUUUUUUU] U: unwritten extent [--DDDDDDDD--] D: valid data |<- ->| ----> this range needs to be initialized ext4_split_extent() first try to split this extent at B with EXT4_EXT_DATA_ENTIRE_VALID1 and EXT4_EXT_MAY_ZEROOUT flag set, but ext4_split_extent_at() failed to split this extent due to temporary lack of space. It zeroout B to N and mark the entire extent from 0 to N as written. 0 A B N [WWWWWWWWWWWW] W: written extent [SSDDDDDDDDZZ] Z: zeroed, S: stale data ext4_split_extent() then try to split this extent at A with EXT4_EXT_DATA_VALID2 flag set. This time, it split successfully and left a stale written extent from 0 to A. 0 A B N [WW|WWWWWWWWWW] [SS|DDDDDDDDZZ] Fix this by pass EXT4_EXT_DATA_PARTIAL_VALID1 to ext4_split_extent_at() when splitting at B, don't convert the entire extent to written and left it as unwritten after zeroing out B to N. The remaining work is just like the standard two-part split. ext4_split_extent() will pass the EXT4_EXT_DATA_VALID2 flag when it calls ext4_split_extent_at() for the second time, allowing it to properly handle the split. If the split is
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 6.12.75, 6.18.14, 6.19.4, 6.6.130
- CVEs
- CVE-2026-45858
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 4 Nov 2026, 11:53 UTC · Revision 1
Source evidence
ext4: don't zero the entire extent if EXT4_EXT_DATA_PARTIAL_VALID1
core-osv · Original sourcePublished 27 May 2026, 12:15 UTC
In the Linux kernel, the following vulnerability has been resolved: ext4: don't zero the entire extent if EXT4_EXT_DATA_PARTIAL_VALID1 When allocating initialized blocks from a large unwritten extent, or when splitting an unwritten extent during end I/O and converting it to initialized, there is currently a potential issue of stale data if the extent needs to be split in the middle. 0 A B N [UUUUUUUUUUUU] U: unwritten extent [--DDDDDDDD--] D: valid data |<- ->| ----> this range needs to be initialized ext4_split_extent() first try to split this extent at B with EXT4_EXT_DATA_ENTIRE_VALID1 and EXT4_EXT_MAY_ZEROOUT flag set, but ext4_split_extent_at() failed to split this extent due to temporary lack of space. It zeroout B to N and mark the entire extent from 0 to N as written. 0 A B N [WWWWWWWWWWWW] W: written extent [SSDDDDDDDDZZ] Z: zeroed, S: stale data ext4_split_extent() then try to split this extent at A with EXT4_EXT_DATA_VALID2 flag set. This time, it split successfully and left a stale written extent from 0 to A. 0 A B N [WW|WWWWWWWWWW] [SS|DDDDDDDDZZ] Fix this by pass EXT4_EXT_DATA_PARTIAL_VALID1 to ext4_split_extent_at() when splitting at B, don't convert the entire extent to written and left it as unwritten after zeroing out B to N. The remaining work is just like the standard two-part split. ext4_split_extent() will pass the EXT4_EXT_DATA_VALID2 flag when it calls ext4_split_extent_at() for the second time, allowing it to properly handle the split. If the split is
osv:CVE-2026-45858
Kernel
Fixed versions: 6.6.130, 6.12.75, 6.18.14, 6.19.4
Complete source record
{
"id": "086ba639cd3fbb1e069e3ea64ce092793b228abdc33e29596fa0aa9de631498c",
"url": "https://osv.dev/vulnerability/CVE-2026-45858",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "ext4: don't zero the entire extent if EXT4_EXT_DATA_PARTIAL_VALID1",
"summary": "In the Linux kernel, the following vulnerability has been resolved: ext4: don't zero the entire extent if EXT4_EXT_DATA_PARTIAL_VALID1 When allocating initialized blocks from a large unwritten extent, or when splitting an unwritten extent during end I/O and converting it to initialized, there is currently a potential issue of stale data if the extent needs to be split in the middle. 0 A B N [UUUUUUUUUUUU] U: unwritten extent [--DDDDDDDD--] D: valid data |<- ->| ----> this range needs to be initialized ext4_split_extent() first try to split this extent at B with EXT4_EXT_DATA_ENTIRE_VALID1 and EXT4_EXT_MAY_ZEROOUT flag set, but ext4_split_extent_at() failed to split this extent due to temporary lack of space. It zeroout B to N and mark the entire extent from 0 to N as written. 0 A B N [WWWWWWWWWWWW] W: written extent [SSDDDDDDDDZZ] Z: zeroed, S: stale data ext4_split_extent() then try to split this extent at A with EXT4_EXT_DATA_VALID2 flag set. This time, it split successfully and left a stale written extent from 0 to A. 0 A B N [WW|WWWWWWWWWW] [SS|DDDDDDDDZZ] Fix this by pass EXT4_EXT_DATA_PARTIAL_VALID1 to ext4_split_extent_at() when splitting at B, don't convert the entire extent to written and left it as unwritten after zeroing out B to N. The remaining work is just like the standard two-part split. ext4_split_extent() will pass the EXT4_EXT_DATA_VALID2 flag when it calls ext4_split_extent_at() for the second time, allowing it to properly handle the split. If the split is",
"evidence": "osv:CVE-2026-45858",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "6.6.130",
"evidence": "/affected/1/ranges"
},
{
"value": "6.12.75",
"evidence": "/affected/1/ranges"
},
{
"value": "6.18.14",
"evidence": "/affected/1/ranges"
},
{
"value": "6.19.4",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "CVE-2026-45858",
"aliases": [
"CVE-2026-45858"
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "dee1f973ca341c266229faa5a1a5bb268bed3531"
},
{
"fixed": "58ddae5d77b1db3a27b891c75a8fa120239ac092"
},
{
"fixed": "d17857b4fb9ba5745b59be0ef38fd532991fccbf"
},
{
"fixed": "d67c8ecf3d8fda9b8ef80e6f665d84b6d6ac9d88"
},
{
"fixed": "7015fcf473796e1d2d876f241bd9e0c36f3d4eef"
},
{
"fixed": "1bf6974822d1dba86cf11b5f05498581cf3488a2"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "3.2.33"
},
{
"fixed": "3.3"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "3.4.16"
},
{
"fixed": "3.5"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "3.6.4"
},
{
"fixed": "3.7"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "814a7833df19e1de7447f870ae890adb12561627"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "4319fd00002630a761fa5559a086f11ed7623006"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "e28b27be06c5e6a5236c0c0b370ca0768ab086bb"
}
]
}
],
"versions": [
"v3.2.102",
"v3.2.101",
"v3.2.100",
"v3.2.99",
"v3.2.98",
"v3.2.97",
"v3.2.96",
"v3.2.95",
"v3.2.94",
"v3.2.93",
"v3.2.92",
"v3.2.91",
"v3.2.90",
"v3.2.89",
"v3.2.88",
"v3.2.87",
"v3.2.86",
"v3.2.85",
"v3.2.84",
"v3.2.83",
"v3.2.82",
"v3.2.81",
"v3.2.80",
"v3.2.79",
"v3.2.78",
"v3.2.77",
"v3.2.76",
"v3.2.75",
"v3.2.74",
"v3.2.73",
"v3.2.72",
"v3.2.71",
"v3.2.70",
"v3.2.69",
"v3.2.68",
"v3.2.67",
"v3.2.66",
"v3.2.65",
"v3.2.64",
"v3.2.63",
"v3.2.62",
"v3.2.61",
"v3.2.60",
"v3.2.59",
"v3.2.58",
"v3.2.57",
"v3.2.56",
"v3.2.55",
"v3.2.54",
"v3.2.53",
"v3.2.52",
"v3.2.51",
"v3.2.50",
"v3.2.49",
"v3.2.48",
"v3.2.47",
"v3.2.46",
"v3.2.45",
"v3.2.44",
"v3.2.43",
"v3.2.42",
"v3.2.41",
"v3.2.40",
"v3.2.39",
"v3.2.38",
"v3.2.37",
"v3.2.36",
"v3.2.35",
"v3.2.34",
"v3.2.33",
"v3.4.113",
"v3.4.112",
"v3.4.111",
"v3.4.110",
"v3.4.109",
"v3.4.108",
"v3.4.107",
"v3.4.106",
"v3.4.105",
"v3.4.104",
"v3.4.103",
"v3.4.102",
"v3.4.101",
"v3.4.100",
"v3.4.99",
"v3.4.98",
"v3.4.97",
"v3.4.96",
"v3.4.95",
"v3.4.94",
"v3.4.93",
"v3.4.92",
"v3.4.91",
"v3.4.90",
"v3.4.89",
"v3.4.88",
"v3.4.87",
"v3.4.86",
"v3.4.85",
"v3.4.84",
"v3.4.83",
"v3.4.82",
"v3.4.81",
"v3.4.80",
"v3.4.79",
"v3.4.78",
"v3.4.77",
"v3.4.76",
"v3.4.75",
"v3.4.74",
"v3.4.73",
"v3.4.72",
"v3.4.71",
"v3.4.70",
"v3.4.69",
"v3.4.68",
"v3.4.67",
"v3.4.66",
"v3.4.65",
"v3.4.64",
"v3.4.63",
"v3.4.62",
"v3.4.61",
"v3.4.60",
"v3.4.59",
"v3.4.58",
"v3.4.57",
"v3.4.56",
"v3.4.55",
"v3.4.54",
"v3.4.53",
"v3.4.52",
"v3.4.51",
"v3.4.50",
"v3.4.49",
"v3.4.48",
"v3.4.47",
"v3.4.46",
"v3.4.45",
"v3.4.44",
"v3.4.43",
"v3.4.42",
"v3.4.41",
"v3.4.40",
"v3.4.39",
"v3.4.38",
"v3.4.37",
"v3.4.36",
"v3.4.35",
"v3.4.34",
"v3.4.33",
"v3.4.32",
"v3.4.31",
"v3.4.30",
"v3.4.29",
"v3.4.28",
"v3.4.27",
"v3.4.26",
"v3.4.25",
"v3.4.24",
"v3.4.23",
"v3.4.22",
"v3.4.21",
"v3.4.20",
"v3.4.19",
"v3.4.18",
"v3.4.17",
"v3.4.16",
"v3.6.11",
"v3.6.10",
"v3.6.9",
"v3.6.8",
"v3.6.7",
"v3.6.6",
"v3.6.5",
"v3.6.4"
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-45858.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "3.7.0"
},
{
"fixed": "6.6.130"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.7.0"
},
{
"fixed": "6.12.75"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.13.0"
},
{
"fixed": "6.18.14"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.19.0"
},
{
"fixed": "6.19.4"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-45858.json"
}
}
],
"modified": "2026-10-28T02:30:34.883359185Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/1bf6974822d1dba86cf11b5f05498581cf3488a2",
"https://git.kernel.org/stable/c/58ddae5d77b1db3a27b891c75a8fa120239ac092",
"https://git.kernel.org/stable/c/7015fcf473796e1d2d876f241bd9e0c36f3d4eef",
"https://git.kernel.org/stable/c/d17857b4fb9ba5745b59be0ef38fd532991fccbf",
"https://git.kernel.org/stable/c/d67c8ecf3d8fda9b8ef80e6f665d84b6d6ac9d88",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/45xxx/CVE-2026-45858.json",
"https://nvd.nist.gov/vuln/detail/CVE-2026-45858",
"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/45xxx/CVE-2026-45858.json"
}
},
"related_cves": [
{
"value": "CVE-2026-45858",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 502172,
"published_at": "2026-05-27T12:15:37.738+00:00"
}