Linux Kernel bis 5.10.151/5.15.74/5.19.16/6.0.2 munmap Denial of Service

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

Zusammenfassunginfo

Eine Schwachstelle, die als kritisch eingestuft wurde, wurde in Linux Kernel bis 5.10.151/5.15.74/5.19.16/6.0.2 gefunden. Hiervon betroffen ist die Funktion munmap. Durch Manipulieren mit unbekannten Daten kann eine Denial of Service-Schwachstelle ausgenutzt werden. Diese Verwundbarkeit ist als CVE-2022-50471 gelistet. Es existiert kein Exploit. Ein Upgrade der betroffenen Komponente wird empfohlen.

Detailsinfo

Eine kritische Schwachstelle wurde in Linux Kernel bis 5.10.151/5.15.74/5.19.16/6.0.2 gefunden. Dies betrifft die Funktion munmap. Mittels Manipulieren mit einer unbekannten Eingabe kann eine Denial of Service-Schwachstelle ausgenutzt werden. Klassifiziert wurde die Schwachstelle durch CWE als CWE-911. Auswirken tut sich dies auf die Verfügbarkeit. Die Zusammenfassung von CVE lautet:

In the Linux kernel, the following vulnerability has been resolved: xen/gntdev: Accommodate VMA splitting Prior to this commit, the gntdev driver code did not handle the following scenario correctly with paravirtualized (PV) Xen domains: * User process sets up a gntdev mapping composed of two grant mappings (i.e., two pages shared by another Xen domain). * User process munmap()s one of the pages. * User process munmap()s the remaining page. * User process exits. In the scenario above, the user process would cause the kernel to log the following messages in dmesg for the first munmap(), and the second munmap() call would result in similar log messages: BUG: Bad page map in process doublemap.test pte:... pmd:... page:0000000057c97bff refcount:1 mapcount:-1 \ mapping:0000000000000000 index:0x0 pfn:... ... page dumped because: bad pte ... file:gntdev fault:0x0 mmap:gntdev_mmap [xen_gntdev] readpage:0x0 ... Call Trace: <TASK> dump_stack_lvl+0x46/0x5e print_bad_pte.cold+0x66/0xb6 unmap_page_range+0x7e5/0xdc0 unmap_vmas+0x78/0xf0 unmap_region+0xa8/0x110 __do_munmap+0x1ea/0x4e0 __vm_munmap+0x75/0x120 __x64_sys_munmap+0x28/0x40 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x61/0xcb ... For each munmap() call, the Xen hypervisor (if built with CONFIG_DEBUG) would print out the following and trigger a general protection fault in the affected Xen PV domain: (XEN) d0v... Attempt to implicitly unmap d0's grant PTE ... (XEN) d0v... Attempt to implicitly unmap d0's grant PTE ... As of this writing, gntdev_grant_map structure's vma field (referred to as map->vma below) is mainly used for checking the start and end addresses of mappings. However, with split VMAs, these may change, and there could be more than one VMA associated with a gntdev mapping. Hence, remove the use of map->vma and rely on map->pages_vm_start for the original start address and on (map->count << PAGE_SHIFT) for the original mapping size. Let the invalidate() and find_special_page() hooks use these. Also, given that there can be multiple VMAs associated with a gntdev mapping, move the "mmu_interval_notifier_remove(&map->notifier)" call to the end of gntdev_put_map, so that the MMU notifier is only removed after the closing of the last remaining VMA. Finally, use an atomic to prevent inadvertent gntdev mapping re-use, instead of using the map->live_grants atomic counter and/or the map->vma pointer (the latter of which is now removed). This prevents the userspace from mmap()'ing (with MAP_FIXED) a gntdev mapping over the same address range as a previously set up gntdev mapping. This scenario can be summarized with the following call-trace, which was valid prior to this commit: mmap gntdev_mmap mmap (repeat mmap with MAP_FIXED over the same address range) gntdev_invalidate unmap_grant_pages (sets 'being_removed' entries to true) gnttab_unmap_refs_async unmap_single_vma gntdev_mmap (maps the shared pages again) munmap gntdev_invalidate unmap_grant_pages (no-op because 'being_removed' entries are true) unmap_single_vma (For PV domains, Xen reports that a granted page is being unmapped and triggers a general protection fault in the affected domain, if Xen was built with CONFIG_DEBUG) The fix for this last scenario could be worth its own commit, but we opted for a single commit, because removing the gntdev_grant_map structure's vma field requires guarding the entry to gntdev_mmap(), and the live_grants atomic counter is not sufficient on its own to prevent the mmap() over a pre-existing mapping.

