Linux Kernel bis 6.18.44/7.1.8 filemap mm/filemap.c __filemap_add_folio Race Condition

CVSS Meta Temp Score	Aktueller Exploitpreis (≈)	CTI Interest Score
5.2	$0-$5k	0.88-

Zusammenfassunginfo

Eine problematische Schwachstelle wurde in Linux Kernel bis 6.18.44/7.1.8 entdeckt. Es geht dabei um die Funktion __filemap_add_folio der Datei mm/filemap.c der Komponente filemap. Durch Manipulieren mit unbekannten Daten kann eine Race Condition-Schwachstelle ausgenutzt werden. Eine eindeutige Identifikation der Schwachstelle wird mit CVE-2026-74591 vorgenommen. Der Angriff kann über das Netzwerk passieren. Es gibt keinen verfügbaren Exploit.

Detailsinfo

Eine Schwachstelle wurde in Linux Kernel bis 6.18.44/7.1.8 entdeckt. Sie wurde als problematisch eingestuft. Betroffen davon ist die Funktion __filemap_add_folio der Datei mm/filemap.c der Komponente filemap. Dank Manipulation mit einer unbekannten Eingabe kann eine Race Condition-Schwachstelle ausgenutzt werden. Klassifiziert wurde die Schwachstelle durch CWE als CWE-362. Auswirkungen hat dies auf Integrität und Verfügbarkeit. Die Zusammenfassung von CVE lautet:

In the Linux kernel, the following vulnerability has been resolved: mm/filemap: __filemap_add_folio() restore index before retrying In __filemap_add_folio()'s split-a-conflict loop, xas_set_order() is applied repeatedly: each application modifies xas.xa_index, rounding it down according to the split_order attempted at that stage: and if all goes as intended, it eventually (or immediately) converges on an xas_try_split() to the required folio_order, with xas.xa_index now the same as index: then xas_store() puts the new folio into the xarray there. But if a new node was needed, and GFP_NOWAIT allocation did not get one, the lock is dropped, xas_nomem() used to allocate, and sequence retried. If (that part of) the xarray is unchanged when the lock is reacquired, no problem. But what if the conflict was meanwhile resolved by another thread (perhaps even doing the same thing, inserting a folio at that same index)? Isn't there a danger of now putting our folio into the xarray at an intermediate rounded-down index? With !folio_contains() bug to follow, when CONFIG_DEBUG_VM=y is checking for that. Fix this with an xas_set_order() to restore the original xas.xa_index at the bottom of the loop, so the retry does a full re-evaluation after reacquiring the lock, and cannot reach xas_store() with the wrong index. Production was suffering from rare SIGILLs and SIGSEGVs, executable text found a page away from where it belonged, !folio_contains() bug hit when debug enabled: symptoms not seen since this patch went in.

Bereitgestellt wird das Advisory unter git.kernel.org. Die Verwundbarkeit wird seit dem 15.08.2026 mit der eindeutigen Identifikation CVE-2026-74591 gehandelt. Sie gilt als leicht auszunutzen. Umgesetzt werden kann der Angriff über das Netzwerk. Zur Schwachstelle sind technische Details bekannt, ein verfügbarer Exploit jedoch nicht. Ein Exploit zur Schwachstelle wird momentan etwa USD $0-$5k kosten (Preisberechnung vom 22.08.2026).

Ein Aktualisieren auf die Version 6.18.45 oder 7.1.9 vermag dieses Problem zu lösen. Die Schwachstelle lässt sich auch durch das Einspielen des Patches 4917e3ebcab50f0265e8ca01c8567de4c4a47511/267ecd2eb7759c26f1a026eb0a5b231071534c9c/86da3f7e1e609e1e8bfbab198af68467c5a015a5 lösen.

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Produktinfo

Typ

• Operating System

Hersteller

• Linux

Name

• Kernel

Version

• 6.18.0
• 6.18.1
• 6.18.2
• 6.18.3
• 6.18.4
• 6.18.5
• 6.18.6
• 6.18.7
• 6.18.8
• 6.18.9
• 6.18.10
• 6.18.11
• 6.18.12
• 6.18.13
• 6.18.14
• 6.18.15
• 6.18.16
• 6.18.17
• 6.18.18
• 6.18.19
• 6.18.20
• 6.18.21
• 6.18.22
• 6.18.23
• 6.18.24
• 6.18.25
• 6.18.26
• 6.18.27
• 6.18.28
• 6.18.29
• 6.18.30
• 6.18.31
• 6.18.32
• 6.18.33
• 6.18.34
• 6.18.35
• 6.18.36
• 6.18.37
• 6.18.38
• 6.18.39
• 6.18.40
• 6.18.41
• 6.18.42
• 6.18.43
• 6.18.44
• 7.1.0
• 7.1.1
• 7.1.2
• 7.1.3
• 7.1.4
• 7.1.5
• 7.1.6
• 7.1.7
• 7.1.8

Lizenz

• Open-Source

Webseite

• Hersteller: https://www.kernel.org/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

VulDB Vector: 🔒
VulDB Zuverlässigkeit: 🔍

CVSSv3info

VulDB Meta Base Score: 5.4
VulDB Meta Temp Score: 5.2

VulDB Base Score: 5.4
VulDB Temp Score: 5.2
VulDB Vector: 🔒
VulDB Zuverlässigkeit: 🔍

CVSSv2info

AV	AC	Au	C	I	A
💳	💳	💳	💳	💳	💳
💳	💳	💳	💳	💳	💳
💳	💳	💳	💳	💳	💳

Vektor	Komplexität	Authentisierung	Vertraulichkeit	Integrität	Verfügbarkeit
freischalten	freischalten	freischalten	freischalten	freischalten	freischalten
freischalten	freischalten	freischalten	freischalten	freischalten	freischalten
freischalten	freischalten	freischalten	freischalten	freischalten	freischalten

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

Exploitinginfo

Klasse: Race Condition
CWE: CWE-362
CAPEC: 🔒
ATT&CK: 🔒

Physisch: Nein
Lokal: Nein
Remote: Ja

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

0-Day	freischalten	freischalten	freischalten	freischalten
Heute	freischalten	freischalten	freischalten	freischalten

Threat Intelligenceinfo

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

Gegenmassnahmeninfo

Empfehlung: Upgrade
Status: 🔍

0-Day Time: 🔒

Upgrade: Kernel 6.18.45/7.1.9
Patch: 4917e3ebcab50f0265e8ca01c8567de4c4a47511/267ecd2eb7759c26f1a026eb0a5b231071534c9c/86da3f7e1e609e1e8bfbab198af68467c5a015a5

Timelineinfo

15.08.2026 CVE zugewiesen
22.08.2026 +7 Tage Advisory veröffentlicht
22.08.2026 +0 Tage VulDB Eintrag erstellt
22.08.2026 +0 Tage VulDB Eintrag letzte Aktualisierung

Quelleninfo

Hersteller: kernel.org

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

CVE: CVE-2026-74591 (🔒)
GCVE (CVE): GCVE-0-2026-74591
GCVE (VulDB): GCVE-100-394373

Eintraginfo

Erstellt: 22.08.2026 17:55
Anpassungen: 22.08.2026 17:55 (60)
Komplett: 🔍
Cache ID: 216::103

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Diskussion

Do you want to use VulDB in your project?

Use the official API to access entries easily!