CVE-2026-80879
UnknownSummary
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.
Risk Assessment
The deadlock can hang the system or processes using OCFS2, leading to service unavailability and potential data loss. A local attacker able to trigger DIO operations could intentionally cause this condition, resulting in a denial of service.
Recommendation
Apply the Linux kernel update containing the fix for CVE-2026-80879. If unavailable, restrict access to OCFS2 filesystems and monitor kernel logs for circular locking warnings.
Other vulnerabilities in Linux kernel
See all- 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-80884Unknown
In the Linux kernel, a fix was made in the NTB driver to store the original DMA address for future release. The DMA API requires that dma_free_attrs receive the exact dma_handle originally returned by the allocation function. The fix prevents modifying it.
- CVE-2026-80883Unknown
In the Linux kernel, a fix was made in the Tegra graphics drivers (gr2d/gr3d) to initialize the address register map before the HOST1X client is registered. Previously, client registration occurred before initialization, potentially allowing userspace to submit jobs before initialization. The fix moves register initialization before client registration.
- 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-80878Unknown
In the Linux kernel, the AFS filesystem has a memory leak related to an ungot volume. The afs_lookup_volume_rcu() function does not release a dying volume when afs_try_get_volume() fails.
- 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-80876Unknown
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).
Original NVD description (English source)
In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix circular locking dependency in ocfs2_dio_end_io_write A circular locking dependency involves INODE_ALLOC_SYSTEM_INODE, EXTENT_ALLOC_SYSTEM_INODE, and ORPHAN_DIR_SYSTEM_INODE. 1. ocfs2_mknod() acquires INODE_ALLOC then EXTENT_ALLOC. 2. ocfs2_dio_end_io_write() acquires EXTENT_ALLOC for unwritten extents, then ORPHAN_DIR via ocfs2_del_inode_from_orphan() while still holding EXTENT_ALLOC. 3. ocfs2_wipe_inode() acquires ORPHAN_DIR then INODE_ALLOC via ocfs2_remove_inode. Break the cycle in ocfs2_dio_end_io_write() by freeing the allocation contexts (releasing EXTENT_ALLOC) before acquiring ORPHAN_DIR. WARNING: possible circular locking dependency detected ------------------------------------------------------ is trying to acquire lock: ffff8881e78b33a0 (&ocfs2_sysfile_lock_key[INODE_ALLOC_SYSTEM_INODE]){+.+.}-{4:4}, at: ocfs2_evict_inode+0x1539/0x43b0 fs/ocfs2/inode.c:1299 but task is already holding lock: ffff8881e78b4fa0 (&ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE]){+.+.}-{4:4}, at: ocfs2_evict_inode+0xe97/0x43b0 fs/ocfs2/inode.c:1299 the existing dependency chain (in reverse order) is: -> #2 (&ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE]){+.+.}-{4:4}: inode_lock include/linux/fs.h:1029 [inline] ocfs2_del_inode_from_orphan+0x12e/0x7a0 fs/ocfs2/namei.c:2728 ocfs2_dio_end_io+0xf9c/0x1370 fs/ocfs2/aops.c:2418 dio_complete+0x25b/0x790 fs/direct-io.c:281 -> #1 (&ocfs2_sysfile_lock_key[EXTENT_ALLOC_SYSTEM_INODE]){+.+.}-{4:4}: inode_lock include/linux/fs.h:1029 [inline] ocfs2_reserve_suballoc_bits+0x16d/0x4840 fs/ocfs2/suballoc.c:882 ocfs2_reserve_new_metadata_blocks+0x415/0x9a0 fs/ocfs2/suballoc.c:1078 ocfs2_mknod+0x10f3/0x2260 fs/ocfs2/namei.c:351 -> #0 (&ocfs2_sysfile_lock_key[INODE_ALLOC_SYSTEM_INODE]){+.+.}-{4:4}: __lock_acquire+0x15a5/0x2cf0 kernel/locking/lockdep.c:5237 lock_acquire+0x106/0x350 kernel/locking/lockdep.c:5868 down_write+0x96/0x200 kernel/locking/rwsem.c:1625 inode_lock include/linux/fs.h:1029 [inline] ocfs2_remove_inode fs/ocfs2/inode.c:733 [inline] ocfs2_wipe_inode fs/ocfs2/inode.c:896 [inline] ocfs2_delete_inode fs/ocfs2/inode.c:1157 [inline] ocfs2_evict_inode+0x1539/0x43b0 fs/ocfs2/inode.c:1299 Chain exists of: &ocfs2_sysfile_lock_key[INODE_ALLOC_SYSTEM_INODE] --> &ocfs2_sysfile_lock_key[EXTENT_ALLOC_SYSTEM_INODE] --> &ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE]); lock(&ocfs2_sysfile_lock_key[EXTENT_ALLOC_SYSTEM_INODE]); lock(&ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE]); lock(&ocfs2_sysfile_lock_key[INODE_ALLOC_SYSTEM_INODE]); *** DEADLOCK ***

