CVE-2026-98920 (GCVE-0-2026-98920)
Vulnerability from cvelistv5 – Published: 2026-10-23 12:02 – Updated: 2026-10-23 12:05
VLAI
EPSS
VEX
Title
netfs: Fix missing alloc tagging of direct mempool allocations
Summary
In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix missing alloc tagging of direct mempool allocations
Commit 1d78d56c43ef ("netfs: Fix folio_queue ENOMEM in writeback by
adding a mempool") added a mempool for the folio_queues and made the
request, subrequest and folio_queue allocations distinguish between
writeback and everything else. Writeback is part of memory reclaim
and must not fail due to ENOMEM, so it allocates under GFP_NOFS
through mempool_alloc(), which may dip into the pool's reserve and,
if that runs empty, wait for elements to be returned. The
GFP_KERNEL paths, which can return -ENOMEM to their callers, invoke
the pool's ->alloc() callback directly instead.
The direct call, however, skips the alloc_hooks() wrapper that the
mempool_alloc() macro provides. The pool callbacks, mempool_alloc_slab()
and mempool_kmalloc(), call kmem_cache_alloc_noprof() and kmalloc_noprof()
and rely on current->alloc_tag having been set by the caller. With
CONFIG_MEM_ALLOC_PROFILING_DEBUG=y this leads to
current->alloc_tag not set
WARNING: ./include/linux/alloc_tag.h:161 at __alloc_tagging_slab_alloc_hook
alloc_tag was not set
WARNING: ./include/linux/alloc_tag.h:166 at __alloc_tagging_slab_free_hook
at allocation and free time respectively, as reported when reading
files on a CIFS mount. The allocations are also missing from
/proc/allocinfo.
Wrap the direct ->alloc() invocations in alloc_hooks() with a new
mempool_alloc_noreserve() helper in include/linux/mempool.h, next to
the other alloc_hooks()-wrapped macros such as mempool_alloc(). The
GFP_KERNEL paths keep their failable allocation semantics, they just
get tagged now.
Severity
No CVSS data available.
Assigner
References
Impacted products
2 products
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
15ed8a9b7c63e9171f5139a6aaa1ffb61809861f , < 5c03da745171485fd181f17b69213464f6d05f3d
(git)
Affected: 1d78d56c43ef3768183e8370e7367b162700e049 , < 37a2042748bc880df03ff8315db86ed82991fbb8 (git) Affected: 1d78d56c43ef3768183e8370e7367b162700e049 , < b78b728e21c32ec4c330b299f657fb1eb02dffc2 (git) Affected: b343252d6f536203dd0660f676190dcbf6d2ecdc (git) Affected: 3f6d7f8a5416d852648d15a05e895f1195ee8a85 (git) Affected: 6.12.114 , < 6.13 (semver) Affected: 7.1.8 , < 7.2 (semver) |
guessed | |
| Linux | Linux |
Affected:
7.2
Unaffected: 0 , < 7.2 (semver) Unaffected: 7.2.9 , ≤ 7.2.* (semver) Unaffected: 7.3 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/netfs/objects.c",
"fs/netfs/rolling_buffer.c",
"include/linux/mempool.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "5c03da745171485fd181f17b69213464f6d05f3d",
"status": "affected",
"version": "15ed8a9b7c63e9171f5139a6aaa1ffb61809861f",
"versionType": "git"
},
{
"lessThan": "37a2042748bc880df03ff8315db86ed82991fbb8",
"status": "affected",
"version": "1d78d56c43ef3768183e8370e7367b162700e049",
"versionType": "git"
},
{
"lessThan": "b78b728e21c32ec4c330b299f657fb1eb02dffc2",
"status": "affected",
"version": "1d78d56c43ef3768183e8370e7367b162700e049",
"versionType": "git"
},
{
"status": "affected",
"version": "b343252d6f536203dd0660f676190dcbf6d2ecdc",
"versionType": "git"
},
{
"status": "affected",
"version": "3f6d7f8a5416d852648d15a05e895f1195ee8a85",
"versionType": "git"
},
{
"lessThan": "6.13",
"status": "affected",
"version": "6.12.114",
"versionType": "semver"
},
{
"lessThan": "7.2",
"status": "affected",
"version": "7.1.8",
"versionType": "semver"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/netfs/objects.c",
"fs/netfs/rolling_buffer.c",
"include/linux/mempool.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "7.2"
},
{
"lessThan": "7.2",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "7.2.*",
"status": "unaffected",
"version": "7.2.9",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.3",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "7.2.9",
"versionStartIncluding": "7.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "7.3",
"versionStartIncluding": "7.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "6.12.114",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "7.1.8",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfs: Fix missing alloc tagging of direct mempool allocations\n\nCommit 1d78d56c43ef (\"netfs: Fix folio_queue ENOMEM in writeback by\nadding a mempool\") added a mempool for the folio_queues and made the\nrequest, subrequest and folio_queue allocations distinguish between\nwriteback and everything else. Writeback is part of memory reclaim\nand must not fail due to ENOMEM, so it allocates under GFP_NOFS\nthrough mempool_alloc(), which may dip into the pool\u0027s reserve and,\nif that runs empty, wait for elements to be returned. The\nGFP_KERNEL paths, which can return -ENOMEM to their callers, invoke\nthe pool\u0027s -\u003ealloc() callback directly instead.\n\nThe direct call, however, skips the alloc_hooks() wrapper that the\nmempool_alloc() macro provides. The pool callbacks, mempool_alloc_slab()\nand mempool_kmalloc(), call kmem_cache_alloc_noprof() and kmalloc_noprof()\nand rely on current-\u003ealloc_tag having been set by the caller. With\nCONFIG_MEM_ALLOC_PROFILING_DEBUG=y this leads to\n\n current-\u003ealloc_tag not set\n WARNING: ./include/linux/alloc_tag.h:161 at __alloc_tagging_slab_alloc_hook\n alloc_tag was not set\n WARNING: ./include/linux/alloc_tag.h:166 at __alloc_tagging_slab_free_hook\n\nat allocation and free time respectively, as reported when reading\nfiles on a CIFS mount. The allocations are also missing from\n/proc/allocinfo.\n\nWrap the direct -\u003ealloc() invocations in alloc_hooks() with a new\nmempool_alloc_noreserve() helper in include/linux/mempool.h, next to\nthe other alloc_hooks()-wrapped macros such as mempool_alloc(). The\nGFP_KERNEL paths keep their failable allocation semantics, they just\nget tagged now."
}
],
"providerMetadata": {
"dateUpdated": "2026-10-23T12:05:25.919Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/5c03da745171485fd181f17b69213464f6d05f3d"
},
{
"url": "https://git.kernel.org/stable/c/37a2042748bc880df03ff8315db86ed82991fbb8"
},
{
"url": "https://git.kernel.org/stable/c/b78b728e21c32ec4c330b299f657fb1eb02dffc2"
}
],
"title": "netfs: Fix missing alloc tagging of direct mempool allocations",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2026-98920",
"datePublished": "2026-10-23T12:02:06.560Z",
"dateReserved": "2026-09-25T10:25:14.380Z",
"dateUpdated": "2026-10-23T12:05:25.919Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/netfs/objects.c",
"fs/netfs/rolling_buffer.c",
"include/linux/mempool.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "5c03da745171485fd181f17b69213464f6d05f3d",
"status": "affected",
"version": "15ed8a9b7c63e9171f5139a6aaa1ffb61809861f",
"versionType": "git"
},
{
"lessThan": "37a2042748bc880df03ff8315db86ed82991fbb8",
"status": "affected",
"version": "1d78d56c43ef3768183e8370e7367b162700e049",
"versionType": "git"
},
{
"lessThan": "b78b728e21c32ec4c330b299f657fb1eb02dffc2",
"status": "affected",
"version": "1d78d56c43ef3768183e8370e7367b162700e049",
"versionType": "git"
},
{
"status": "affected",
"version": "b343252d6f536203dd0660f676190dcbf6d2ecdc",
"versionType": "git"
},
{
"status": "affected",
"version": "3f6d7f8a5416d852648d15a05e895f1195ee8a85",
"versionType": "git"
},
{
"lessThan": "6.13",
"status": "affected",
"version": "6.12.114",
"versionType": "semver"
},
{
"lessThan": "7.2",
"status": "affected",
"version": "7.1.8",
"versionType": "semver"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/netfs/objects.c",
"fs/netfs/rolling_buffer.c",
"include/linux/mempool.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "7.2"
},
{
"lessThan": "7.2",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "7.2.*",
"status": "unaffected",
"version": "7.2.9",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.3",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfs: Fix missing alloc tagging of direct mempool allocations\n\nCommit 1d78d56c43ef (\"netfs: Fix folio_queue ENOMEM in writeback by\nadding a mempool\") added a mempool for the folio_queues and made the\nrequest, subrequest and folio_queue allocations distinguish between\nwriteback and everything else. Writeback is part of memory reclaim\nand must not fail due to ENOMEM, so it allocates under GFP_NOFS\nthrough mempool_alloc(), which may dip into the pool\u0027s reserve and,\nif that runs empty, wait for elements to be returned. The\nGFP_KERNEL paths, which can return -ENOMEM to their callers, invoke\nthe pool\u0027s -\u003ealloc() callback directly instead.\n\nThe direct call, however, skips the alloc_hooks() wrapper that the\nmempool_alloc() macro provides. The pool callbacks, mempool_alloc_slab()\nand mempool_kmalloc(), call kmem_cache_alloc_noprof() and kmalloc_noprof()\nand rely on current-\u003ealloc_tag having been set by the caller. With\nCONFIG_MEM_ALLOC_PROFILING_DEBUG=y this leads to\n\n current-\u003ealloc_tag not set\n WARNING: ./include/linux/alloc_tag.h:161 at __alloc_tagging_slab_alloc_hook\n alloc_tag was not set\n WARNING: ./include/linux/alloc_tag.h:166 at __alloc_tagging_slab_free_hook\n\nat allocation and free time respectively, as reported when reading\nfiles on a CIFS mount. The allocations are also missing from\n/proc/allocinfo.\n\nWrap the direct -\u003ealloc() invocations in alloc_hooks() with a new\nmempool_alloc_noreserve() helper in include/linux/mempool.h, next to\nthe other alloc_hooks()-wrapped macros such as mempool_alloc(). The\nGFP_KERNEL paths keep their failable allocation semantics, they just\nget tagged now."
}
],
"id": "CVE-2026-98920",
"lastModified": "2026-10-23T13:17:12.617",
"metrics": {},
"published": "2026-10-23T13:17:12.617",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/37a2042748bc880df03ff8315db86ed82991fbb8"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/5c03da745171485fd181f17b69213464f6d05f3d"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/b78b728e21c32ec4c330b299f657fb1eb02dffc2"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Received"
}
}
}
}
Loading…
Loading…
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
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.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
Loading…
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Loading…
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.