CVE-2026-53303

What it actually does

This is a Linux kernel race condition in the F2FS filesystem sysfs interface. The affected code reads F2FS extension metadata such as the extension list and related counters without holding the required superblock lock while another thread can concurrently modify that same data through the sysfs store path. Under the right timing, the kernel may read inconsistent list contents or counters, which can lead to stale data exposure, out-of-bounds reads, kernel warnings, or a local denial of service such as a kernel crash. The flaw is local and F2FS-specific; systems that do not have F2FS enabled or mounted are unlikely to be exposed.

Why it matters to the business

The primary operational risk is instability of Linux systems using F2FS, especially if local users, containers, or administrative automation can interact with F2FS sysfs files. Successful exploitation could crash affected hosts or expose limited kernel-resident data, causing service interruption and potential incident response activity. Current exploitation signals are low: EPSS is 0.00126, there is no known CISA KEV listing, no ransomware association is reported, and exploit maturity is listed as none. Remediation should still be incorporated into normal kernel patch cycles, with higher priority for multi-user systems, container hosts, embedded devices, mobile/edge systems, and appliances that use F2FS.

How an attack unfolds

An attacker first needs local access to a system where the F2FS filesystem is present and an F2FS instance is mounted. The attacker then attempts to interact with the F2FS sysfs extension-list interface from multiple execution contexts at the same time. One thread repeatedly reads the sysfs attribute that formats and displays the F2FS extension list, while another thread repeatedly updates the extension list through the corresponding sysfs store path. Because vulnerable kernels do not hold the superblock lock around the full read-and-format operation, the reader can observe the list and counters while they are being changed. If the race is won, the kernel may use mismatched counts and array contents, potentially causing an out-of-bounds access, displaying stale data, triggering KASAN or kernel warnings on instrumented builds, or crashing the system. There is no indication from the supplied intelligence that public weaponized exploitation or broad in-the-wild abuse exists.

How to fix it

Apply a Linux kernel update from the relevant distribution, device vendor, or kernel maintainer that includes the F2FS locking fix for f2fs_sbi_show(). No exact fixed package versions were provided in the input, so use vendor advisories and changelogs to identify the first kernel build containing the patch. Reboot into the patched kernel after installation; kernel package installation alone is not sufficient if the host continues running the old kernel. Where immediate patching is not possible, reduce exposure by disabling or avoiding F2FS where it is not required, unmounting unnecessary F2FS filesystems, preventing untrusted users or containers from accessing host /sys, avoiding read-write bind mounts of /sys into containers, and restricting administrative capabilities that allow modification of filesystem sysfs attributes.

How to confirm the fix worked

Confirm whether the system is potentially exposed by checking for F2FS support and usage, such as loaded f2fs modules, CONFIG_F2FS_FS in the running kernel configuration, and mounted F2FS filesystems. Verify the active kernel version with uname -a and confirm through distribution package metadata or vendor changelogs that the running kernel includes the F2FS sb_lock fix for f2fs_sbi_show(). After patching, reboot and confirm the patched kernel is active. Validate hardening by checking that untrusted users and containers cannot write to host F2FS sysfs attributes and that /sys is not exposed read-write to workloads that do not require it. On test systems, concurrent reads and writes to the F2FS extension-list sysfs interface should no longer produce kernel warnings, KASAN findings, or crashes.

Typical attack path

1. Gain local execution on a Linux system that has F2FS support enabled and an F2FS filesystem mounted.
2. Identify the F2FS sysfs directory for the mounted filesystem, commonly under /sys/fs/f2fs/.
3. Repeatedly read the F2FS extension-list sysfs attribute to trigger the vulnerable show path.
4. Concurrently modify the same extension list through the sysfs store interface to create an inconsistent read/write race.
5. Attempt to win the race until the kernel reads mismatched extension counts and list contents.
6. Observe resulting impact such as stale data output, kernel warning, out-of-bounds read report, or system crash.

How to detect it

To investigate prior exploitation, focus on local activity and kernel telemetry rather than network indicators. Review kernel logs from journalctl, dmesg, /var/log/kern.log, /var/log/messages, and crash dumps for F2FS-related warnings, kernel oopses, KASAN or UBSAN reports, general protection faults, or panics referencing f2fs_sbi_show, extension_list, or /sys/fs/f2fs. Review auditd, EDR, process accounting, shell history, and sudo logs for repeated or scripted reads and writes under /sys/fs/f2fs/, especially extension_list. On container platforms, check whether containers had host /sys mounted read-write and whether processes inside containers accessed /sys/fs/f2fs/. If kernel crash dumps are available, inspect stack traces for f2fs_sbi_show or F2FS sysfs handlers. There are no known remote network indicators for this issue based on the supplied intelligence.

• /sys/fs/f2fs/
• /sys/fs/f2fs/*/extension_list
• extension_list
• f2fs_sbi_show
• f2fs_update_extension_list
• BUG: KASAN: slab-out-of-bounds in f2fs_sbi_show
• KASAN: slab-out-of-bounds
• UBSAN: array-index-out-of-bounds
• general protection fault
• Unable to handle kernel paging request
• kernel BUG
• Oops:
• Call Trace:
• F2FS-fs
• sysfs

What your security team should do

• Inventory Linux systems using F2FS, prioritizing multi-user hosts, container hosts, embedded systems, appliances, mobile/edge devices, and systems exposing host /sys to workloads.
• Patch affected systems through the normal kernel update process and verify they have rebooted into a fixed kernel.
• Treat systems with writable host /sys exposure to containers or untrusted workloads as higher risk and remediate that configuration independently of kernel patching.
• If F2FS is not required, disable its use, unmount F2FS filesystems, or prevent loading the F2FS module where operationally feasible.
• Add monitoring for kernel crash, KASAN, UBSAN, general protection fault, and F2FS sysfs-related messages until patching is complete.
• Review audit logs, shell history, EDR telemetry, and container runtime configurations for unusual access to /sys/fs/f2fs/ paths.
• Because current EPSS and exploitation maturity are low and there is no KEV listing, prioritize remediation based on F2FS presence and local access exposure rather than emergency internet-facing risk.