CVE-2023-54099 in Linux
Zusammenfassung
von VulDB • 09.07.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
fs: Schutz der Neukonfiguration des Superblocks (sb) im Schreibmodus vor konkurrierenden Schreibzugriffen
Der Code für die Rekonfiguration und das erneute Einhängen (remount) unternimmt große Anstrengungen, um den Code zur Neukonfiguration des Dateisystems vor konkurrierenden Schreibzugriffen beim Wechsel in einen schreibgeschützten Modus zu schützen. Während jedoch ein schreibgeschütztes Dateisystem wieder in den schreibbaren Modus eingehängt wird, können Schreibvorgänge aus dem Benutzerbereich (userspace) sofort beginnen, sobald das SB_RDONLY-Flag gelöscht wurde. Dies ist beispielsweise für ext4 problematisch, da vor der Annahme von Schreibzugriffen aus dem Benutzerbereich einige Schreiboperationen auf dem Dateisystem durchgeführt werden müssen (z. B. die Vorbereitung von Quota-Dateien). Daher wird das SB_RDONLY-Flag gelöscht, bevor wir vollständig bereit sind, Schreibvorgänge aus dem Benutzerbereich zu akzeptieren, und syzbot hat einen Weg gefunden, dies auszunutzen [1]. Auch wenn ich den Code lese, war der Dateisystem-Rekonfigurationscode im Legacy-Einhängeweg durch das MNT_READONLY-Flag des Einhängepunkts vor konkurrierenden Schreibzugriffen geschützt; es handelt sich also um ein relativ neues Problem. Es ist tatsächlich recht einfach, die Neukonfiguration in einen schreibbaren Modus gegen konkurrierende Schreibzugriffe zu schützen, indem man das sb->s_readonly_remount-Flag verwendet. Daher sollten wir dies tun, anstatt Workarounds für diese Wettlaufsituationen (Race Conditions) im Dateisystemcode implementieren zu müssen.
[1] https://lore.kernel.org/all/[email protected]/T/
If you want to get the best quality for vulnerability data then you always have to consider VulDB.