CVE-2026-80876
UnknownSummary
A vulnerability was found in the Linux kernel's ring buffer mechanism used by ftrace. When RB_FORCE_8BYTE_ALIGNMENT is enabled (e.g., on riscv64 with CONFIG_HAVE_64BIT_ALIGNED_ACCESS), ring_buffer_event_length() incorrectly calculates the length of small events, reporting a data length 4 bytes larger than expected. This causes inconsistent results in ftrace tests (trace_marker_raw).
Risk Assessment
The vulnerability leads to incorrect event length readings in the ring buffer, which may cause malfunction of diagnostic tools (ftrace) and hinder system analysis. In extreme cases, it could affect stability or security of systems using these mechanisms on architectures with forced 8-byte alignment.
Recommendation
It is recommended to apply the patch provided by the Linux kernel vendor as soon as possible (update to a version containing the fix for CVE-2026-80876). Monitor distribution security advisories and test the system after the update.
Other vulnerabilities in Linux kernel
See all- CVE-2026-80919Unknown
In the Linux kernel, a vulnerability was found in the amdgpu driver where amdgpu_devcoredump_format() recursively acquires a ww_mutex lock. This can lead to a deadlock when dumping IB contents from a hung job. The fix moves the operation to a separate helper using a single drm_exec context.
- CVE-2026-80915Unknown
In the Linux kernel, the drm/xe driver's DPT allocation paths were fixed. The fallback from VRAM to system memory was removed as it did not work and caused black screen with pipe faults. Also, stolen memory usage is avoided due to latency and risk of random system hangs under load.
- CVE-2026-80886Unknown
In the Linux kernel, a vulnerability in the msm serial driver was fixed by disabling DMA for the console UART. Concurrent writes from userspace and the kernel can trigger a race condition resulting in an infinite loop of the same messages. The fix disables DMA for the console UART to ensure a reliable output path.
- CVE-2026-80885Unknown
In the Linux kernel, a fix was made for an uncancelled rxrpc OOB message handler in AFS. The fix cancels OOB message processing (typically to respond to security challenges) and moves it to afs_wq so it is also waited for. The OOB handler now returns if the net namespace is no longer live.
- CVE-2026-80882Unknown
In the Linux kernel, a fix was made in the Tegra crypto driver to return ENOMEM when input buffer allocation fails for ccm. The fix ensures the ENOMEM error value is set when the allocation fails in tegra_ccm_do_one_req.
- CVE-2026-80881Unknown
In the Linux kernel, a fix was made in the OCFS2 filesystem regarding buffer head management in ocfs2_read_blocks(). The fix clarifies that the caller should not assume that the buffer head returned by sb_getblk() is exclusively owned and that put_bh() always drops b_count from 1 to 0. To avoid a scenario where a buffer head remains on hold and may be returned with BH_Uptodate set despite previous validation failure, BH_Uptodate is now cleared immediately after the validate() callback detects data inconsistency.
- CVE-2026-80880Unknown
In the Linux kernel, the IB/mlx5 driver has a vulnerability related to implicit ODP and rereg_mr operation. Due to child mkeys in the implicit ODP configuration, nothing can be changed in place for the parent mkey, so the whole structure must be rebuilt. Additionally, a race condition involving access to mr->pd by child keys was removed.
- CVE-2026-80879Unknown
A circular locking dependency was found in the Linux kernel's OCFS2 filesystem during direct I/O write completion. The ocfs2_dio_end_io_write function could deadlock due to improper lock ordering involving system inodes (INODE_ALLOC, EXTENT_ALLOC, ORPHAN_DIR). The fix releases allocation contexts before acquiring the ORPHAN_DIR lock.
- CVE-2026-80877Unknown
In the Linux kernel, the AFS filesystem has a memory leak related to the vllist in afs_update_cell(). When the new list is empty (nr_servers == 0), the old list is not replaced, leading to a leak of the new list.
- CVE-2026-80875Unknown
In the Linux kernel, the IPVS module has a vulnerability in TCP state handling. The code reparses the packet to find the TCP header, using sizeof(struct ipv6hdr) for IPv6, while the actual transport header offset is already known from ip_vs_fill_iph_skb(). For IPv6 packets with extension headers, this leads to reading the wrong bytes.
Original NVD description (English source)
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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

