CVE-2026-80809 in Linuxinfo

Summary

by MITRE • 09/04/2026

In the Linux kernel, the following vulnerability has been resolved:

ocfs2: fix missing metadata reservation for large xattrs

[BUG]
lsetxattr() panics the kernel when setting a large xattr value on a fragmented filesystem where the file already has an external xattr block.

[CAUSE]
ocfs2_calc_xattr_set_need() never reserves metadata blocks for a new xattr value's extent tree when the file already has an external xattr block. The not_found path leaves meta_add at zero, so meta_ac is NULL when ocfs2_xattr_extend_allocation() runs.

A new value root has room for a single extent record. On a fragmented filesystem, the allocator cannot satisfy the xattr value in one contiguous run, so each non-contiguous run requires its own extent record. When the value root's extent list is full and meta_ac is NULL, ocfs2_add_clusters_in_btree() returns RESTART_META, and ocfs2_xattr_extend_allocation() hits BUG_ON(why == RESTART_META).

[FIX]
The case where no xattr block exists yet already calls ocfs2_extend_meta_needed(&def_xv.xv.xr_list) to reserve value tree metadata. Add the same reservation to the case where an xattr block already exists, making the two cases consistent.

Replace the BUG_ON with a -ENOSPC return so that if RESTART_META is returned despite the reservation, the error propagates to userspace instead of panicking the kernel.

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Analysis

by VulDB Data Team • 09/04/2026

The Open Cluster File System version 2 (OCFS2) implementation within the Linux kernel contains a critical logic flaw in its extended attribute handling mechanism, specifically affecting scenarios where large attributes are set on files that already possess external xattr blocks. This vulnerability manifests as a local denial of service condition, resulting in a kernel panic when an unprivileged or privileged user attempts to invoke the lsetxattr system call with a sufficiently large value under specific fragmentation conditions. The root cause lies in the ocfs2_calc_xattr_set_need function, which fails to reserve necessary metadata blocks for the extent tree associated with a new xattr value if the file already maintains an external xattr block. In this code path, identified as not_found, the variable meta_add remains zero, leading to a null pointer assignment for meta_ac when ocfs2_xattr_extend_allocation is subsequently executed.

The operational impact of this flaw becomes apparent during the allocation process on fragmented filesystems. When setting a large extended attribute, the system must allocate space for both the value and its metadata structure. The root node of the extent tree has capacity for only a single extent record initially. However, if the underlying storage is fragmented such that the new xattr value cannot be stored in one contiguous run, each non-contiguous segment requires its own distinct extent record to map it within the b-tree structure. As the allocator attempts to satisfy these multiple runs, the extent list of the value root quickly becomes full. Because meta_ac was incorrectly initialized as NULL due to the missing reservation logic, the function ocfs2_add_clusters_in_btree returns a RESTART_META status code indicating that metadata allocation failed and needs retrying with proper reservations.

The presence of this error condition triggers an immediate kernel panic because the calling function ocfs2_xattr_extend_allocation contains a BUG_ON macro that asserts why is not equal to RESTART_META. This design choice assumes that all necessary metadata will be pre-reserved, preventing such errors from occurring in normal operation. However, due to the oversight in the code path for files with existing external xattr blocks, this assumption is violated on fragmented volumes. The BUG_ON macro causes an unconditional kernel panic, effectively crashing the entire system and denying service to all users and processes running on that host. This represents a significant stability risk, particularly in clustered environments where OCFS2 is commonly deployed, as it allows any user with write access to the affected file to destabilize the node.

The resolution involves correcting the metadata reservation logic to ensure consistency between files with new xattr blocks and those with existing ones. The fix adds a call to ocfs2_extend_meta_needed for the value tree extent list in the case where an xattr block already exists, mirroring the behavior of the path where no xattr block is present yet. This ensures that sufficient metadata space is reserved before attempting allocation. Furthermore, the remediation replaces the BUG_ON assertion with a proper error handling mechanism that returns -ENOSPC to userspace if RESTART_META is still encountered despite reservations. This change prevents kernel panics by gracefully propagating resource exhaustion errors rather than crashing the system, aligning the behavior with standard POSIX expectations for storage limits.

From a security taxonomy perspective, this vulnerability corresponds to CWE-20 Improper Input Validation and CWE-754: Improper Check for Unusual or Exceptional Conditions. The failure lies in not validating that sufficient resources are available before proceeding with complex allocation logic, leading to an unhandled exception state. In terms of the MITRE ATT&CK framework, this flaw facilitates Local Privilege Escalation via Denial of Service (T1053), although its primary impact is availability rather than confidentiality or integrity compromise. Attackers can exploit this by crafting specific file systems with high fragmentation and attempting to set large extended attributes on files that already have external xattr blocks. Mitigation strategies include applying the kernel patch provided in the upstream release, ensuring filesystems are defragmented where possible to reduce the likelihood of triggering the multi-run allocation path, and monitoring for repeated lsetxattr failures which may indicate exploitation attempts. System administrators should also consider implementing resource limits on extended attribute sizes through security modules like SELinux or AppArmor if granular control is required, although the kernel fix remains the primary defense against this specific logic error.

Responsible

Linux

Reservation

08/26/2026

Disclosure

09/04/2026

Moderation

accepted

CPE

ready

EPSS

0.00195

KEV

no

Activities

very low

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!