CVE-2026-23147 (GCVE-0-2026-23147)
Vulnerability from cvelistv5 – Published: 2026-02-14 16:01 – Updated: 2026-02-14 16:01
VLAI?
Title
btrfs: zlib: fix the folio leak on S390 hardware acceleration
Summary
In the Linux kernel, the following vulnerability has been resolved:
btrfs: zlib: fix the folio leak on S390 hardware acceleration
[BUG]
After commit aa60fe12b4f4 ("btrfs: zlib: refactor S390x HW acceleration
buffer preparation"), we no longer release the folio of the page cache
of folio returned by btrfs_compress_filemap_get_folio() for S390
hardware acceleration path.
[CAUSE]
Before that commit, we call kumap_local() and folio_put() after handling
each folio.
Although the timing is not ideal (it release previous folio at the
beginning of the loop, and rely on some extra cleanup out of the loop),
it at least handles the folio release correctly.
Meanwhile the refactored code is easier to read, it lacks the call to
release the filemap folio.
[FIX]
Add the missing folio_put() for copy_data_into_buffer().
Severity ?
No CVSS data available.
Assigner
References
Impacted products
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/btrfs/zlib.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "e80617a5e1c246da2f112a1a072cdd535046adfe",
"status": "affected",
"version": "aa60fe12b4f49f49fc73e5023f8675e2df1f7805",
"versionType": "git"
},
{
"lessThan": "0d0f1314e8f86f5205f71f9e31e272a1d008e40b",
"status": "affected",
"version": "aa60fe12b4f49f49fc73e5023f8675e2df1f7805",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/btrfs/zlib.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.15"
},
{
"lessThan": "6.15",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.9",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.19",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.18.9",
"versionStartIncluding": "6.15",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.19",
"versionStartIncluding": "6.15",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: zlib: fix the folio leak on S390 hardware acceleration\n\n[BUG]\nAfter commit aa60fe12b4f4 (\"btrfs: zlib: refactor S390x HW acceleration\nbuffer preparation\"), we no longer release the folio of the page cache\nof folio returned by btrfs_compress_filemap_get_folio() for S390\nhardware acceleration path.\n\n[CAUSE]\nBefore that commit, we call kumap_local() and folio_put() after handling\neach folio.\n\nAlthough the timing is not ideal (it release previous folio at the\nbeginning of the loop, and rely on some extra cleanup out of the loop),\nit at least handles the folio release correctly.\n\nMeanwhile the refactored code is easier to read, it lacks the call to\nrelease the filemap folio.\n\n[FIX]\nAdd the missing folio_put() for copy_data_into_buffer()."
}
],
"providerMetadata": {
"dateUpdated": "2026-02-14T16:01:16.917Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/e80617a5e1c246da2f112a1a072cdd535046adfe"
},
{
"url": "https://git.kernel.org/stable/c/0d0f1314e8f86f5205f71f9e31e272a1d008e40b"
}
],
"title": "btrfs: zlib: fix the folio leak on S390 hardware acceleration",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2026-23147",
"datePublished": "2026-02-14T16:01:16.917Z",
"dateReserved": "2026-01-13T15:37:45.975Z",
"dateUpdated": "2026-02-14T16:01:16.917Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"nvd": "{\"cve\":{\"id\":\"CVE-2026-23147\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2026-02-14T16:15:54.813\",\"lastModified\":\"2026-02-14T16:15:54.813\",\"vulnStatus\":\"Received\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nbtrfs: zlib: fix the folio leak on S390 hardware acceleration\\n\\n[BUG]\\nAfter commit aa60fe12b4f4 (\\\"btrfs: zlib: refactor S390x HW acceleration\\nbuffer preparation\\\"), we no longer release the folio of the page cache\\nof folio returned by btrfs_compress_filemap_get_folio() for S390\\nhardware acceleration path.\\n\\n[CAUSE]\\nBefore that commit, we call kumap_local() and folio_put() after handling\\neach folio.\\n\\nAlthough the timing is not ideal (it release previous folio at the\\nbeginning of the loop, and rely on some extra cleanup out of the loop),\\nit at least handles the folio release correctly.\\n\\nMeanwhile the refactored code is easier to read, it lacks the call to\\nrelease the filemap folio.\\n\\n[FIX]\\nAdd the missing folio_put() for copy_data_into_buffer().\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/0d0f1314e8f86f5205f71f9e31e272a1d008e40b\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/e80617a5e1c246da2f112a1a072cdd535046adfe\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}"
}
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
Loading…