CVE-2023-54099: fs: Protect reconfiguration of sb read-write from racing writes
In the Linux kernel, the following vulnerability has been resolved:
fs: Protect reconfiguration of sb read-write from racing writes
The reconfigure / remount code takes a lot of effort to protect
filesystem's reconfiguration code from racing writes on remounting
read-only. However during remounting read-only filesystem to read-write
mode userspace writes can start immediately once we clear SB_RDONLY
flag. This is inconvenient for example for ext4 because we need to do
some writes to the filesystem (such as preparation of quota files)
before we can take userspace writes so we are clearing SB_RDONLY flag
before we are fully ready to accept userpace writes and syzbot has found
a way to exploit this [1]. Also as far as I'm reading the code
the filesystem remount code was protected from racing writes in the
legacy mount path by the mount's MNT_READONLY flag so this is relatively
new problem. It is actually fairly easy to protect remount read-write
from racing writes using sb->s_readonly_remount flag so let's just do
that instead of having to workaround these races in the filesystem code.
[1] https://lore.kernel.org/all/00000000000006a0df05f6667499@google.com/T/
Security readout for executives and security teams
Plain-English summary
CVE-2023-54099 is a Linux kernel filesystem race during remount from read-only to read-write. The kernel could allow userspace writes before the filesystem finished internal preparation. The public record does not provide CVSS, impact class, or confirmed real-world exploitation, so business urgency depends on kernel exposure and vendor advisories.
Executive priority
Track as a kernel maintenance item until vendor severity is clear. Prioritize patching internet-facing multi-user, hosting, and workload-isolation platforms before low-risk single-purpose systems.
Technical view
The issue is in Linux VFS remount/reconfiguration handling. Clearing SB_RDONLY can let userspace writes race with filesystem preparation, including ext4 quota setup. The resolved change uses sb->s_readonly_remount protection to block racing writes until remount read-write handling is ready.
Likely exposure
Systems running affected Linux kernel versions or distro kernels carrying the vulnerable filesystem remount logic may be exposed. Exact exposure requires mapping deployed kernels to vendor-fixed builds.
Exploitation context
The source states syzbot found a way to exploit the race. There is no KEV listing and no cited source confirming active exploitation in the wild.
Researcher notes
Evidence supports a VFS remount read-write race fixed in stable kernel commits. Public data does not establish CVSS, affected distro packages, privilege requirements, or impact beyond the described racing writes condition.
Mitigation direction
Check Linux distribution advisories for CVE-2023-54099 fixed kernel packages.
Upgrade affected kernels to vendor-supported builds containing the referenced stable fixes.
Prioritize systems allowing untrusted users or workloads to trigger mounts or filesystem writes.
Restrict unnecessary mount/remount privileges where operationally feasible.
Validation and detection
Inventory Linux kernel versions across servers, containers hosts, and appliances.
Map deployed distro kernel packages to vendor advisories for CVE-2023-54099.
Confirm whether referenced stable kernel commits are included in your kernel build.
Review logs and configuration for unexpected remount activity on shared systems.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2023-54099 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
7Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Dec 24, 2025, 13:06 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.