CVE-2026-80876

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

Published Sep 4, 2026 CVSS n/a EPSS < 1% KEV · Not listed

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.

Affected Products

Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).

Vendor Product Default status Versions

Linux

unaffected

Version	Status	Constraints
`2271048d1b3b0aabf83d25b29c20646dcabedc05`	affected	< 7c9f0ccf9f04142458d2ac3d39414f4acae242f0
`2271048d1b3b0aabf83d25b29c20646dcabedc05`	affected	< 24c3fa71f9947b0e1f3b954db1b769b44140192e
`2271048d1b3b0aabf83d25b29c20646dcabedc05`	affected	< 14057268e79654c3e8ea2c9b5204cb9644b2964d
`2271048d1b3b0aabf83d25b29c20646dcabedc05`	affected	< dbcb8635b1eb7603818591cf745c7b1d714f7ac6
`2271048d1b3b0aabf83d25b29c20646dcabedc05`	affected	< cfada73fabe2ccc06ec77fe2ceaa088689213326
`2271048d1b3b0aabf83d25b29c20646dcabedc05`	affected	< ec5e96aee75d27779b9a860307679f13f33adb0c
`2271048d1b3b0aabf83d25b29c20646dcabedc05`	affected	< 3a63a11897c7ba32d1be7a3fdbc48a8b01cf4992
`2271048d1b3b0aabf83d25b29c20646dcabedc05`	affected	< c37e0a4b79a6bbb96ce5ffe279d7c001e20529e0

Linux

affected

Version	Status	Constraints
`2.6.34`	affected	—
`0`	unaffected	< 2.6.34
`5.10.261`	unaffected	≤ 5.10.*
`5.15.212`	unaffected	≤ 5.15.*
`6.1.178`	unaffected	≤ 6.1.*
`6.6.145`	unaffected	≤ 6.6.*
`6.12.97`	unaffected	≤ 6.12.*
`6.18.40`	unaffected	≤ 6.18.*
`7.1.5`	unaffected	≤ 7.1.*
`7.2`	unaffected	≤ *

No data.

Vendor Product Versions

Linux

Linux Kernel

Version	Status	Scheme	Platform
`[2271048d1b3b0aabf83d25b29c20646dcabedc05,7c9f0ccf9f04142458d2ac3d39414f4acae242f0)`	affected	code_commit	—
`[2271048d1b3b0aabf83d25b29c20646dcabedc05,24c3fa71f9947b0e1f3b954db1b769b44140192e)`	affected	code_commit	—
`[2271048d1b3b0aabf83d25b29c20646dcabedc05,14057268e79654c3e8ea2c9b5204cb9644b2964d)`	affected	code_commit	—
`[2271048d1b3b0aabf83d25b29c20646dcabedc05,dbcb8635b1eb7603818591cf745c7b1d714f7ac6)`	affected	code_commit	—
`[2271048d1b3b0aabf83d25b29c20646dcabedc05,cfada73fabe2ccc06ec77fe2ceaa088689213326)`	affected	code_commit	—
`[2271048d1b3b0aabf83d25b29c20646dcabedc05,ec5e96aee75d27779b9a860307679f13f33adb0c)`	affected	code_commit	—
`[2271048d1b3b0aabf83d25b29c20646dcabedc05,3a63a11897c7ba32d1be7a3fdbc48a8b01cf4992)`	affected	code_commit	—
`[2271048d1b3b0aabf83d25b29c20646dcabedc05,c37e0a4b79a6bbb96ce5ffe279d7c001e20529e0)`	affected	code_commit	—

Linux

Linux Kernel

Version	Status	Scheme	Platform
`2.6.34`	affected	semver	—
`[0,2.6.34)`	unaffected	semver	—
`[5.10.261,5.11.0)`	unaffected	semver	—
`[5.15.212,5.16.0)`	unaffected	semver	—
`[6.1.178,6.2.0)`	unaffected	semver	—
`[6.6.145,6.7.0)`	unaffected	semver	—
`[6.12.97,6.13.0)`	unaffected	semver	—
`[6.18.40,6.19.0)`	unaffected	semver	—
`[7.1.5,7.2.0)`	unaffected	semver	—
`[7.2,*]`	unaffected	generic	—

Remediation

No solution or workaround provided in the CVE record

Tracking

Advisories

