CVE-2021-46967: vhost-vdpa: fix vm_flags for virtqueue doorbell mapping
In the Linux kernel, the following vulnerability has been resolved:
vhost-vdpa: fix vm_flags for virtqueue doorbell mapping
The virtqueue doorbell is usually implemented via registeres but we
don't provide the necessary vma->flags like VM_PFNMAP. This may cause
several issues e.g when userspace tries to map the doorbell via vhost
IOTLB, kernel may panic due to the page is not backed by page
structure. This patch fixes this by setting the necessary
vm_flags. With this patch, try to map doorbell via IOTLB will fail
with bad address.
Security readout for executives and security teams
Plain-English summary
This Linux kernel flaw affects a specialized virtualization path, vhost-vdpa. Missing memory-mapping flags for a virtqueue doorbell could let a userspace mapping attempt trigger a kernel panic. The available sources describe a reliability and availability risk, not data theft or confirmed active exploitation.
Executive priority
Handle through normal kernel patch governance, with higher priority for virtualization infrastructure using vDPA. There is no sourced evidence of active exploitation, but kernel panic risk can still affect service availability.
Technical view
vhost-vdpa did not set required VMA flags, including VM_PFNMAP, for virtqueue doorbell mappings. Because the doorbell may be register-backed rather than page-backed, vhost IOTLB mapping could touch memory without a page structure and panic the kernel. The fix makes such mapping fail with a bad address.
Likely exposure
Exposure is most likely on Linux kernels in the affected range where vhost-vdpa or vDPA-backed virtualization is enabled. General Linux systems not using this subsystem appear less exposed, based on the source description.
Exploitation context
The source bundle does not show CISA KEV listing, public exploitation, exploit code, or weaponized details. The described impact is a kernel panic through a userspace mapping path, so treat it as a potential denial-of-service issue until vendor guidance says otherwise.
Researcher notes
The evidence is limited to the CVE record and Linux stable commit references. No CVSS, CWE, proof of concept, or distribution-specific affected package matrix is provided in the bundle, so validation should be kernel-branch and vendor-advisory driven.
Mitigation direction
Update to a vendor kernel containing the referenced stable fixes.
Prioritize virtualization hosts using vhost-vdpa or vDPA devices.
Check distribution advisories for backported fixes and exact package versions.
Avoid unsupported workaround assumptions; follow vendor guidance for temporary controls.
Validation and detection
Inventory Linux kernel versions across virtualization hosts.
Identify systems using vhost-vdpa or vDPA functionality.
Compare installed kernels against vendor fixed versions or referenced stable commits.
Confirm the CVE is not listed in CISA KEV before claiming active exploitation.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2021-46967 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.