CVE-2026-80790: nvmet-fc: fix invalid free in LS IOD error path
In the Linux kernel, the following vulnerability has been resolved:
nvmet-fc: fix invalid free in LS IOD error path
nvmetfcalloclsiodlist() advances iod while initializing the LS IOD array. If an rqstbuf allocation or response buffer DMA mapping fails, the unwind loop decrements iod past the start of the array. The final kfree(iod) therefore frees an address before the allocated object.
This can be reproduced with nvme-fcloop and failslab by setting fail-nth to 6 before creating a target port. KASAN reports:
BUG: KASAN: invalid-free in nvmetfcregistertargetport Free of addr ffff88816cf8ff48 by task nvmetfailnth/9552
Free the original allocation base stored in tgtport->iod instead. With this fix applied, the same sysfs write with fail-nth=6 returns -ENOMEM without any KASAN report.
Affected Software
Event History
Frequently Asked Questions
Under what conditions does the invalid free occur?
It occurs when initialization of the LS IOD array encounters either an rqstbuf allocation failure or a response-buffer DMA mapping failure. The failing cleanup path can then free an address before the allocated object.
Who is most likely to encounter this issue?
Systems using the Linux kernel nvmet-fc target functionality are relevant. The issue was reproduced using nvme-fcloop with failslab fault injection while creating a target port.
How can administrators determine whether the error path is affected?
With failslab configured with fail-nth set to 6 before target-port creation, an affected kernel can produce a KASAN invalid-free report in nvmet_fc_register_targetport. With the fix, the operation returns -ENOMEM without a KASAN report.
What behavior changes after applying the fix?
The cleanup path frees the original allocation base stored in tgtport->iod rather than the advanced iod pointer. When the induced allocation failure occurs, target-port creation returns -ENOMEM without the invalid free.