CVE-2026-80876None▾ SunlitIn 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…
▾ Sunlit zone — Low / medium · no exploitation signal
impact 2.8 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Stakeholder-Specific Vulnerability Categorization from CISA's ADP record at CVE.org: whether exploitation is observed, whether an attack can be automated, and how much of the system is at stake.
Exploit-prediction probability, daily snapshots since Nov 6.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via CVEORG
Last analysed / modified upstream
0.2%
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:
...
...
After applying this change, the number of data field keeps being 8*N+4 consistently.
Linux >= 2271048d1b3b0aabf83d25b29c20646dcabedc05 < 7c9f0ccf9f04142458d2ac3d39414f4acae242f0Linux >= 2271048d1b3b0aabf83d25b29c20646dcabedc05 < 24c3fa71f9947b0e1f3b954db1b769b44140192eLinux >= 2271048d1b3b0aabf83d25b29c20646dcabedc05 < 14057268e79654c3e8ea2c9b5204cb9644b2964dLinux >= 2271048d1b3b0aabf83d25b29c20646dcabedc05 < dbcb8635b1eb7603818591cf745c7b1d714f7ac6Linux >= 2271048d1b3b0aabf83d25b29c20646dcabedc05 < cfada73fabe2ccc06ec77fe2ceaa088689213326Linux >= 2271048d1b3b0aabf83d25b29c20646dcabedc05 < ec5e96aee75d27779b9a860307679f13f33adb0cLinux >= 2271048d1b3b0aabf83d25b29c20646dcabedc05 < 3a63a11897c7ba32d1be7a3fdbc48a8b01cf4992Linux >= 2271048d1b3b0aabf83d25b29c20646dcabedc05 < c37e0a4b79a6bbb96ce5ffe279d7c001e20529e0Linux 2.6.34Refer to the linked advisories for vendor-supplied fixes and affected version ranges.
Connected by shared product, vendor, weakness, or advisory.
CVE-2026-99284Nonenet: skbuff: propagate shared-frag marker in skb_zerocopy()
CVE-2026-99283Nonenetfilter: conntrack: tcp: use UNACK timeout for non-closing RST packets
CVE-2026-99272Nonesmb: client: validate the data area in SMB2_read()
CVE-2026-99271NoneALSA: line6: Clear prev_fbuf on capture buffer release
CVE-2026-99273Noneksmbd: reserve space for the UTF-16 terminator in stream info
CVE-2026-99275Nonesmb: client: reject short SESSION_SETUP responses