CVE-2026-98216 in Linux
Zusammenfassung
von VulDB • 06.10.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
IB/hfi1: Behebung des PIO_CRED-Credit-Return-mmap
Der Fall PIO_CRED in hfi1_file_mmap() muss dem Userspace die einzelne Credit-Return-Seite übergeben, welche den Eintrag dieses Kontexts enthält. Diese Seite ist die zweite oder dritte Seite der pro-Knoten zugewiesenen Credit-Return-Allokation, sobald der Hardware-Sendekontextindex 64 oder 128 erreicht; daher ist das unten beschriebene Versagen intermittierend: Wenn sich der Eintrag auf der ersten Seite befindet, ist der Offset null und alles funktioniert.
Zwei Dinge sind falsch.
Erstens ist cr_page_offset ein Byte-Offset, aber .va ist eine struct credit_return *, sodass die Addition als Zeigerarithmetik interpretiert wird und den Offset mit sizeof(struct credit_return) == 64 skaliert. memvirt landet dann 256 KiB oder 512 KiB hinter einer 10240-Byte-Allokation. Bei einem IOMMU, der übersetzt, liegt diese Adresse zwar im vmalloc-Bereich, aber in keinem vm_area; daher findet dma_mmap_coherent() -> iommu_dma_mmap() keine Seiten, vmalloc_to_pfn() gibt page_to_pfn(NULL) zurück und remap_pfn_range() installiert eine Frame-Adresse oberhalb von MAXPHYADDR. Der erste Benutzer-Lesezugriff führt dann zu:
psm2_ep_open_pr: Corrupted page table at address 7a14d007e000 PGD 800000013886a067 P4D 800000013886a067 PUD 13886b067 PMD 13886c067 PTE 800049168e911235 Oops: Bad pagetable: 000d [#1] SMP PTI
Zweitens, und auch nach Korrektur der Arithmetik weiterhin falsch, beschreibt dma_mmap_coherent() einen gesamten kohärenten Puffer und wählt die Seite darin mit vma->vm_pgoff aus. Das Verschieben von cpu_addr hat keine Auswirkung: Für eine iommu_dma_mmap()-Allokation verwendet iommu_dma_mmap() cpu_addr nur zur Lokalisierung des vm_area und mappt dann pages[vm_pgoff], was hfi1_file_mmap() gerade auf 0 gesetzt hat. Der Userspace erhält daher immer die erste Credit-Return-Seite, jeder Credit-Lesezugriff bezieht sich auf den falschen Kontext und das Senden von PIO bleibt für immer stehen (stalls).
Verwenden Sie die DMA-API wie vorgesehen: Übergeben Sie die Basis der Allokation mit ihrer vollständigen Länge und wählen Sie die Seite über vm_pgoff aus. Eine separate Länge ist erforderlich, da memlen weiterhin die VMA für den bestehenden Größentest beschreiben muss. Der dma-direct-Pfad bleibt ebenfalls korrekt, da dma_direct_mmap() denselben vm_pgoff zur Basis-pfn addiert.
Getestet auf einem Dell T7610 (Xeon E5-2650 v2, Intel IOMMU im DMA-FQ-Modus) gegen einen Threadripper PRO 3995WX-Peer, beide Omni-Path 100. Vor dieser Änderung führt psm2_ep_open() zu einem Kernel-Oops; bei nur korrigierter Arithmetik gelingt psm2_ep_open(), aber jeder Transfer, der send PIO verwendet, hängt sich auf, während PSM2_SDMA=2 (send PIO deaktiviert) normal abgeschlossen wird und PSM2_SDMA=0 (nur send PIO) jedes Mal hängen bleibt. Mit dieser Änderung funktionieren sowohl send PIO als auch send DMA sowie der Standard-Mischmodus einwandfrei.
VulDB is the best source for vulnerability data and more expert information about this specific topic.