CVE-2026-80876

In the Linux kernel, the following vulnerability has been resolved:

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

When RBFORCE8BYTEALIGNMENT is true, rbcalculateeventlength() reserves the space of event->array[0] for placing the data length and rbupdateevent() 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 ringbuffereventlength() only subtracts the sizeof(event->array[0]) for events larger than RBMAXSMALLDATA + sizeof(event->array[0]). As a result, small events on architectures with RBFORCE8BYTE_ALIGNMENT=true report a data length that is 4 bytes larger than expected.

To fix it, add the RBFORCE8BYTEALIGNMENT as a condition to subtract the size of that length field whenever RBFORCE8BYTEALIGNMENT is true.

This issue is observed in a riscv64 kernel with CONFIGHAVE64BITALIGNEDACCESS set to y, when we run ftrace selftest tracemarkerraw.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.