CVE-2026-31446

What it actually does

This is a Linux kernel use-after-free flaw in the ext4 filesystem teardown path. A race can occur between ext4 unmount processing and pending ext4 superblock update work: sysfs entries for the ext4 filesystem can be removed while queued work still calls ext4_notify_error_sysfs() and ultimately sysfs_notify() on a kobject whose kernfs_node has already been freed. If the race is triggered, the kernel may dereference freed memory. Depending on kernel configuration, memory layout, and exploit reliability, impact can range from kernel crash or panic to potential local privilege escalation through controlled use-after-free exploitation. The CVSS vector indicates local attack requirements and user interaction, with high confidentiality, integrity, and availability impact if successfully exploited.

Why it matters to the business

Systems using affected Linux kernels with ext4 filesystems may be exposed to local denial-of-service risk and, in worst cases, local elevation of privilege. Because exploitation requires local access or the ability to influence local filesystem operations, the risk is highest on multi-user Linux servers, shared hosting platforms, container hosts, developer workstations, CI/CD runners, and systems where untrusted users can trigger mount, unmount, or filesystem error paths. This issue is not listed in CISA KEV, is not marked as ransomware-associated, has no known mature public exploit in the provided data, and has a low, flat EPSS score, so emergency internet-scale exploitation is unlikely; however, kernel memory-safety flaws should still be patched promptly because successful exploitation can compromise the entire host.

How an attack unfolds

An attacker first needs code execution or interactive access on a vulnerable Linux system, or another path that lets them influence local filesystem activity. The attacker then attempts to create conditions where ext4 superblock update work is pending while an ext4 filesystem is being unmounted. During unmount, ext4 sysfs objects can be removed before the pending update work is flushed. If the queued work subsequently tries to notify sysfs of an ext4 error, it can access a kobject/kernfs_node that has already been freed. A basic exploit may simply trigger a kernel oops or panic, causing a denial of service. A more advanced exploit would attempt to win the race repeatedly and shape kernel heap memory so the freed kernfs_node memory is replaced with attacker-influenced data, potentially redirecting kernel execution or corrupting kernel state to gain elevated privileges. No known exploitation campaigns or named threat actors were provided, and exploit maturity is listed as none.

How to fix it

Apply a Linux kernel update from the operating system or kernel vendor that includes the ext4 fix. The corrected behavior makes ext4_notify_error_sysfs() check whether the kobject is still present in sysfs before calling sysfs_notify(), and uses serialization to prevent a race between that check and kobject deletion. No exact fixed package versions were provided in the input, so remediation should be based on vendor advisories and package changelogs for the relevant distribution kernel. Where live patching is available from the vendor, it may reduce reboot urgency, but a reboot or kernel live-patch activation is required for the running kernel to be protected. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted users, preventing unprivileged mount/user-namespace workflows where feasible, isolating multi-tenant workloads, and monitoring for kernel oops/panic events involving ext4, sysfs, kernfs, or update_super_work. Avoid relying on filesystem configuration alone as a complete mitigation if ext4 remains in use.

How to confirm the fix worked

Confirm that the running kernel, not only the installed kernel package, has been updated. Check the active kernel with uname -r and compare it to the vendor advisory or package changelog that contains the ext4 use-after-free fix. On package-managed systems, verify the installed kernel package version and confirm the system has rebooted into the fixed kernel or that an approved live patch is active. Review distribution changelogs for references to ext4, update_super_work, ext4_notify_error_sysfs(), sysfs_notify(), kobject_del(), state_in_sysfs, or s_error_notify_mutex. Confirm ext4 filesystems are present where relevant by reviewing mount output, /proc/mounts, or filesystem inventory. For exposure testing in non-production only, run controlled mount/unmount stress and ext4 error-notification tests under a fixed kernel and verify there are no kernel warnings, KASAN reports, oopses, or panics referencing ext4_notify_error_sysfs, kernfs_get, sysfs_notify, or update_super_work.

Typical attack path

1. Gain local ability to run code or otherwise trigger local ext4 filesystem operations on a vulnerable Linux host.
2. Identify or create an ext4 filesystem context where mount, unmount, error notification, or superblock update activity can be influenced.
3. Trigger ext4 error or superblock update work so s_sb_upd_work is queued.
4. Race the queued update_super_work path against ext4 unmount teardown, specifically ext4_unregister_sysfs() and kobject deletion.
5. Cause ext4_notify_error_sysfs() to call sysfs_notify() after the relevant kobject/kernfs_node has been removed.
6. Leverage the resulting use-after-free to crash the kernel, or attempt heap grooming and repeated triggering for local privilege escalation.

How to detect it

Look for evidence of attempted or successful triggering in kernel logs and crash artifacts rather than network telemetry, because this is a local kernel race in ext4. Relevant sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, systemd-coredump metadata, kdump/vmcore repositories, hypervisor reset logs, EDR kernel event telemetry, and kernel panic/oops alerting. Search for crashes or warnings involving ext4_notify_error_sysfs(), sysfs_notify(), kernfs_get(), kobject_del(), ext4_unregister_sysfs(), ext4_put_super(), update_super_work, or s_sb_upd_work. KASAN-enabled systems may report explicit use-after-free findings; production systems without KASAN may show general protection faults, NULL or non-canonical pointer dereferences, RCU/kernfs warnings, hung tasks, or unexpected reboots during ext4 unmount activity. Correlate any such kernel event with recent local user activity, mount/umount operations, loop device usage, container lifecycle events, removable media activity, filesystem error messages, and privilege changes. There are no provided network indicators, malware hashes, or threat actor-specific artifacts for this CVE.

• BUG: KASAN: use-after-free in kernfs_get
• KASAN: use-after-free in kernfs_get
• use-after-free in kernfs_get
• kernfs_get
• sysfs_notify
• ext4_notify_error_sysfs
• update_super_work
• s_sb_upd_work
• ext4_unregister_sysfs
• ext4_put_super
• kobject_del
• sysfs_remove_dir
• kernfs_put
• general protection fault:.*kernfs_get
• Oops:.*kernfs_get
• kernel panic.*ext4
• EXT4-fs error
• EXT4-fs warning
• WARNING:.*fs/ext4
• BUG: unable to handle kernel NULL pointer dereference.*sysfs_notify
• BUG: unable to handle page fault.*kernfs_get

What your security team should do

• Prioritize patching Linux systems that allow local users, shared workloads, CI jobs, containers, or untrusted code execution, especially where ext4 is used.
• Track vendor kernel advisories and update to a kernel build that explicitly includes the ext4 update_super_work/sysfs use-after-free fix.
• Verify systems have rebooted into the fixed kernel or that an approved kernel live patch is active; installed-but-not-running kernel updates do not remediate the issue.
• Reduce local attack surface until patched by limiting interactive access, disabling unnecessary unprivileged mount paths, and reviewing user namespace policy where applicable.
• Add monitoring for kernel oops, panic, KASAN, ext4, sysfs, and kernfs crash indicators that may show failed exploitation or instability.
• Treat any kernel crash involving ext4_notify_error_sysfs(), sysfs_notify(), kernfs_get(), or update_super_work as a high-priority forensic event on multi-user or externally managed hosts.
• Because this is not currently KEV-listed and has low EPSS with no known mature exploit, schedule remediation based on local exposure rather than internet-facing emergency triage, while still respecting normal kernel security patch SLAs.