---
id: CVE-2026-98216
title: |-
  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
summary: |-
  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…
severity: none
vendor: Linux
product: Linux
affected:
  - >-
    Linux >= 1ec82317a1daac78c04b0c15af89018ccf9fa2b7 <
    535530bb2ea5254e1e9f55280143d262dd065204
  - >-
    Linux >= 1ec82317a1daac78c04b0c15af89018ccf9fa2b7 <
    dcebe0b0bb080a25fe08011fd6b6e741f7912f01
  - >-
    Linux >= 1ec82317a1daac78c04b0c15af89018ccf9fa2b7 <
    180752deb7270ad37394ab6ef7cf4978fad040b3
  - >-
    Linux >= 1ec82317a1daac78c04b0c15af89018ccf9fa2b7 <
    bafeac9ce5d1ce5256bcf7e5702e831e9aaf419b
  - >-
    Linux >= 1ec82317a1daac78c04b0c15af89018ccf9fa2b7 <
    62f0f34fbd2b2d5653d33d3b9d42fdcabb1c0101
  - Linux 6.3
published: '2026-10-06'
updated: '2026-10-06'
sourceUpdated: '2026-10-06T09:18:08.260'
source: NVD
sourceUrl: 'https://nvd.nist.gov/vuln/detail/CVE-2026-98216'
references:
  - url: 'https://git.kernel.org/stable/c/180752deb7270ad37394ab6ef7cf4978fad040b3'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/535530bb2ea5254e1e9f55280143d262dd065204'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/62f0f34fbd2b2d5653d33d3b9d42fdcabb1c0101'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/bafeac9ce5d1ce5256bcf7e5702e831e9aaf419b'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/dcebe0b0bb080a25fe08011fd6b6e741f7912f01'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
tags:
  - nvd
  - cve.org
ingestedAt: '2026-10-06T08:50:17.442Z'
---

## Overview

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.

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.