CVE-2023-54099

What it actually does

Race condition during filesystem remount from read-only to read-write allows userspace writes to begin immediately after clearing the SB_RDONLY flag but before the filesystem completes internal preparations such as quota file setup.

Why it matters to the business

Linux systems performing remount operations risk filesystem corruption, crashes, or instability that can interrupt services, require recovery procedures, and increase downtime until kernels are updated.

How an attack unfolds

An attacker with local access triggers a remount from read-only to read-write while issuing concurrent writes that exploit the unprotected window before the filesystem is ready, as identified in syzbot reports.

How to fix it

Update the Linux kernel to a version containing commit 0336b42456e485fda1006b5b411e7372e20fbf03 which adds protection via the s_readonly_remount flag.

How to confirm the fix worked

Confirm the running kernel includes the referenced commit, then exercise repeated remount read-write operations under concurrent write load to verify the race is closed.

Typical attack path

1. Gain local access to a Linux system
2. Initiate remount of a filesystem from read-only to read-write
3. Race writes against internal preparation steps
4. Trigger corruption, crashes, or denial of service

How to detect it

Review kernel logs and dmesg output around remount events for unexpected write errors, quota preparation failures, or crashes; correlate with process activity issuing writes during RO-to-RW transitions.

What your security team should do

• Apply the kernel fix containing commit 0336b42456e485fda1006b5b411e7372e20fbf03 as soon as possible
• Limit local unprivileged access on systems that perform frequent remounts
• Monitor kernel and filesystem logs for remount-related errors or panics