fkie_cve-2025-38691
Vulnerability from fkie_nvd
Published
2025-09-04 16:15
Modified
2025-09-05 17:47
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved:
pNFS: Fix uninited ptr deref in block/scsi layout
The error occurs on the third attempt to encode extents. When function
ext_tree_prepare_commit() reallocates a larger buffer to retry encoding
extents, the "layoutupdate_pages" page array is initialized only after the
retry loop. But ext_tree_free_commitdata() is called on every iteration
and tries to put pages in the array, thus dereferencing uninitialized
pointers.
An additional problem is that there is no limit on the maximum possible
buffer_size. When there are too many extents, the client may create a
layoutcommit that is larger than the maximum possible RPC size accepted
by the server.
During testing, we observed two typical scenarios. First, one memory page
for extents is enough when we work with small files, append data to the
end of the file, or preallocate extents before writing. But when we fill
a new large file without preallocating, the number of extents can be huge,
and counting the number of written extents in ext_tree_encode_commit()
does not help much. Since this number increases even more between
unlocking and locking of ext_tree, the reallocated buffer may not be
large enough again and again.
References
Impacted products
| Vendor | Product | Version |
|---|
{
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\npNFS: Fix uninited ptr deref in block/scsi layout\n\nThe error occurs on the third attempt to encode extents. When function\next_tree_prepare_commit() reallocates a larger buffer to retry encoding\nextents, the \"layoutupdate_pages\" page array is initialized only after the\nretry loop. But ext_tree_free_commitdata() is called on every iteration\nand tries to put pages in the array, thus dereferencing uninitialized\npointers.\n\nAn additional problem is that there is no limit on the maximum possible\nbuffer_size. When there are too many extents, the client may create a\nlayoutcommit that is larger than the maximum possible RPC size accepted\nby the server.\n\nDuring testing, we observed two typical scenarios. First, one memory page\nfor extents is enough when we work with small files, append data to the\nend of the file, or preallocate extents before writing. But when we fill\na new large file without preallocating, the number of extents can be huge,\nand counting the number of written extents in ext_tree_encode_commit()\ndoes not help much. Since this number increases even more between\nunlocking and locking of ext_tree, the reallocated buffer may not be\nlarge enough again and again."
}
],
"id": "CVE-2025-38691",
"lastModified": "2025-09-05T17:47:24.833",
"metrics": {},
"published": "2025-09-04T16:15:37.297",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/24334f3cf8a294f253071b5bf22d754dbb6d0f2d"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/2896f101110076ac6bf99d7aaf463d61e26f89dd"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/37c3443a2685528f972d910a6fb87716b96fef46"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/4f783333cbfa2ee7d4aa8e47f6bd1b3f77534fcf"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/579b85f893d9885162e1cabf99a4a088916e143e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/94ec6d939031a616474376dadbf4a8d0ef8b0bcc"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/9768797c219326699778fba9cd3b607b2f1e7950"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/9be5c04beca3202d0a5f09fb4b2ecb644caa0bc5"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/f0b2eee3fbba9b7e3746ef698424ef5e4a197776"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Awaiting Analysis"
}
Loading…
Loading…
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.
- 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.
Loading…