Skip to content
CVE Ledger
  • Newest CVEsPage
  • Recently added to KEVPage
  • Rising exploitation (EPSS)Page
  • Weekly digestPage
  • StatisticsPage
  • WatchlistPage
  • API docsPage
  • MCP serverPage
  • AboutPage
  • Data sourcesPage
  • Data statusPage
  • ChangelogPage
  • How it's builtPage
  • Support the projectPage

14 results

Back

CVE-2026-80876ring-buffer: Fix event length with forced 8-byte alignment

Description

In 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 8*N, but once id exceeds 100, the number of data field becomes 8*N+4: # 1 buf: 58 00 00 00 80 5e d1 63 (number of data field is 8*1) ... # a buf: 58 ... (number of data field is 8*2) ... # 64 buf: 58 ... (number of data field is 8*13) # 65 buf: 58 ... (number of data field is 8*13+4) After applying this change, the number of data field keeps being 8*N+4 consistently.

Timeline

  1. ID reserved

    By Linux

  2. · 9 days later

    Published

  3. · 2 months later

    Record updated

Changes after publication (a new score, a public exploit, EPSS crossing 1, 10 or 50 %, leaving KEV) are kept since November 2026; earlier ones are not known.

Scores

No CVSS score yet: neither the CNA, CISA nor NVD has scored this CVE. NVD status: Received.

EPSS (exploitation in 30 days)
0.22% · top 87% of all CVEs (14 Nov 2026)
CISA SSVC
Exploitation: none · Automatable: no · Technical impact: partial
Loading the EPSS history…

The list uses the assigner's score when there is one, then CISA's, then NVD's: Not scored.

Affected products

  • Linux · Linux

    • affected 2271048d1b3b0aabf83d25b29c20646dcabedc05 – < 7c9f0ccf9f04142458d2ac3d39414f4acae242f0
    • affected 2271048d1b3b0aabf83d25b29c20646dcabedc05 – < 24c3fa71f9947b0e1f3b954db1b769b44140192e
    • affected 2271048d1b3b0aabf83d25b29c20646dcabedc05 – < 14057268e79654c3e8ea2c9b5204cb9644b2964d
    • affected 2271048d1b3b0aabf83d25b29c20646dcabedc05 – < dbcb8635b1eb7603818591cf745c7b1d714f7ac6
    • affected 2271048d1b3b0aabf83d25b29c20646dcabedc05 – < cfada73fabe2ccc06ec77fe2ceaa088689213326
    • affected 2271048d1b3b0aabf83d25b29c20646dcabedc05 – < ec5e96aee75d27779b9a860307679f13f33adb0c
    • affected 2271048d1b3b0aabf83d25b29c20646dcabedc05 – < 3a63a11897c7ba32d1be7a3fdbc48a8b01cf4992
    • affected 2271048d1b3b0aabf83d25b29c20646dcabedc05 – < c37e0a4b79a6bbb96ce5ffe279d7c001e20529e0
  • Linux · Linux

    • affected 2.6.34
    • unaffected < 2.6.34
    • unaffected 5.10.261 – ≤ 5.10.*
    • unaffected 5.15.212 – ≤ 5.15.*
    • unaffected 6.1.178 – ≤ 6.1.*
    • unaffected 6.6.145 – ≤ 6.6.*
    • unaffected 6.12.97 – ≤ 6.12.*
    • unaffected 6.18.40 – ≤ 6.18.*
    • unaffected 7.1.5 – ≤ 7.1.*
    • unaffected 7.2 – ≤ *

References

References8

Sources

The same CVE in the primary databases and aggregators, to check against.

Badge for a README or a ticket

CVE-2026-80876 badge
[![CVE-2026-80876](https://cveledger.app/badge/CVE-2026-80876.svg)](https://cveledger.app/cve/CVE-2026-80876)

Record last updated .