GHSA-RH9V-MPGH-F53X
Vulnerability from github – Published: 2026-10-23 15:31 – Updated: 2026-10-23 15:31In the Linux kernel, the following vulnerability has been resolved:
sched_ext: Build the cid tables privately and publish them with RCU
The cid tables are visible to the cid kfuncs while being modified: the first enable publishes the global pointers before filling them, ops.init_cids() overrides rewrite them in place, and re-enables rebuild them in place. A racing TRACING or SYSCALL program can read unfilled entries, including uninitialized memory in the kmalloc'd tables, or torn topo updates.
Tie the tables' lifetimes to the root sched instead: each root enable builds a fresh set privately and publishes the per-table __rcu globals once the layout is final, and root disable unpublishes and RCU-frees the set. A non-NULL global is now always a fully built table which stays valid for the reader's RCU read section, and lookups stay two loads. Kfuncs treat NULL as no-mapping, also after the scheduler exits instead of reporting the stale last mapping.
The cid kfuncs are available whether the root scheduler is cid-form or cpu-form, the latter to allow gradual migration to cids. Every root therefore builds and publishes a default mapping.
Every reader must either be gated on scheduler liveness or NULL-check inside an RCU read section. Fix the two kfuncs that were neither: scx_bpf_this_cid() read the table with no RCU or preemption protection and scx_bpf_task_cid() relied on KF_RCU, which doesn't put a sleepable program in an RCU read section. The hotplug callbacks are instead serialized by retiring the tables inside the cpus_read_lock() section that clears scx_root.
v2: Document why every root builds the tables (desc + cid.c comment).
{
"affected": [],
"aliases": [
"CVE-2026-98942"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-23T13:17:15Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsched_ext: Build the cid tables privately and publish them with RCU\n\nThe cid tables are visible to the cid kfuncs while being modified: the\nfirst enable publishes the global pointers before filling them,\nops.init_cids() overrides rewrite them in place, and re-enables rebuild\nthem in place. A racing TRACING or SYSCALL program can read unfilled\nentries, including uninitialized memory in the kmalloc\u0027d tables, or torn\ntopo updates.\n\nTie the tables\u0027 lifetimes to the root sched instead: each root enable\nbuilds a fresh set privately and publishes the per-table __rcu globals once\nthe layout is final, and root disable unpublishes and RCU-frees the set. A\nnon-NULL global is now always a fully built table which stays valid for the\nreader\u0027s RCU read section, and lookups stay two loads. Kfuncs treat NULL as\nno-mapping, also after the scheduler exits instead of reporting the stale\nlast mapping.\n\nThe cid kfuncs are available whether the root scheduler is cid-form or\ncpu-form, the latter to allow gradual migration to cids. Every root\ntherefore builds and publishes a default mapping.\n\nEvery reader must either be gated on scheduler liveness or NULL-check\ninside an RCU read section. Fix the two kfuncs that were neither:\nscx_bpf_this_cid() read the table with no RCU or preemption protection and\nscx_bpf_task_cid() relied on KF_RCU, which doesn\u0027t put a sleepable program\nin an RCU read section. The hotplug callbacks are instead serialized by\nretiring the tables inside the cpus_read_lock() section that clears\nscx_root.\n\nv2: Document why every root builds the tables (desc + cid.c comment).",
"id": "GHSA-rh9v-mpgh-f53x",
"modified": "2026-10-23T15:31:32Z",
"published": "2026-10-23T15:31:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98942"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0e1a74369bdbc357d3d9713734418d914a981553"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3a773220d39ba993dfe5d135f8b610be10794d5d"
}
],
"schema_version": "1.4.0",
"severity": []
}
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.
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…
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.