CVE-2021-47130

What it actually does

Incorrect assignment of p2p_dev leads nvmet to call pci_p2pmem_free_sgl on an SGL that was never allocated from the p2p pool, triggering a BUG() inside gen_pool_free_owner and a kernel panic.

Why it matters to the business

NVMe target systems using RDMA may experience sudden kernel crashes and loss of storage connectivity, requiring reboots and interrupting dependent workloads until the kernel or affected packages are updated.

How an attack unfolds

An attacker configures an NVMe-oF target with p2p memory enabled, then issues commands that cause the p2p pool to be empty while a p2p device is still detected; the resulting free path in nvmet_rdma_release_rsp panics the kernel.

How to fix it

Upgrade resource-agents, resource-agents-aliyun, and resource-agents-gcp to 4.1.1-68.el8_3.1 or newer on AlmaLinux 8; apply the corresponding kernel update that contains the nvmet fix for p2pmem handling.

How to confirm the fix worked

Confirm the installed package versions match the fixed releases, then exercise nvmet-rdma workloads that previously triggered the empty-pool condition and verify no BUG() occurs in gen_pool_free_owner.

Typical attack path

1. Discover or create an nvmet-rdma target with p2p memory support
2. Force the p2p pool into an empty state while a p2p device remains visible
3. Send NVMe commands that allocate from the regular pool but trigger the erroneous p2p free path
4. Observe kernel BUG at lib/genalloc.c followed by system crash

How to detect it

Search kernel logs for the signature 'kernel BUG at lib/genalloc.c:518' together with stack frames containing pci_p2pmem_free_sgl, nvmet_req_free_sgls, and nvmet_rdma_release_rsp; correlate with nvmet-rdma target activity around the crash time.

What your security team should do

• Apply the listed package updates immediately on all systems exposing NVMe-oF targets
• Prioritize systems that enable p2p memory or RDMA offload
• Monitor for kernel panics referencing pci_p2pmem_free_sgl or nvmet_req_free_sgls