CVE-2026-80876

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.