From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-cve-announce@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@kernel.org>
Subject: CVE-2026-80876: ring-buffer: Fix event length with forced 8-byte alignment
Date: Fri, 4 Sep 2026 18:46:43 +0200 [thread overview]
Message-ID: <2026090435-CVE-2026-80876-8d4a@gregkh> (raw)
From: Greg Kroah-Hartman <gregkh@kernel.org>
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.
The Linux kernel CVE team has assigned CVE-2026-80876 to this issue.
Affected and fixed versions
===========================
Issue introduced in 2.6.34 with commit 2271048d1b3b0aabf83d25b29c20646dcabedc05 and fixed in 5.10.261 with commit 7c9f0ccf9f04142458d2ac3d39414f4acae242f0
Issue introduced in 2.6.34 with commit 2271048d1b3b0aabf83d25b29c20646dcabedc05 and fixed in 5.15.212 with commit 24c3fa71f9947b0e1f3b954db1b769b44140192e
Issue introduced in 2.6.34 with commit 2271048d1b3b0aabf83d25b29c20646dcabedc05 and fixed in 6.1.178 with commit 14057268e79654c3e8ea2c9b5204cb9644b2964d
Issue introduced in 2.6.34 with commit 2271048d1b3b0aabf83d25b29c20646dcabedc05 and fixed in 6.6.145 with commit dbcb8635b1eb7603818591cf745c7b1d714f7ac6
Issue introduced in 2.6.34 with commit 2271048d1b3b0aabf83d25b29c20646dcabedc05 and fixed in 6.12.97 with commit cfada73fabe2ccc06ec77fe2ceaa088689213326
Issue introduced in 2.6.34 with commit 2271048d1b3b0aabf83d25b29c20646dcabedc05 and fixed in 6.18.40 with commit ec5e96aee75d27779b9a860307679f13f33adb0c
Issue introduced in 2.6.34 with commit 2271048d1b3b0aabf83d25b29c20646dcabedc05 and fixed in 7.1.5 with commit 3a63a11897c7ba32d1be7a3fdbc48a8b01cf4992
Issue introduced in 2.6.34 with commit 2271048d1b3b0aabf83d25b29c20646dcabedc05 and fixed in 7.2 with commit c37e0a4b79a6bbb96ce5ffe279d7c001e20529e0
Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.
Unaffected versions might change over time as fixes are backported to
older supported kernel versions. The official CVE entry at
https://cve.org/CVERecord/?id=CVE-2026-80876
will be updated if fixes are backported, please check that for the most
up to date information about this issue.
Affected files
==============
The file(s) affected by this issue are:
kernel/trace/ring_buffer.c
Mitigation
==========
The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes. Individual
changes are never tested alone, but rather are part of a larger kernel
release. Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all. If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
https://git.kernel.org/stable/c/7c9f0ccf9f04142458d2ac3d39414f4acae242f0
https://git.kernel.org/stable/c/24c3fa71f9947b0e1f3b954db1b769b44140192e
https://git.kernel.org/stable/c/14057268e79654c3e8ea2c9b5204cb9644b2964d
https://git.kernel.org/stable/c/dbcb8635b1eb7603818591cf745c7b1d714f7ac6
https://git.kernel.org/stable/c/cfada73fabe2ccc06ec77fe2ceaa088689213326
https://git.kernel.org/stable/c/ec5e96aee75d27779b9a860307679f13f33adb0c
https://git.kernel.org/stable/c/3a63a11897c7ba32d1be7a3fdbc48a8b01cf4992
https://git.kernel.org/stable/c/c37e0a4b79a6bbb96ce5ffe279d7c001e20529e0
reply other threads:[~2026-09-04 16:49 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2026090435-CVE-2026-80876-8d4a@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=cve@kernel.org \
--cc=gregkh@kernel.org \
--cc=linux-cve-announce@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.