Linux kernel - NVMe-oF RDMA target, drivers/nvme/target/rdma.c: TENANT ISOLATION: nvmet_rdma_use_inline_sg() accepted

Impact

TENANT ISOLATION: nvmet_rdma_use_inline_sg() accepted any host-controlled inline data offset that satisfied off + len <= inline_data_size, but the mapping still assumed the data started in the first inline page. When a port is configured with inline_data_size larger than PAGE_SIZE - a legitimate, performance-motivated setting, allowed up to 16K - an offset past PAGE_SIZE makes the length calculation underflow to roughly 4 GiB, and the block backend reads far past the intended page. There is also a double-free path where a persistent inline page is mistaken for an allocated scatterlist and freed. Remote, host-controlled, on the NVMe-oF-over-RDMA target that fronts tenant storage: this is the disaggregated-storage isolation break in its most direct form.

Who can reach it

A connected NVMe-oF initiator submits a command with an inline data offset in the range between PAGE_SIZE and the port's configured inline_data_size. Requires the target port to be configured with inline_data_size > PAGE_SIZE, which operators do deliberately to cut latency on small writes - so the hardened, performance-tuned configuration is the vulnerable one.

What to do

Host reboot / kernel upgrade on NVMe-oF RDMA targets. Immediate config-only mitigation with a measurable but acceptable cost: set the port's inline_data_size to PAGE_SIZE or less (nvmet configfs, applied on port re-enable, brief reconnect for attached initiators) - this removes the precondition entirely without a reboot. Then schedule the kernel upgrade and restore the larger inline size afterwards if the latency mattered.

References