In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
IB\/hfi1: Fix the PIO_CRED credit-return mmap<\/p>\n
hfi1_file_mmap()’s PIO_CRED case must hand user space the single
\ncredit-return page that holds this context’s entry. That page is the
\nsecond or third page of the per-node credit-return allocation once the
\nhardware send context index reaches 64 or 128, so the failure below is
\nintermittent: when the entry lands on the first page the offset is zero
\nand everything works.<\/p>\n
Two things are wrong.<\/p>\n
First, cr_page_offset is a byte offset but .va is a struct
\ncredit_return *, so adding it is pointer arithmetic and scales the offset
\nby sizeof(struct credit_return) == 64. memvirt then lands 256 KiB or
\n512 KiB past a 10240-byte allocation. With an IOMMU translating, that
\naddress is inside the vmalloc range but in no vm_area, so
\ndma_mmap_coherent() -> iommu_dma_mmap() finds no pages, vmalloc_to_pfn()
\nreturns page_to_pfn(NULL), and remap_pfn_range() installs a frame above
\nMAXPHYADDR. The first user read then takes:<\/p>\n
psm2_ep_open_pr: Corrupted page table at address 7a14d007e000
\n PGD 800000013886a067 P4D 800000013886a067 PUD 13886b067 PMD 13886c067
\n PTE 800049168e911235
\n Oops: Bad pagetable: 000d [#1] SMP PTI<\/p>\n
Second, and still wrong once the arithmetic is corrected,
\ndma_mmap_coherent() describes a whole coherent buffer and selects the
\npage within it with vma->vm_pgoff. Offsetting cpu_addr has no effect:
\nfor a vmap’d allocation iommu_dma_mmap() uses cpu_addr only to locate the
\nvm_area and then maps pages[vm_pgoff], which hfi1_file_mmap() has just
\nset to 0. User space therefore always receives the first credit-return
\npage, every credit read is for the wrong context, and send PIO stalls
\nforever.<\/p>\n
Use the DMA API as intended: pass the base of the allocation with its
\nfull length and select the page with vm_pgoff. A separate length is
\nneeded because memlen must keep describing the VMA for the existing size
\ncheck. The dma-direct path stays correct as well, since dma_direct_mmap()
\nadds the same vm_pgoff to the base pfn.<\/p>\n
Tested on a Dell T7610 (Xeon E5-2650 v2, Intel IOMMU in DMA-FQ mode)
\nagainst a Threadripper PRO 3995WX peer, both Omni-Path 100. Before this
\nchange psm2_ep_open() Oopses the kernel; with only the arithmetic
\ncorrected psm2_ep_open() succeeds but any transfer that uses send PIO
\nhangs, PSM2_SDMA=2 (send PIO disabled) completing normally while
\nPSM2_SDMA=0 (send PIO only) hangs every time. With this change send PIO,
\nsend DMA and the default mixed mode all work.<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
IB\/hfi1: Fix the PIO_CRED credit-return mmap<\/p>\n
hfi1_file_mmap()’s PIO_CRED case must hand user space the single
\ncredit-return page t<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-33285","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/33285","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=33285"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=33285"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=33285"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}