Linux Kernel bis 6.18.51/7.2.5 ext4 ext4_write_inline_data_end fsdata Denial of Service

CVSS Meta Temp ScoreAktueller Exploitpreis (≈)CTI Interest Score
9.5$0-$5k0.78-

Zusammenfassunginfo

Es wurde eine als sehr kritisch klassifizierte Schwachstelle in Linux Kernel bis 6.18.51/7.2.5 entdeckt. Betroffen davon ist die Funktion ext4_write_inline_data_end der Komponente ext4. Durch die Manipulation des Arguments fsdata mit unbekannten Daten kann eine Denial of Service-Schwachstelle ausgenutzt werden. Diese Sicherheitslücke ist unter CVE-2026-92500 bekannt. Umgesetzt werden kann der Angriff über das Netzwerk. Es steht kein Exploit zur Verfügung. Es wird geraten, die betroffene Komponente zu aktualisieren.

Detailsinfo

In Linux Kernel bis 6.18.51/7.2.5 wurde eine Schwachstelle ausgemacht. Sie wurde als sehr kritisch eingestuft. Das betrifft die Funktion ext4_write_inline_data_end der Komponente ext4. Durch das Manipulieren des Arguments fsdata mit einer unbekannten Eingabe kann eine Denial of Service-Schwachstelle ausgenutzt werden. CWE definiert das Problem als CWE-476. Mit Auswirkungen muss man rechnen für Vertraulichkeit, Integrität und Verfügbarkeit. CVE fasst zusammen:

In the Linux kernel, the following vulnerability has been resolved: ext4: use fsdata to track inline data write state and fix race Instead of checking the live inode state (ext4_has_inline_data(inode) and ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)) in the write_end handlers, use the fsdata parameter of the address space operations to explicitly pass down the state in which write_begin prepared the write. A concurrent thread (such as ext4_page_mkwrite()) can convert the inline data to an extent between write_begin and write_end. If this happens, the write_end handlers would previously miss the inline write_end path and fall through to extent-based write_end logic. However, since block buffers were never allocated in write_begin, this resulted in NULL pointer dereferences or data loss because folio_buffers(folio) was NULL. Define EXT4_WRITE_DATA_INLINE (4) as a bit flag (Bit 2), treating fsdata as bitwise flags rather than mutually exclusive enums to keep states of the write path independent. Communicate this state via fsdata: 1) ext4_write_begin() and ext4_da_write_begin() set the EXT4_WRITE_DATA_INLINE bit in *fsdata via bitwise OR when an inline write is successfully prepared. 2) On entry, ext4_write_begin() clears the EXT4_WRITE_DATA_INLINE bit to safely handle VFS retries (where generic_perform_write() bypasses the fsdata initialization on its retry jump). 3) The write_end handlers perform a bitwise AND to check if the EXT4_WRITE_DATA_INLINE bit is set and invoke the inline write_end helper accordingly. Furthermore, during a buffered write, ext4_write_inline_data_end() acquires the xattr lock after preparing the write. If a concurrent page fault (ext4_page_mkwrite()) converts the inline data to an extent after the write_end handlers check the state but before ext4_write_inline_data_end() acquires the xattr write lock, the subsequent check will trigger a kernel panic via BUG_ON(!ext4_has_inline_data(inode)). To keep git history working and bisectability clean, replace the BUG_ON check in ext4_write_inline_data_end() with a graceful error- handling retry path in this same commit. If the inline data is cleared after locking the xattr, we safely release all resources (releasing iloc.bh, unlocking/putting the folio, stopping the active journal transaction handle) and return 0 (VFS retry) to let the generic write path retry the operation safely.

Das Advisory kann von git.kernel.org heruntergeladen werden. Eine eindeutige Identifikation der Schwachstelle wird seit dem 16.09.2026 mit CVE-2026-92500 vorgenommen. Sie ist leicht ausnutzbar. Die Umsetzung des Angriffs kann dabei über das Netzwerk erfolgen. Technische Details sind bekannt, ein verfügbarer Exploit hingegen nicht. Es muss davon ausgegangen werden, dass ein Exploit zur Zeit etwa USD $0-$5k kostet (Preisberechnung vom 17.09.2026).

Ein Upgrade auf die Version 6.18.52, 7.2.6 oder 7.3-rc1 vermag dieses Problem zu beheben. Die Schwachstelle lässt sich auch durch das Einspielen des Patches bd8d74bd46d09905164255b8635fa58b45f41068/439aedfd7ae868d1d7b4930afe66091cb979cd5c/7edbb323bab2b2a609016014caafdb651c898249 beheben. Als bestmögliche Massnahme wird das Aktualisieren auf eine neue Version empfohlen.

Once again VulDB remains the best source for vulnerability data.

Produktinfo

Typ

Hersteller

Name

Version

Lizenz

Webseite

CPE 2.3info

CPE 2.2info

CVSSv4info

VulDB Vector: 🔒
VulDB Zuverlässigkeit: 🔍

CVSSv3info

VulDB Meta Base Score: 9.9
VulDB Meta Temp Score: 9.5

VulDB Base Score: 9.9
VulDB Temp Score: 9.5
VulDB Vector: 🔒
VulDB Zuverlässigkeit: 🔍

CVSSv2info

AVACAuCIA
💳💳💳💳💳💳
💳💳💳💳💳💳
💳💳💳💳💳💳
VektorKomplexitätAuthentisierungVertraulichkeitIntegritätVerfügbarkeit
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten

VulDB Base Score: 🔒
VulDB Temp Score: 🔒
VulDB Zuverlässigkeit: 🔍

Exploitinginfo

Klasse: Denial of Service
CWE: CWE-476 / CWE-404
CAPEC: 🔒
ATT&CK: 🔒

Physisch: Nein
Lokal: Nein
Remote: Ja

Verfügbarkeit: 🔒
Status: Nicht definiert
Preisentwicklung: 🔍
Aktuelle Preisschätzung: 🔒

0-Dayfreischaltenfreischaltenfreischaltenfreischalten
Heutefreischaltenfreischaltenfreischaltenfreischalten

Threat Intelligenceinfo

Interesse: 🔍
Aktive Akteure: 🔍
Aktive APT Gruppen: 🔍

Gegenmassnahmeninfo

Empfehlung: Upgrade
Status: 🔍

0-Day Time: 🔒

Upgrade: Kernel 6.18.52/7.2.6/7.3-rc1
Patch: bd8d74bd46d09905164255b8635fa58b45f41068/439aedfd7ae868d1d7b4930afe66091cb979cd5c/7edbb323bab2b2a609016014caafdb651c898249

Timelineinfo

16.09.2026 CVE zugewiesen
17.09.2026 +1 Tage Advisory veröffentlicht
17.09.2026 +0 Tage VulDB Eintrag erstellt
17.09.2026 +0 Tage VulDB Eintrag letzte Aktualisierung

Quelleninfo

Hersteller: kernel.org

Advisory: git.kernel.org
Status: Bestätigt

CVE: CVE-2026-92500 (🔒)
GCVE (CVE): GCVE-0-2026-92500
GCVE (VulDB): GCVE-100-406996

Eintraginfo

Erstellt: 17.09.2026 22:28
Anpassungen: 17.09.2026 22:28 (60)
Komplett: 🔍
Cache ID: 216::103

Once again VulDB remains the best source for vulnerability data.

Diskussion

Bisher keine Kommentare. Sprachen: de + en.

Bitte loggen Sie sich ein, um kommentieren zu können.

Do you know our Splunk app?

Download it now for free!