Source	ID	Title
Ubuntu USN	USN-8875-1	Linux kernel vulnerabilities
Ubuntu USN	USN-8877-1	Linux kernel (GCP) vulnerabilities
Ubuntu USN	USN-8878-1	Linux kernel (GCP) vulnerabilities
Ubuntu USN	USN-8879-1	Linux kernel (Oracle) vulnerabilities
Ubuntu USN	USN-8887-1	Linux kernel vulnerabilities
Ubuntu USN	USN-8888-1	Linux kernel (Azure) vulnerabilities
Ubuntu USN	USN-8889-1	Linux kernel (OEM) vulnerabilities
Ubuntu USN	USN-8887-2	Linux kernel (AWS) vulnerabilities
Ubuntu USN	USN-8888-2	Linux kernel (Azure) vulnerabilities
Ubuntu USN	USN-8875-2	Linux kernel (NVIDIA) vulnerabilities
Ubuntu USN	USN-8887-3	Linux kernel vulnerabilities
Ubuntu USN	USN-8917-1	Linux kernel vulnerabilities
Ubuntu USN	USN-8918-1	Linux kernel (Azure) vulnerabilities
Ubuntu USN	USN-9003-1	Linux kernel (NVIDIA) vulnerabilities
Ubuntu USN	USN-9024-1	Linux kernel vulnerabilities
Ubuntu USN	USN-9025-1	Linux kernel vulnerabilities
Ubuntu USN	USN-9026-1	Linux kernel (Azure) vulnerabilities
Ubuntu USN	USN-9029-1	Linux kernel (Raspberry Pi) vulnerabilities
Ubuntu USN	USN-9040-1	Linux kernel (Low Latency NVIDIA) vulnerabilities
Ubuntu USN	USN-9043-1	Linux kernel (NVIDIA) vulnerabilities
Ubuntu USN	USN-9066-1	Linux kernel (HWE) vulnerabilities
Ubuntu USN	USN-9091-1	Linux kernel (NVIDIA Tegra) vulnerabilities

Metrics

No CVSS v4.0

No CVSS v3.1

No CVSS v3.0

No CVSS v2

This CVE is not in the KEV list.

Exploit prediction score: < 1% (0.220% probability within 30 days)

Exploitation none

Automatable no

Technical Impact partial

References

Link	Providers
https://git.kernel.org/stable/c/14057268e79654c3e8ea2c9b5204cb9644b2964d
https://git.kernel.org/stable/c/24c3fa71f9947b0e1f3b954db1b769b44140192e
https://git.kernel.org/stable/c/3a63a11897c7ba32d1be7a3fdbc48a8b01cf4992
https://git.kernel.org/stable/c/7c9f0ccf9f04142458d2ac3d39414f4acae242f0
https://git.kernel.org/stable/c/c37e0a4b79a6bbb96ce5ffe279d7c001e20529e0
https://git.kernel.org/stable/c/cfada73fabe2ccc06ec77fe2ceaa088689213326
https://git.kernel.org/stable/c/dbcb8635b1eb7603818591cf745c7b1d714f7ac6
https://git.kernel.org/stable/c/ec5e96aee75d27779b9a860307679f13f33adb0c

History

Nov 7, 2026 7:30 AM Scoring metrics updated View changes

Type	Values Removed	Values Added
Metrics		ssvc `{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}`

Sep 4, 2026 10:00 PM Weaknesses updated View changes

Type	Values Removed	Values Added
Weaknesses		CWE-198

Sep 4, 2026 5:00 PM Description updated. Title updated. First appearance in the feed. Affected versions updated. Affected vendors updated. Added references View changes

Type	Values Removed	Values Added
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 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.
Title		ring-buffer: Fix event length with forced 8-byte alignment
First Time appeared		Linux Linux linux Kernel
CPEs		cpe:2.3:o:linux:linux_kernel::::::::
Vendors & Products		Linux Linux linux Kernel
References		https://git.kernel.org/stable/c/14057268e79654c3e8ea2c9b5204cb9644b2964d https://git.kernel.org/stable/c/24c3fa71f9947b0e1f3b954db1b769b44140192e https://git.kernel.org/stable/c/3a63a11897c7ba32d1be7a3fdbc48a8b01cf4992 https://git.kernel.org/stable/c/7c9f0ccf9f04142458d2ac3d39414f4acae242f0 https://git.kernel.org/stable/c/c37e0a4b79a6bbb96ce5ffe279d7c001e20529e0 https://git.kernel.org/stable/c/cfada73fabe2ccc06ec77fe2ceaa088689213326 https://git.kernel.org/stable/c/dbcb8635b1eb7603818591cf745c7b1d714f7ac6 https://git.kernel.org/stable/c/ec5e96aee75d27779b9a860307679f13f33adb0c