GHSA-F6HV-XHX3-9X64
Vulnerability from github – Published: 2026-09-04 18:31 – Updated: 2026-09-04 18:31In the Linux kernel, the following vulnerability has been resolved:
ring-buffer: Fix event length with forced 8-byte alignment
When RB_FORCE_8BYTE_ALIGNMENT is true, rb_calculate_event_length() reserves the space of event->array[0] for placing the data length and rb_update_event() stores the data length in event->array[0] accordingly. As a result the whole event length will add extra 4 bytes for sizeof(event.array[0]) unconditionally.
But ring_buffer_event_length() only subtracts the sizeof(event->array[0]) for events larger than RB_MAX_SMALL_DATA + sizeof(event->array[0]). As a result, small events on architectures with RB_FORCE_8BYTE_ALIGNMENT=true report a data length that is 4 bytes larger than expected.
To fix it, add the RB_FORCE_8BYTE_ALIGNMENT as a condition to subtract the size of that length field whenever RB_FORCE_8BYTE_ALIGNMENT is true.
This issue is observed in a riscv64 kernel with CONFIG_HAVE_64BIT_ALIGNED_ACCESS set to y, when we run ftrace selftest trace_marker_raw.tc, we get the weird log: for cases where the id is 1..100, the number of data field is 8N, but once id exceeds 100, the number of data field becomes 8N+4: # 1 buf: 58 00 00 00 80 5e d1 63 (number of data field is 81) ... # a buf: 58 ... (number of data field is 82) ... # 64 buf: 58 ... (number of data field is 813) # 65 buf: 58 ... (number of data field is 813+4)
After applying this change, the number of data field keeps being 8*N+4 consistently.
{
"affected": [],
"aliases": [
"CVE-2026-80876"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-04T17:16:59Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nring-buffer: Fix event length with forced 8-byte alignment\n\nWhen RB_FORCE_8BYTE_ALIGNMENT is true, rb_calculate_event_length()\nreserves the space of event-\u003earray[0] for placing the data length and\nrb_update_event() stores the data length in event-\u003earray[0]\naccordingly. As a result the whole event length will add extra 4 bytes\nfor sizeof(event.array[0]) unconditionally.\n\nBut ring_buffer_event_length() only subtracts the\nsizeof(event-\u003earray[0]) for events larger than RB_MAX_SMALL_DATA +\nsizeof(event-\u003earray[0]). As a result, small events on architectures\nwith RB_FORCE_8BYTE_ALIGNMENT=true report a data length that is 4\nbytes larger than expected.\n\nTo fix it, add the RB_FORCE_8BYTE_ALIGNMENT as a condition to subtract\nthe size of that length field whenever RB_FORCE_8BYTE_ALIGNMENT is\ntrue.\n\nThis issue is observed in a riscv64 kernel with\nCONFIG_HAVE_64BIT_ALIGNED_ACCESS set to y, when we run ftrace selftest\ntrace_marker_raw.tc, we get the weird log: for cases where the id is\n1..100, the number of data field is 8*N, but once id exceeds 100, the\nnumber of data field becomes 8*N+4:\n # 1 buf: 58 00 00 00 80 5e d1 63 (number of data field is 8*1)\n ...\n # a buf: 58 ... (number of data field is 8*2)\n ...\n # 64 buf: 58 ... (number of data field is 8*13)\n # 65 buf: 58 ... (number of data field is 8*13+4)\n\nAfter applying this change, the number of data field keeps being 8*N+4\nconsistently.",
"id": "GHSA-f6hv-xhx3-9x64",
"modified": "2026-09-04T18:31:32Z",
"published": "2026-09-04T18:31:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80876"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/14057268e79654c3e8ea2c9b5204cb9644b2964d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/24c3fa71f9947b0e1f3b954db1b769b44140192e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3a63a11897c7ba32d1be7a3fdbc48a8b01cf4992"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7c9f0ccf9f04142458d2ac3d39414f4acae242f0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c37e0a4b79a6bbb96ce5ffe279d7c001e20529e0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cfada73fabe2ccc06ec77fe2ceaa088689213326"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dbcb8635b1eb7603818591cf745c7b1d714f7ac6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ec5e96aee75d27779b9a860307679f13f33adb0c"
}
],
"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.