GHSA-W946-9G6F-2799
Vulnerability from github – Published: 2026-09-24 18:31 – Updated: 2026-09-24 18:31In the Linux kernel, the following vulnerability has been resolved:
sched/isolation: Defer freeing of cpumask memblock memory to initcall
When testing a linux-next kernel with commit 59bd1d914bb5 ("memblock: warn when freeing reserved memory before memory map is initialized"), the following warning was hit when there was a "nohz_full" kernel boot parameter.
Cannot free reserved memory because of deferred initialization of the memory map WARNING: mm/memblock.c:904 at __free_reserved_area+0xde/0xf0, CPU#0: swapper/0/0 : Call Trace: memblock_phys_free+0xcb/0x100 housekeeping_init+0x14c/0x170 start_kernel+0x207/0x450 x86_64_start_reservations+0x24/0x30 x86_64_start_kernel+0xda/0xe0 common_startup_64+0x13e/0x141
IOW, we shouldn't free memblock allocated memory so early in the boot process when memory map isn't fully initialized in deferred_init_memmap().
Fix it by saving the housekeeping cpumask memblock memory to be freed into a llist free list in housekeeping_init() and add a new housekeeping_late_init() helper to defer the actual freeing of memblock memory to when initcall's are being processed. The cpumask memblock memory is treated as a llist_node with the size of a "long" type which is also smallest cpumask size that can be allocated.
The non-atomic version of the llist APIs are used as there is no contention.
This commit depends on the presence of commit 7c2eee9c1367 ("memblock: don't touch memblock arrays when memblock_free() is called late") to prevent a KASAN UAF bug report [1].
[1] https://lore.kernel.org/lkml/20260505051821.1107133-1-longman@redhat.com/
{
"affected": [],
"aliases": [
"CVE-2026-93253"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-24T16:17:21Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsched/isolation: Defer freeing of cpumask memblock memory to initcall\n\nWhen testing a linux-next kernel with commit 59bd1d914bb5 (\"memblock:\nwarn when freeing reserved memory before memory map is initialized\"),\nthe following warning was hit when there was a \"nohz_full\" kernel boot\nparameter.\n\n Cannot free reserved memory because of deferred initialization of the memory map\n WARNING: mm/memblock.c:904 at __free_reserved_area+0xde/0xf0, CPU#0: swapper/0/0\n :\n Call Trace:\n \u003cTASK\u003e\n memblock_phys_free+0xcb/0x100\n housekeeping_init+0x14c/0x170\n start_kernel+0x207/0x450\n x86_64_start_reservations+0x24/0x30\n x86_64_start_kernel+0xda/0xe0\n common_startup_64+0x13e/0x141\n \u003c/TASK\u003e\n\nIOW, we shouldn\u0027t free memblock allocated memory so early\nin the boot process when memory map isn\u0027t fully initialized in\ndeferred_init_memmap().\n\nFix it by saving the housekeeping cpumask memblock memory to be\nfreed into a llist free list in housekeeping_init() and add a new\nhousekeeping_late_init() helper to defer the actual freeing of memblock\nmemory to when initcall\u0027s are being processed. The cpumask memblock\nmemory is treated as a llist_node with the size of a \"long\" type which\nis also smallest cpumask size that can be allocated.\n\nThe non-atomic version of the llist APIs are used as there is no\ncontention.\n\nThis commit depends on the presence of commit 7c2eee9c1367 (\"memblock:\ndon\u0027t touch memblock arrays when memblock_free() is called late\")\nto prevent a KASAN UAF bug report [1].\n\n [1] https://lore.kernel.org/lkml/20260505051821.1107133-1-longman@redhat.com/",
"id": "GHSA-w946-9g6f-2799",
"modified": "2026-09-24T18:31:24Z",
"published": "2026-09-24T18:31:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-93253"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2b58c749b8c5244e259a0230bc57b10b010dc545"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/811fdac2d1bdf0b0d3fda262aac288ddd13a1422"
}
],
"schema_version": "1.4.0",
"severity": []
}
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.
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.
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.