Linux Kernel bis 7.1.4 NTFS attrib.c ntfs_mft_writepages Denial of Service

CVSS Meta Temp ScoreAktueller Exploitpreis (≈)CTI Interest Score
6.2$0-$5k1.48

Zusammenfassunginfo

Es wurde eine als kritisch klassifizierte Schwachstelle in Linux Kernel bis 7.1.4 entdeckt. Es geht hierbei um die Funktion ntfs_mft_writepages der Datei attrib.c der Komponente NTFS. Dank Manipulation mit unbekannten Daten kann eine Denial of Service-Schwachstelle ausgenutzt werden. Diese Schwachstelle trägt die Bezeichnung CVE-2026-72203. Der Angriff kann über das Netzwerk erfolgen. Es gibt keinen verfügbaren Exploit.

Detailsinfo

In Linux Kernel bis 7.1.4 wurde eine Schwachstelle entdeckt. Sie wurde als kritisch eingestuft. Dabei geht es um die Funktion ntfs_mft_writepages der Datei attrib.c der Komponente NTFS. Durch das Manipulieren mit einer unbekannten Eingabe kann eine Denial of Service-Schwachstelle ausgenutzt werden. CWE definiert das Problem als CWE-833. Mit Auswirkungen muss man rechnen für die Verfügbarkeit. CVE fasst zusammen:

In the Linux kernel, the following vulnerability has been resolved: ntfs: skip extent mft records in writeback to prevent deadlock This patch fixes the ABBA deadlock between extent_lock and extent mrec_lock triggered by xfstests generic/113, that occurs since the commit 6994acf33bae ("ntfs: use base mft_no when looking up base inode for extent record"). Path A (inode writeback): VFS writeback -> ntfs_write_inode() -> __ntfs_write_inode() -> mutex_lock(&ni->extent_lock) -> mutex_lock(&tni->mrec_lock) Path B (MFT folio writeback): VFS writeback of $MFT dirty folios -> ntfs_mft_writepages() -> ntfs_write_mft_block() -> ntfs_may_write_mft_record() -> holds one extent mrec_lock from a previous iteration -> tries to acquire another base inode extent_lock By removing all extent_lock and extent mrec_lock acquisition from the MFT folio writeback path, the ABBA lock ordering is eliminated: Path A: __ntfs_write_inode(): extent_lock -> mrec_lock Path B (removed): ntfs_write_mft_block(): mrec_lock -> extent_lock Path B is always redundant for extent records because: 1. mark_mft_record_dirty(ext_ni) does NOT dirty the MFT folio. It only sets NInoDirty(ext_ni) and marks the base VFS inode dirty via __mark_inode_dirty(I_DIRTY_DATASYNC), which triggers Path A. Therefore, normal extent modifications never create a situation where the MFT folio is dirty and Path B is not scheduled. 2. The MFT folio only gets dirtied via ntfs_mft_mark_dirty() inside ntfs_mft_record_alloc(). But all identified callers in attrib.c (ntfs_attr_add, ntfs_attr_record_move_away, ntfs_attr_make_non_resident, ntfs_attr_record_resize) follow through with mark_mft_record_dirty(), which triggers Path A to write the complete record. 3. ntfs_evict_big_inode() calls ntfs_commit_inode() before freeing extent inodes, ensuring all dirty extents are flushed via Path A before the base inode leaves the icache.

Das Advisory kann von git.kernel.org heruntergeladen werden. Eine eindeutige Identifikation der Schwachstelle wird seit dem 09.08.2026 mit CVE-2026-72203 vorgenommen. Sie gilt als leicht auszunutzen. 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 15.08.2026). Das MITRE ATT&CK Projekt deklariert die Angriffstechnik als T1499.

Ein Upgrade auf die Version 7.1.5 oder 7.2-rc1 vermag dieses Problem zu beheben. Die Schwachstelle lässt sich auch durch das Einspielen des Patches f831ab09d521898bf1dd99bf5adfd630ea1428e3/76bc14c7097ff678b2b5dbfd4fa33b46897d87ce beheben.

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: 6.5
VulDB Meta Temp Score: 6.2

VulDB Base Score: 6.5
VulDB Temp Score: 6.2
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-833 / CWE-404
CAPEC: 🔒
ATT&CK: 🔒

Physisch: Nein
Lokal: Nein
Remote: Ja

Verfügbarkeit: 🔒
Status: Nicht definiert

EPSS Score: 🔒
EPSS Percentile: 🔒

Preisentwicklung: 🔍
Aktuelle Preisschätzung: 🔒

0-Dayfreischaltenfreischaltenfreischaltenfreischalten
Heutefreischaltenfreischaltenfreischaltenfreischalten

Threat Intelligenceinfo

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

Gegenmassnahmeninfo

Empfehlung: Upgrade
Status: 🔍

0-Day Time: 🔒

Upgrade: Kernel 7.1.5/7.2-rc1
Patch: f831ab09d521898bf1dd99bf5adfd630ea1428e3/76bc14c7097ff678b2b5dbfd4fa33b46897d87ce

Timelineinfo

09.08.2026 CVE zugewiesen
15.08.2026 +6 Tage Advisory veröffentlicht
15.08.2026 +0 Tage VulDB Eintrag erstellt
15.08.2026 +0 Tage VulDB Eintrag letzte Aktualisierung

Quelleninfo

Hersteller: kernel.org

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

CVE: CVE-2026-72203 (🔒)
GCVE (CVE): GCVE-0-2026-72203
GCVE (VulDB): GCVE-100-390628

Eintraginfo

Erstellt: 15.08.2026 13:27
Anpassungen: 15.08.2026 13:27 (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.

◂ ZurückÜbersichtWeiter ▸

Do you need the next level of professionalism?

Upgrade your account now!