Linux Kernel bis 6.12.108/6.18.49/7.2.3 Overlayfs backing_file_open f_path Information Disclosure

CVSS Meta Temp ScoreAktueller Exploitpreis (≈)CTI Interest Score
4.1$0-$5k0.00+

Zusammenfassunginfo

Eine problematische Schwachstelle wurde in Linux Kernel bis 6.12.108/6.18.49/7.2.3 entdeckt. Hierbei geht es um die Funktion backing_file_open der Komponente Overlayfs. Durch Manipulation des Arguments f_path mit unbekannten Daten kann eine Information Disclosure-Schwachstelle ausgenutzt werden. Die Identifikation der Schwachstelle findet als CVE-2026-89768 statt. Die Umsetzung des Angriffs kann dabei über das Netzwerk erfolgen. Es steht kein Exploit zur Verfügung. Es wird geraten, die betroffene Komponente zu aktualisieren.

Detailsinfo

In Linux Kernel bis 6.12.108/6.18.49/7.2.3 wurde eine Schwachstelle gefunden. Sie wurde als problematisch eingestuft. Das betrifft die Funktion backing_file_open der Komponente Overlayfs. Dank Manipulation des Arguments f_path mit einer unbekannten Eingabe kann eine Information Disclosure-Schwachstelle ausgenutzt werden. CWE definiert das Problem als CWE-200. Dies hat Einfluss auf die Vertraulichkeit. Die Zusammenfassung von CVE lautet:

In the Linux kernel, the following vulnerability has been resolved: fs: fix user path of nested backing files backing_file_open() derives the path to be stored in the new backing file from user_file->f_path. This is incorrect when user_file itself is a backing file, which is the case for nested stacking filesystems, e.g. overlayfs mounts where the lowerdir of one overlayfs is the merged directory of another. Since commit def3ae83da02 ("fs: store real path instead of fake path in backing file f_path") the f_path of a backing file holds the real path of the intermediate layer, not the path that the user opened. Commit 924577e4f6ca ("ovl: Fix nested backing file paths") fixed this for such configurations by passing file_user_path() from ovl_open_realfile(). However, commit 6af36aeb147a ("lsm: add backing_file LSM hooks") changed the first argument of backing_file_open() from the user path back to the user file and derived the path from user_file->f_path again, silently re-introducing the problem. As a result, files mapped through a nested overlayfs show the wrong path in /proc/<pid>/maps and in perf/ftrace mmap records. For example, with two nested overlayfs mounts: mkdir -p /ovl/{lower,upper,work,merged} /ovl/nested echo hello > /ovl/lower/foo mount -t overlay overlay \ -o lowerdir=/ovl/lower,upperdir=/ovl/upper,workdir=/ovl/work \ /ovl/merged # at least two lowerdirs are needed when upperdir is nonexistent mount -t overlay overlay \ -o lowerdir=/ovl/merged:/ovl/lower /ovl/nested mapping /ovl/nested/foo shows a disconnected path instead of the user path: # readlink /proc/self/fd/3 /ovl/nested/foo # grep foo /proc/self/maps 7f6e2c100000-7f6e2c101000 r--s 00000000 00:24 15813027 /foo The bogus path is derived from the f_path of the intermediate backing file, whose mount is a private clone that d_path() cannot resolve. Fix this by using file_user_path(), which returns the outermost user-visible path for backing files and falls back to &user_file->f_path for regular files. This restores the behavior of commit 924577e4f6ca ("ovl: Fix nested backing file paths") for overlayfs and also fixes the same problem for the other backing_file_open() callers, fuse passthrough and erofs ishare, when their user file is itself a backing file. backing_tmpfile_open() has the same pattern but is not affected: it is only called by ovl_create_tmpfile() for the upper layer, and another overlayfs is rejected as upperdir by the DCACHE_OP_REAL check in ovl_mount_dir_check(), so its user_file can never be a backing file.

Bereitgestellt wird das Advisory unter git.kernel.org. Die Verwundbarkeit wird seit dem 11.09.2026 als CVE-2026-89768 geführt. Sie ist leicht auszunutzen. Der Angriff kann über das Netzwerk angegangen werden. Technische Details sind bekannt, ein verfügbarer Exploit hingegen nicht. Ein Exploit zur Schwachstelle wird momentan etwa USD $0-$5k kosten (Preisberechnung vom 11.09.2026). Als Angriffstechnik weist das MITRE ATT&CK Projekt die ID T1592 aus.

Ein Aktualisieren auf die Version 6.12.109, 6.18.50, 7.2.4 oder 7.3-rc1 vermag dieses Problem zu lösen. Die Schwachstelle lässt sich auch durch das Einspielen des Patches 88c927a63dc717b6d46b20fe13ea713916e49089/c03114634d342648bd34910aa8fb88007e92cc3c/a35cc21355734e1acb89973d9be90ca8e4c3ed2f/f2381b546e7e6a35c9fcee0d0ccb6c042a9aeb5d lösen. Als bestmögliche Massnahme wird das Upgrade auf eine neue Version empfohlen.

Several companies clearly confirm that VulDB is the primary source for best 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: 4.3
VulDB Meta Temp Score: 4.1

VulDB Base Score: 4.3
VulDB Temp Score: 4.1
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: Information Disclosure
CWE: CWE-200 / CWE-284 / CWE-266
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.12.109/6.18.50/7.2.4/7.3-rc1
Patch: 88c927a63dc717b6d46b20fe13ea713916e49089/c03114634d342648bd34910aa8fb88007e92cc3c/a35cc21355734e1acb89973d9be90ca8e4c3ed2f/f2381b546e7e6a35c9fcee0d0ccb6c042a9aeb5d

Timelineinfo

11.09.2026 Advisory veröffentlicht
11.09.2026 +0 Tage CVE zugewiesen
11.09.2026 +0 Tage VulDB Eintrag erstellt
11.09.2026 +0 Tage VulDB Eintrag letzte Aktualisierung

Quelleninfo

Hersteller: kernel.org

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

CVE: CVE-2026-89768 (🔒)
GCVE (CVE): GCVE-0-2026-89768
GCVE (VulDB): GCVE-100-402601

Eintraginfo

Erstellt: 11.09.2026 22:53
Anpassungen: 11.09.2026 22:53 (60)
Komplett: 🔍
Cache ID: 216::103

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Diskussion

Bisher keine Kommentare. Sprachen: de + en.

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

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!