PT-2026-85795 · Linux · Linux
CVE-2026-80876
·
Published
2026-09-04
·
Updated
2026-09-04
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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 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 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.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux