CVE-2023-53447: f2fs remount race triggers kernel crash explained

A subtle race in the f2fs remount logic can leave the filesystem in a dangerous state: a kernel crash triggered by an inconsistent mount-option transition. The flaw tracked as CVE-2023-53447 arises when f2fs resets certain mount options during a remount operation, creating a brief window in which two concurrent threads can disagree about whether READ_EXTENT_CACHE is enabled — and that disagreement can lead to a NULL-pointer access and a general protection fault.

Background​

F2FS (Flash-Friendly File System) is a Linux filesystem optimized for NAND flash devices and SSDs. Like other Linux filesystems, f2fs supports runtime changes to mount options via remount operations. Remount handling is delicate: remounts must coordinate with concurrent filesystem operations (reads, writes, and syscall-driven operations such as fallocate) to avoid races that can corrupt kernel state or cause crashes.
The specific problem reported by syzbot is a kernel oops stemming from __lock_acquire invoked from f2fs extent-cache code during a fallocate path; tracing shows the crash arises from a race between remount logic and the fallocate path where extent-cache state is toggled in one thread and used in another. Vendor advisories and vulnerability trackers characterize the root cause as a race caused by f2fs_remount resetting mount options to defaults before parse_options re-applies requested options, leaving a small but exploitable hole.

---

What happened: short summary of the bug​

• The f2fs remount path calls a routine that resets mount options to default values, then calls parse_options to set options according to the new mount request.
• Some mount options are effectively unchangeable at remount time (for example, options baked into the superblock or features that cannot be toggled on-the-fly), but the code resets everything and then re-applies options.
• If a concurrent thread calls fallocate (or another code path that manipulates extent structures) during that brief window, it may observe the filesystem with the option state inconsistent with the underlying extent structures, resulting in a NULL-pointer dereference when the code expects an initialized extent cache.
• The crash stack reported by syzbot shows f2fs_insert_range -> f2fs_drop_extent_tree -> __drop_extent_tree -> write_lock on a NULL lock pointer. That sequence matches a frame where test_opt(READ_EXTENT_CACHE) returns true while the extent tree is not set up (or vice versa).

This is a local race condition that requires concurrent activity on the same filesystem (remount plus an f2fs file operation like fallocate). The impact classification in vendor advisories is generally medium (availability impact via kernel crash), though the exact CVSS and downstream severity can vary by distribution. Amazon’s vulnerability tracker and other vendors list CVSS characteristics consistent with a medium-severity, locally exploitable denial-of-service.

---

Technical deep dive: how the race unfolds​

Relevant code paths and state​

• f2fs_remount: invoked when the VFS processes a remount (e.g., mount -o remount,rw). That function is responsible for changing runtime mount flags and options for the filesystem.
• default_options: a helper that sets the filesystem’s options to a defined default state.
• parse_options: parses the incoming options and sets/clears option bits accordingly.
• READ_EXTENT_CACHE option: a boolean/flag that controls whether the f2fs extent cache is used for reads. The extent cache holds mapping and extent-tree information that other operations rely on.
• f2fs_fallocate -> f2fs_insert_range -> f2fs_drop_extent_tree -> __drop_extent_tree: the fallocate path manipulates extent cache structures and acquires locks on the extent tree; these operations assume the extent cache handling is consistent with the state of the READ_EXTENT_CACHE option.

The race (simplified)​

• Thread A is executing f2fs_fill_super / parse_options during mount or some initialization. It calls parse_options and clears the READ_EXTENT_CACHE option (or otherwise sets up an initial state) because parse_options is deciding the option state based on superblock/fs state or prior mount arguments.
• Thread B issues a remount that calls f2fs_remount. f2fs_remount calls default_options, resetting option bits to defaults (which may include setting READ_EXTENT_CACHE).
• Immediately afterward, still in thread B’s remount, parse_options is called to set the options according to the remount request.
• Between the default_options reset and parse_options completing, thread A (or another thread) executes fallocate, which enters f2fs_insert_range and eventually f2fs_drop_extent_tree. That code checks test_opt(READ_EXTENT_CACHE) and — depending on the value it reads — assumes the extent-tree pointers/locks exist and calls write_lock on et->lock.
• If test_opt returns true because default_options briefly set READ_EXTENT_CACHE, but parse_options has not yet cleared or adjusted internal data structures, et may be NULL or uninitialized, causing a write_lock on a NULL pointer and a kernel oops.

Why resetting to defaults is fragile​

Resetting all mount option bits en masse to defaults is a straightforward implementation strategy, but it ignores unchangeable options (options that the VFS or userland already enforced or which are controlled by the on-disk superblock). The filesystem must be careful to avoid transient states that are inconsistent with internal in-memory structures while other threads are concurrently accessing those structures.
In this case, the transient state is small (the time between default_options and parse_options), but concurrency makes even micro-windows exploitable by syzbot fuzzers and real workloads. The intended fix is to avoid overwriting options that cannot, or should not, be atomically toggled during a remount, or to hold the necessary locks/synchronization while options are changed so that other threads cannot observe inconsistent state. Vendor advisories and patch descriptions explicitly call out that f2fs should not reset unchangeable mount options during remount.

---

Evidence and verification​

Multiple independent sources document the same root cause and remediation approach:

• NVD and OSV provide canonical CVE descriptions describing the issue as “f2fs: don't reset unchangable mount option in f2fs_remount” and quote the syzbot stack trace that led to discovery. Those entries summarize the race between remount and fallocate and the default_options/parsing hole.
• Distribution trackers (Debian, SUSE, Ubuntu) list affected and fixed kernel package versions and include notes referencing kernel commits that address the issue. Debian’s tracker additionally lists the particular kernel versions where the vulnerability was fixed or where packages remain vulnerable.
• Public mailing list threads and kernel-stable mirror threads record the patch submissions and backport attempts; one thread notes a failed attempt to apply a patch to a stable tree and contains the same explanatory text about the remount/default_options hole. This cross-check confirms the vendor descriptions and the proposed code-level change.

Note on verifiability: while the patch references and commit IDs are publicly noted by vendors and trackers, direct access to some kernel.org commit pages returned HTTP 403 during the research window. The inability to fetch raw commit content from kernel.org does not negate the corroboration by multiple vendors and mailing-list archives, but it does mean the primary commit diff could not be embedded or quoted verbatim in this article; the fix descriptions and distribution changelogs are used for verification instead. Treat any specific line-level patch claims as vendor-reported unless the commit diff is retrieved directly from a trusted authoritative source.

---

Affected kernels and distributions​

• Vendor trackers indicate the issue was introduced in earlier kernel releases and fixed in various downstream trees. Debian’s security tracker lists several vulnerable versions for older stable releases (5.10, 6.1) and shows fixed versions in later trees (e.g., fixes present around kernel 6.4.x and 6.12/6.17 in newer distributions).
• OSV, NVD, and multiple distro advisories published the CVE details on or around the same calendar timeframe and classified the flaw as a medium severity local race leading to a kernel crash (availability impact). Amazon’s ALAS entry shows a CVSS v3 score consistent with a medium severity assessment.
• Because f2fs is optional and not used by every Linux installation, the concrete exposure depends on whether systems mount f2fs filesystems and whether they accept remount requests that toggle the relevant options. Embedded systems, Android devices using f2fs, or servers using f2fs on SSDs are conditional exposure points.

Practical takeaway: any system running a Linux kernel with f2fs support should verify whether kernel packages include the stable fix. Distribution security advisories and kernel package changelogs are the right place to check for backports.

---

Fixes and patches​

The kernel f2fs maintainers addressed the issue by changing the remount handling to avoid resetting mount options that are unchangeable at remount time, or by making the remount atomic with respect to option visibility so that other threads cannot observe inconsistent option states. The fix was proposed as a patch against the f2fs tree and referenced in stable/linus git commit lists and vendor advisories.
Two practical facts to keep in mind:

• Kernel stable trees and distribution maintainers backported fixes differently. Some distros issued packages that include the patched kernel; others may have backported only parts of the patch or required later stable releases for a clean application. One public mirror thread documents a failed attempt to apply a specific patch to a 6.1 stable tree — an example of real-world backport complexity.
• Because remount logic interacts with mount API changes (the kernel has been migrating filesystems to the new mount API over recent versions), patch placement and semantics vary by kernel series. If your distro explicitly lists the CVE in its advisory, that is the best guide for whether your installed kernel is fixed.

If a vendor advisory lists a patch or fixed kernel version, follow that guidance. If you build kernels yourself from source, apply the upstream f2fs patch from the f2fs maintainer branch and rebuild — but follow stable-tree practices and test on a non-production system.

---

Exploitability and threat model​

• Vector: Local (attacker requires ability to trigger a remount and concurrently perform filesystem operations such as fallocate). The bug is not a remote code execution vector by itself; the primary impact is availability (kernel crash and potential service disruption).
• Privileges: An unprivileged local user with the ability to mount/remount or to trigger fallocate on files on the target f2fs mount may trigger the condition in some setups. On many systems, remount requires CAP_SYS_ADMIN or root; however, multi-user setups or containerized environments where capabilities are granted can change that risk calculus.
• Exploit complexity: Moderate — requires race timing (remount + concurrent filesystem operation). Fuzzers like syzbot found the issue, demonstrating that automated fuzzing can reach the triggering interleaving. Real-world exploitation would require carefully timed operations but is not impossible under the right conditions.
• Observed impact: Kernel oops / general protection fault (crash); no public reports of privilege escalation tied to this CVE at the time of public advisories — the principal concern is denial-of-service and system instability.

Overall, the CVE represents a local denial-of-service vector rather than an elevation-of-privilege vulnerability. That classification shapes remediation priorities: high-availability setups and systems that host untrusted users should prioritize patching.

---

Mitigation and practical recommendations​

If you manage Linux systems that run f2fs, follow these concrete steps:

• Inventory: Determine whether any systems in your fleet mount f2fs filesystems. Use mount, /proc/filesystems, or system configuration management tooling to locate f2fs uses.
• Verify kernel packages: Check your distribution’s security advisory for CVE-2023-53447 and the kernel package changelog for the fixed kernel version. If the distro provides an updated kernel package that includes the f2fs fix, schedule immediate updates for affected hosts.
• Workarounds where patching is impractical:
• Avoid remount operations that change the mount options that f2fs parses, particularly on production f2fs mounts, until an updated kernel is deployed.
• Restrict who can perform remounts (CAP_SYS_ADMIN) and avoid granting that capability in shared or multi-tenant contexts.
• On systems with untrusted users, consider mounting f2fs with options that minimize the need for runtime remounts and ensure user capabilities are constrained.
• For embedded or custom-kernel environments: backport the upstream patch from the f2fs maintainer branch and test thoroughly. Because stable-tree backports occasionally fail to apply cleanly across kernel versions, treat backports as code changes that require QA and runtime testing. One public stable-mirror thread shows a failed patch application attempt as evidence that backports can be non-trivial.
• Monitor: Watch your distribution’s security tracker and kernel mailing lists for follow-up fixes or errata; some vendors add additional hardening around mount option handling in subsequent releases.

---

Operational impact and risk assessment​

• Production servers: If you run f2fs on production servers, the immediate risk is service interruption if an attacker or a benign admin operation triggers the race. For multi-user systems or systems exposing shell access to many users, the risk increases because multiple actors may inadvertently create the triggering interleaving.
• Embedded devices and Android: Many Android builds use f2fs for userdata partitions. For devices that allow runtime remounts or file operations from multiple concurrent processes, the issue is relevant — patching or vendor firmware updates are the recommended route.
• Cloud and container platforms: Containers typically do not give direct control over host remounts, but privileged containers with CAP_SYS_ADMIN could initiate remounts and trigger the race. Consider reducing granted capabilities for containers and verifying host kernel status.

Mitigation priority should be driven by exposure: systems with untrusted local users, containers with elevated capabilities, or devices where firmware/kernel updates are easily distributed should prioritize fixing.

---

Strengths and limitations of the fix​

• Strengths:
• The fix addresses the root cause (the transient resetting of unchangeable options during remount), improving correctness across concurrency boundaries.
• Upstream maintainers and distributions have responded with patches or package updates, reducing window of exposure for patched installations.
• Limitations and risks:
• Backport complexity: stable-tree backports are sometimes non-trivial, and distribution-level patches may differ. Administrators who apply custom backports must test carefully. Public thread evidence shows at least one failed apply attempt when backporting the patch to an older stable tree.
• Partial mitigations: simply avoiding remounts reduces risk but does not resolve the underlying race if other filesystem code paths change. The clean fix needs to be in the f2fs remount logic upstream and in downstream kernels.

Cautionary note: any specific claims about the exact lines changed in the kernel commit should be verified against the raw commit diff in kernel.org or the vendor’s patch bundle. During research, some kernel.org commit pages were not retrievable (HTTP 403 returned), so rely on vendor advisories and mailing-list archives for the authoritative narrative if the raw commit cannot be fetched. Flag those raw diff claims as contingent until the commit is inspected directly.

---

How to test whether you’re still vulnerable​

• Check kernel version: consult your distribution’s advisory to see the list of patched kernel versions. If your running kernel is older than the vendor’s fixed version, assume vulnerable until patched.
• Reproduce test (advanced / lab only): in a controlled test environment, try to create the race by issuing a remount while concurrently running work that triggers f2fs fallocate on the same mount. Because the race depends on interleaving, it may be non-deterministic and require repeated attempts or fuzzing tools. Use syzkaller/syzbot-style stress tests only in non-production environments. The syzbot report that discovered the issue is the basis for the initial disclosure.
• Monitoring: look for kernel oopses with the call trace patterns noted in advisories (the __lock_acquire -> raw_write_lock -> drop_extent_tree stack involving f2fs extent-cache code). If such oopses appear under remount/fallocate activity, treat them as indicators of this vulnerability or related races.

---

Final verdict: why this matters to WindowsForum readers who manage Linux systems​

Although WindowsForum’s audience focuses on Windows, many environments are mixed or run Linux guests, containers, or storage nodes that mount f2fs. CVE-2023-53447 demonstrates a classic concurrency pitfall in filesystem code: small implementation decisions (resetting options to defaults) can create micro-windows that fuzzers and determined attackers can exploit to cause crashes. The practical lesson is to keep kernels patched, to avoid exposing unnecessary capabilities to untrusted processes, and to treat filesystem remounts and mount-option changes as operations that must be carefully synchronized.
For administrators, the steps are straightforward: identify f2fs usage, confirm kernel packages include the f2fs remount fix from upstream or the vendor, apply updates, and restrict remount capabilities where feasible. For embedded vendors or teams building custom kernels, the patch must be applied and tested thoroughly, because backporting can be delicate and may fail to apply cleanly across kernel branches.
CVE-2023-53447 is not a remote, unauthenticated RCE — it’s a local race leading to denial-of-service — but it is a concrete reminder that filesystem correctness in the presence of concurrency remains a subtle and critical part of kernel security engineering.

---

Conclusion
CVE-2023-53447 exposed a small but consequential race in f2fs remount handling that can produce a kernel oops by creating an inconsistent view of mount options during a remount. The fix avoids resetting unchangeable options at remount time (or otherwise synchronizes option visibility), and vendors have published patches or fixed kernel packages. Systems using f2fs should be inventoried, patched as soon as vendor updates are available, and operational practices adjusted to limit remount exposures and unnecessary privileges. Where direct validation of the upstream commit is required, consult your distribution’s advisory and the f2fs maintainer’s tree; if the upstream commit page cannot be fetched, rely on vendor advisories and mailing-list archives while flagging line-by-line patch claims as contingent until a raw diff is reviewed.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center