Cloudanix VulnDB

CVE-2026-98216

High · 7.1

CVSS

7.1

EPSS

0.1%

Published

Oct 6, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in Linux kernel code for certain high-speed network cards can crash the computer or freeze data transfers when applications try to use them.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Incorrect pointer arithmetic on struct credit_return* and improper dma_mmap_coherent usage in hfi1_file_mmap PIO_CRED case cause either out-of-bounds mapping (bad PTE above MAXPHYADDR) or always mapping the first page of the credit-return buffer, resulting in wrong-context credit reads and permanent PIO send stalls or kernel oops.

Why it matters to the business

Systems using Omni-Path 100 networking may experience sudden kernel crashes during application startup or complete stalls of high-performance message passing, halting workloads that rely on send PIO.

How an attack unfolds

A local user opens a PSM2 endpoint that triggers hfi1_file_mmap with the PIO_CRED case; when the hardware send context index is >=64 the miscalculated offset lands outside the allocation or selects the wrong page, causing either an immediate bad-pagetable oops or silent mapping of the first credit page so every subsequent PIO credit read is for the wrong context and sends hang forever.

How to fix it

Update the Linux kernel to a version containing the corrected hfi1 PIO_CRED mmap logic that passes the full allocation base to dma_mmap_coherent and lets vm_pgoff select the page; rebuild and reboot any systems exposing Omni-Path hardware.

How to confirm the fix worked

Confirm the hfi1 driver contains the DMA-API fix; run psm2_ep_open followed by transfers under PSM2_SDMA=0 and verify no oops occurs and PIO completes successfully.

Typical attack path

  1. Local unprivileged process calls psm2_ep_open()
  2. hfi1_file_mmap() is invoked for PIO_CRED credit-return region
  3. cr_page_offset arithmetic or vm_pgoff handling selects wrong or invalid page
  4. Kernel installs bad PTE or user-space receives first-page mapping only
  5. Subsequent PIO send operations read wrong credits and stall or trigger oops

How to detect it

Search kernel logs for 'Bad pagetable', 'Corrupted page table at address', 'psm2_ep_open_pr', and 'Oops: Bad pagetable' around times when PSM2 endpoints are opened; also look for processes stuck in PIO send paths with no forward progress.

  • Bad pagetable: 000d
  • Corrupted page table at address
  • psm2_ep_open_pr
  • PTE 800049168e911235
  • Oops: Bad pagetable

What your security team should do

  • Prioritize kernel updates on all hosts with Omni-Path adapters
  • Add kernel oops and PSM2 credit-page error strings to SIEM alerting
  • Temporarily set PSM2_SDMA=2 on affected nodes until patched

The record

In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Fix the PIO_CRED credit-return mmap hfi1_file_mmap()'s PIO_CRED case must hand user space the single credit-return page that holds this context's entry. That page is the second or third page of the per-node credit-return allocation once the hardware send context index reaches 64 or 128, so the failure below is intermittent: when the entry lands on the first page the offset is zero and everything works. Two things are wrong. First, cr_page_offset is a byte offset but .va is a struct credit_return *, so adding it is pointer arithmetic and scales the offset by sizeof(struct credit_return) == 64. memvirt then lands 256 KiB or 512 KiB past a 10240-byte allocation. With an IOMMU translating, that address is inside the vmalloc range but in no vm_area, so dma_mmap_coherent() -> iommu_dma_mmap() finds no pages, vmalloc_to_pfn() returns page_to_pfn(NULL), and remap_pfn_range() installs a frame above MAXPHYADDR. The first user read then takes: 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 Second, and still wrong once the arithmetic is corrected, dma_mmap_coherent() describes a whole coherent buffer and selects the page within it with vma->vm_pgoff. Offsetting cpu_addr has no effect: for a vmap'd allocation iommu_dma_mmap() uses cpu_addr only to locate the vm_area and then maps pages[vm_pgoff], which hfi1_file_mmap() has just set to 0. User space therefore always receives the first credit-return page, every credit read is for the wrong context, and send PIO stalls forever. Use the DMA API as intended: pass the base of the allocation with its full length and select the page with vm_pgoff. A separate length is needed because memlen must keep describing the VMA for the existing size check. The dma-direct path stays correct as well, since dma_direct_mmap() adds the same vm_pgoff to the base pfn. Tested on a Dell T7610 (Xeon E5-2650 v2, Intel IOMMU in DMA-FQ mode) against a Threadripper PRO 3995WX peer, both Omni-Path 100. Before this change psm2_ep_open() Oopses the kernel; with only the arithmetic corrected psm2_ep_open() succeeds but any transfer that uses send PIO hangs, PSM2_SDMA=2 (send PIO disabled) completing normally while PSM2_SDMA=0 (send PIO only) hangs every time. With this change send PIO, send DMA and the default mixed mode all work.

Affected packages

Ecosystem Package Introduced Fixed