GHSA-47XM-6CXX-CM4J
Vulnerability from github – Published: 2026-09-25 12:31 – Updated: 2026-09-25 12:31In the Linux kernel, the following vulnerability has been resolved:
tracing: Take trace_array reference when opening a tracer options file
When a tracer option file is opened, it is passed a descriptor that points to an element on the trace_array's topts array. This element has information to find the trace array and other information. It uses this element to take a reference of the trace_array so that the trace_array does not get removed while this file is opened.
Unfortunately, there's a race condition where the element itself could be freed by the removal of the instance the trace_array represents causing a use-after-free as this element that is used to find the trace_array to increment its reference counter is also freed when the instance is removed.
To solve this, add a trace_array_tracer_options_get() helper function that will take the address of the element that is passed to the open function by the inode->i_private pointer and search all the trace_arrays under a lock to find the one that the element's address is in the range of the trace_arrays topts array elements. When a match happens, that trace_array's reference would be increased.
Note, there's a race where if an admin was deleting and creating trace instances at the same time and the memory of the old trace_array's array matched the memory of the new trace_array that it could in theory open the option from the wrong trace array. But we do not care because it would be stupid to perform that kind of action. As long as the only thing that can happen is that the option from the wrong trace array is used and doesn't crash the kernel it will only make the user confused. But if they are doing something stupid like this, they are already confused, so no harm done.
{
"affected": [],
"aliases": [
"CVE-2026-97933"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-25T11:17:20Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Take trace_array reference when opening a tracer options file\n\nWhen a tracer option file is opened, it is passed a descriptor that points\nto an element on the trace_array\u0027s topts array. This element has\ninformation to find the trace array and other information. It uses this\nelement to take a reference of the trace_array so that the trace_array\ndoes not get removed while this file is opened.\n\nUnfortunately, there\u0027s a race condition where the element itself could be\nfreed by the removal of the instance the trace_array represents causing a\nuse-after-free as this element that is used to find the trace_array to\nincrement its reference counter is also freed when the instance is\nremoved.\n\nTo solve this, add a trace_array_tracer_options_get() helper function that\nwill take the address of the element that is passed to the open function\nby the inode-\u003ei_private pointer and search all the trace_arrays under a\nlock to find the one that the element\u0027s address is in the range of the\ntrace_arrays topts array elements. When a match happens, that trace_array\u0027s\nreference would be increased.\n\nNote, there\u0027s a race where if an admin was deleting and creating trace\ninstances at the same time and the memory of the old trace_array\u0027s array\nmatched the memory of the new trace_array that it could in theory open the\noption from the wrong trace array. But we do not care because it would be\nstupid to perform that kind of action. As long as the only thing that can\nhappen is that the option from the wrong trace array is used and doesn\u0027t\ncrash the kernel it will only make the user confused. But if they are\ndoing something stupid like this, they are already confused, so no harm\ndone.",
"id": "GHSA-47xm-6cxx-cm4j",
"modified": "2026-09-25T12:31:29Z",
"published": "2026-09-25T12:31:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97933"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b2fb87d29ffb3a7a9ccc5acf12898ecb80587427"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ed0aff60f83a9bdc2f6556376ac79c96b3ce7e80"
}
],
"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.