CVE-2026-90411: nvme-fc: unmap cmd_iu DMA on rsp_iu mapping failure in init_request
In the Linux kernel, the following vulnerability has been resolved:
nvme-fc: unmap cmdiu DMA on rspiu mapping failure in initrequest
nvmefcinitrequest() maps cmdiu and then rspiu for DMA. If the rspiu mapping fails, the original code only recorded the error and fell through: it left the already-mapped cmdiu unmapped and still marked the op as FCPOPSTATEIDLE before returning. Since blk-mq does not call .exitrequest() when .initrequest() fails, the cmdiu mapping is leaked for every op whose rspiu mapping fails.
Jump to an error path on rspiu mapping failure that unmaps cmdiu and returns the error without marking the op idle, so it stays in the FCPOPSTATEUNINIT state set by the initial memset().
Affected Software
Event History
Frequently Asked Questions
Under what condition does the DMA mapping leak occur?
The leak occurs when __nvme_fc_init_request() successfully maps cmd_iu for DMA but the subsequent rsp_iu DMA mapping fails. Each such failed request initialization can leave the cmd_iu mapping in place because blk-mq does not invoke .exit_request() after .init_request() fails.
What is the practical impact of the incorrect request state?
On rsp_iu mapping failure, the affected code marked the operation FCPOP_STATE_IDLE even though request initialization had failed. The fix instead returns the error after unmapping cmd_iu and leaves the operation in its initial FCPOP_STATE_UNINIT state.
What should be done if an affected system cannot be updated immediately?
The provided information identifies the failure path but does not specify a configuration workaround. The available remediation is to apply a kernel version containing the referenced fix.