Answer in brief
CVE-2026-43128 records a Unknown severity vulnerability in RDMA/umem: Fix double dma_buf_unpin in failure path. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=1e4df4a21c5ac722df1099eee30cad9246c889b5 <70542b69abff34d24b11ae0bb200cc7a766d18df || >=1e4df4a21c5ac722df1099eee30cad9246c889b5 <b324327ff6f48d8065dca67eb3b91357e72726bd || >=1e4df4a21c5ac722df1099eee30cad9246c889b5 <ba3bf0f1bf1d5d0404678485e872980532fcc2c4 || >=1e4df4a21c5ac722df1099eee30cad9246c889b5 <d3e32e2f3262f1b25d77c085ace38e2cc4ad75cf || >=1e4df4a21c5ac722df1099eee30cad9246c889b5 <40126bcbefa79ea86672e05dae608596bab38319 || >=1e4df4a21c5ac722df1099eee30cad9246c889b5 <104016eb671e19709721c1b0048dd912dc2e96be | 70542b69abff34d24b11ae0bb200cc7a766d18df, b324327ff6f48d8065dca67eb3b91357e72726bd, ba3bf0f1bf1d5d0404678485e872980532fcc2c4, d3e32e2f3262f1b25d77c085ace38e2cc4ad75cf, 40126bcbefa79ea86672e05dae608596bab38319, 104016eb671e19709721c1b0048dd912dc2e96be |
| Linux/Linuxgeneric | 5.16 | Not reported |
Published upstream
May 6, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
In the Linux kernel, the following vulnerability has been resolved: RDMA/umem: Fix double dma_buf_unpin in failure path In ib_umem_dmabuf_get_pinned_with_dma_device(), the call to ib_umem_dmabuf_map_pages() can fail. If this occurs, the dmabuf is immediately unpinned but the umem_dmabuf->pinned flag is still set. Then, when ib_umem_release() is called, it calls ib_umem_dmabuf_revoke() which will call dma_buf_unpin() again. Fix this by removing the immediate unpin upon failure and just let the ib_umem_release/revoke path handle it. This also ensures the proper unmap-unpin unwind ordering if the dmabuf_map_pages call happened to fail due to dma_resv_wait_timeout (and therefore has a non-NULL umem_dmabuf->sgt).
Quoted source text, attributed separately from HOL analysis.
Answer in brief
CVE-2026-43128 records a Unknown severity vulnerability in RDMA/umem: Fix double dma_buf_unpin in failure path. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=1e4df4a21c5ac722df1099eee30cad9246c889b5 <70542b69abff34d24b11ae0bb200cc7a766d18df || >=1e4df4a21c5ac722df1099eee30cad9246c889b5 <b324327ff6f48d8065dca67eb3b91357e72726bd || >=1e4df4a21c5ac722df1099eee30cad9246c889b5 <ba3bf0f1bf1d5d0404678485e872980532fcc2c4 || >=1e4df4a21c5ac722df1099eee30cad9246c889b5 <d3e32e2f3262f1b25d77c085ace38e2cc4ad75cf || >=1e4df4a21c5ac722df1099eee30cad9246c889b5 <40126bcbefa79ea86672e05dae608596bab38319 || >=1e4df4a21c5ac722df1099eee30cad9246c889b5 <104016eb671e19709721c1b0048dd912dc2e96be | 70542b69abff34d24b11ae0bb200cc7a766d18df, b324327ff6f48d8065dca67eb3b91357e72726bd, ba3bf0f1bf1d5d0404678485e872980532fcc2c4, d3e32e2f3262f1b25d77c085ace38e2cc4ad75cf, 40126bcbefa79ea86672e05dae608596bab38319, 104016eb671e19709721c1b0048dd912dc2e96be |
| Linux/Linuxgeneric | 5.16 | Not reported |
Published upstream
May 6, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
In the Linux kernel, the following vulnerability has been resolved: RDMA/umem: Fix double dma_buf_unpin in failure path In ib_umem_dmabuf_get_pinned_with_dma_device(), the call to ib_umem_dmabuf_map_pages() can fail. If this occurs, the dmabuf is immediately unpinned but the umem_dmabuf->pinned flag is still set. Then, when ib_umem_release() is called, it calls ib_umem_dmabuf_revoke() which will call dma_buf_unpin() again. Fix this by removing the immediate unpin upon failure and just let the ib_umem_release/revoke path handle it. This also ensures the proper unmap-unpin unwind ordering if the dmabuf_map_pages call happened to fail due to dma_resv_wait_timeout (and therefore has a non-NULL umem_dmabuf->sgt).
Quoted source text, attributed separately from HOL analysis.