CVE-2026-46046

What it actually does

This is a local Linux kernel denial-of-service flaw in the ext4 filesystem extended-attribute handling path. A missing brelse() call in ext4_xattr_inode_dec_ref_all() can leak a buffer_head reference after ext4_get_inode_loc() is called under certain ext4/xattr conditions. Repeated triggering can cause kernel resource exhaustion, degraded filesystem behavior, hangs, or system unavailability. The issue does not directly provide confidentiality or integrity impact and requires local privileges to exercise filesystem operations on an affected ext4 filesystem.

Why it matters to the business

An attacker or untrusted local workload with access to an affected Linux system can potentially make the host unstable or unavailable, causing application downtime, failed jobs, service interruption, and possible emergency reboots. The risk is highest for shared Linux hosts, CI/build systems, container hosts, hosting platforms, and systems where less-trusted users or workloads can create or modify files on ext4 filesystems. This is not currently listed in CISA KEV, has low EPSS, and has no reported public exploit maturity, so broad internet-scale exploitation is unlikely; however, local denial-of-service issues can still be operationally significant in multi-user or multi-tenant environments.

How an attack unfolds

An attacker first obtains local access to a Linux system, such as a shell account, compromised low-privileged service account, or code execution inside a workload that can write to an ext4-backed filesystem. The attacker then performs repeated file extended-attribute operations designed to exercise the vulnerable ext4 xattr inode reference-decrement path. On affected kernels, the filesystem code obtains an inode location buffer but fails to release it in a specific path, leaking kernel references/resources over time. By repeatedly triggering this condition, the attacker can steadily consume kernel memory or related filesystem resources until the system becomes sluggish, triggers out-of-memory handling, hangs, or requires a reboot. Successful exploitation is local and availability-focused; it is not expected to directly disclose data or grant elevated privileges.

How to fix it

Update the Linux kernel to a vendor-supported version that includes the ext4 fix for the missing brelse() in ext4_xattr_inode_dec_ref_all(). No exact fixed package versions were provided in the input, so use the relevant distribution or appliance security advisory for the authoritative fixed kernel package. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads from writing to ext4 filesystems, isolating multi-tenant workloads, enforcing container resource limits where applicable, and monitoring for abnormal extended-attribute activity or kernel memory exhaustion. Mitigations should be treated as temporary; the durable fix is a patched kernel followed by rebooting into that kernel.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, has been updated to a build containing the ext4 xattr reference leak fix. Validate with uname -a, distribution package tools, and vendor advisory metadata. After patching and rebooting, run controlled extended-attribute create/remove workloads on non-production ext4 test filesystems while monitoring dmesg, journalctl -k, slab memory, OOM events, and filesystem errors. The system should not show growing unreclaimed kernel memory, buffer_head-related symptoms, ext4 warnings, or OOM behavior under repeated xattr operations. Also verify that untrusted users and workloads do not retain unnecessary write access to ext4-backed shared storage.

Typical attack path

1. Gain low-privileged local execution on a Linux system using an affected kernel.
2. Identify or use a writable ext4-backed filesystem where extended attributes are supported.
3. Create, modify, or remove files and extended attributes repeatedly to exercise the vulnerable ext4 xattr handling path.
4. Loop the operation to accumulate leaked kernel buffer references/resources.
5. Cause host degradation, OOM behavior, filesystem stalls, kernel warnings, or a full denial of service requiring administrator intervention.

How to detect it

There is no known unique network signature or definitive post-exploitation artifact for this local kernel denial-of-service issue. Detection should focus on evidence of suspicious local triggering and resulting host instability. Review kernel logs from journalctl -k, dmesg, syslog, and distribution crash/OOM logs for ext4 warnings, OOM killer activity, hung tasks, soft lockups, or filesystem stalls around the same time as bursts of file extended-attribute activity. If auditd or eBPF syscall telemetry is available, search for unusually high volumes of setxattr, lsetxattr, fsetxattr, removexattr, lremovexattr, or fremovexattr calls by a single user, process, container, or service account. Review shell histories, process accounting, EDR telemetry, and command logs for repeated use of setfattr/getfattr or scripts looping over xattr operations. Correlate these findings with memory pressure, slab growth, host hangs, service restarts, or reboots. Absence of these artifacts does not prove non-exploitation because a resource-exhaustion attempt may leave only generic instability evidence.

• setfattr
• getfattr
• removexattr
• setxattr
• lsetxattr
• fsetxattr
• lremovexattr
• fremovexattr
• EXT4-fs error
• EXT4-fs warning
• Out of memory: Killed process
• oom-killer
• kernel: INFO: task
• blocked for more than
• soft lockup
• hung task
• ext4_xattr_inode_dec_ref_all
• buffer_head

What your security team should do

• Prioritize patching shared, multi-user, container-hosting, CI/CD, build, and HPC Linux systems where low-privileged users or workloads can write to ext4 filesystems.
• Track vendor advisories for the exact fixed kernel package and ensure systems are rebooted into the fixed kernel after installation.
• Inventory Linux systems using ext4, especially those with untrusted local users or workloads, and rank them ahead of single-user or tightly controlled systems.
• Add monitoring for abnormal rates of extended-attribute syscalls, setfattr/removexattr usage, OOM killer events, kernel memory pressure, and ext4 filesystem errors.
• Temporarily restrict local access, filesystem write permissions, or untrusted workload placement on vulnerable systems until patched.
• Review recent kernel logs and audit logs for signs of unexplained local resource exhaustion or repeated xattr manipulation before patching.
• Because there is no KEV listing, no known ransomware use, and low EPSS, handle as maintenance-priority for tightly controlled systems but elevate urgency where local multi-tenant abuse is plausible.