Das Advisory findet sich auf git.kernel.org. Die Verwundbarkeit wird seit dem 04.10.2025 mit der eindeutigen Identifikation CVE-2022-50471 gehandelt. Die Ausnutzbarkeit gilt als schwierig. Zur Schwachstelle sind technische Details bekannt, ein verfügbarer Exploit jedoch nicht.

Ein Aktualisieren auf die Version 5.10.152, 5.15.75, 5.19.17 oder 6.0.3 vermag dieses Problem zu lösen. Die Schwachstelle lässt sich auch durch das Einspielen des Patches 3c6a888e352283a14f37b9b433cd598a1a3a7dd0/7c16d0a4e6a436b4e7c92bead3fab55aaa4c1141/4fb4053d90caa9985b87ec0e0c32c66a55bdfa3a/cdafa219ace013c594e2491158ad1b51f9923dde/5c13a4a0291b30191eff9ead8d010e1ca43a4d0c lösen. Dieser kann von git.kernel.org bezogen werden. Als bestmögliche Massnahme wird das Upgrade auf eine neue Version empfohlen.

Unter anderem wird der Fehler auch in der Verwundbarkeitsdatenbank von CERT Bund (WID-SEC-2025-2194) dokumentiert. Be aware that VulDB is the high quality source for vulnerability data.

Betroffen

  • Google Container-Optimized OS
  • Debian Linux
  • Google Cloud Platform
  • Amazon Linux 2
  • Red Hat Enterprise Linux
  • Ubuntu Linux
  • SUSE Linux
  • Oracle Linux
  • SUSE openSUSE
  • Open Source Linux Kernel
  • RESF Rocky Linux
  • NetApp ActiveIQ Unified Manager
  • IBM QRadar SIEM
  • Dell NetWorker

Produktinfo

Typ

Hersteller

Name

Version

Lizenz

Webseite

CPE 2.3info

CPE 2.2info

CVSSv4info

VulDB Vector: 🔒
VulDB Zuverlässigkeit: 🔍

CVSSv3info

VulDB Meta Base Score: 5.1
VulDB Meta Temp Score: 5.0

VulDB Base Score: 4.8
VulDB Temp Score: 4.6
VulDB Vector: 🔒
VulDB Zuverlässigkeit: 🔍

NVD Base Score: 5.5
NVD Vector: 🔒

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-911 / CWE-664
CAPEC: 🔒
ATT&CK: 🔒

Physisch: Teilweise
Lokal: Ja
Remote: Teilweise

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 5.10.152/5.15.75/5.19.17/6.0.3
Patch: 3c6a888e352283a14f37b9b433cd598a1a3a7dd0/7c16d0a4e6a436b4e7c92bead3fab55aaa4c1141/4fb4053d90caa9985b87ec0e0c32c66a55bdfa3a/cdafa219ace013c594e2491158ad1b51f9923dde/5c13a4a0291b30191eff9ead8d010e1ca43a4d0c

Timelineinfo

04.10.2025 Advisory veröffentlicht
04.10.2025 +0 Tage CVE zugewiesen
04.10.2025 +0 Tage VulDB Eintrag erstellt
01.03.2026 +148 Tage VulDB Eintrag letzte Aktualisierung

Quelleninfo

Hersteller: kernel.org

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

CVE: CVE-2022-50471 (🔒)
GCVE (CVE): GCVE-0-2022-50471
GCVE (VulDB): GCVE-100-327047
CERT Bund: WID-SEC-2025-2194 - Linux Kernel: Mehrere Schwachstellen

Eintraginfo

Erstellt: 04.10.2025 17:57
Aktualisierung: 01.03.2026 13:41
Anpassungen: 04.10.2025 17:57 (58), 07.10.2025 05:42 (7), 17.11.2025 10:20 (1), 26.12.2025 02:34 (1), 23.01.2026 19:06 (12), 01.03.2026 13:41 (1)
Komplett: 🔍
Cache ID: 216::103

Be aware that VulDB is the high quality 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!