CVE-2023-54137: vfio/type1: fix cap_migration information leak
In the Linux kernel, the following vulnerability has been resolved:
vfio/type1: fix cap_migration information leak
Fix an information leak where an uninitialized hole in struct
vfio_iommu_type1_info_cap_migration on the stack is exposed to userspace.
The definition of struct vfio_iommu_type1_info_cap_migration contains a hole as
shown in this pahole(1) output:
struct vfio_iommu_type1_info_cap_migration {
struct vfio_info_cap_header header; /* 0 8 */
__u32 flags; /* 8 4 */
/* XXX 4 bytes hole, try to pack */
__u64 pgsize_bitmap; /* 16 8 */
__u64 max_dirty_bitmap_size; /* 24 8 */
/* size: 32, cachelines: 1, members: 4 */
/* sum members: 28, holes: 1, sum holes: 4 */
/* last cacheline: 32 bytes */
};
The cap_mig variable is filled in without initializing the hole:
static int vfio_iommu_migration_build_caps(struct vfio_iommu *iommu,
struct vfio_info_cap *caps)
{
struct vfio_iommu_type1_info_cap_migration cap_mig;
cap_mig.header.id = VFIO_IOMMU_TYPE1_INFO_CAP_MIGRATION;
cap_mig.header.version = 1;
cap_mig.flags = 0;
/* support minimum pgsize */
cap_mig.pgsize_bitmap = (size_t)1 << __ffs(iommu->pgsize_bitmap);
cap_mig.max_dirty_bitmap_size = DIRTY_BITMAP_SIZE_MAX;
return vfio_info_add_capability(caps, &cap_mig.header, sizeof(cap_mig));
}
The structure is then copied to a temporary location on the heap. At this point
it's already too late and ioctl(VFIO_IOMMU_GET_INFO) copies it to userspace
later:
int vfio_info_add_capability(struct vfio_info_cap *caps,
struct vfio_info_cap_header *cap, size_t size)
{
struct vfio_info_cap_header *header;
header = vfio_info_cap_add(caps, size, cap->id, cap->version);
if (IS_ERR(header))
return PTR_ERR(header);
memcpy(header + 1, cap + 1, size - sizeof(*header));
return 0;
}
This issue was found by code inspection.
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel information leak in VFIO, a subsystem commonly used for device passthrough and virtualization. A small uninitialized padding area in a VFIO migration capability structure could be copied from kernel stack memory to a local userspace caller. The bundle does not identify remote impact or active exploitation.
Executive priority
Treat as a targeted kernel hygiene issue, not an emergency based on current evidence. Patch through normal kernel maintenance, with higher priority for virtualization hosts where untrusted local users or workloads may reach VFIO interfaces.
Technical view
The bug is an uninitialized four-byte hole in struct vfio_iommu_type1_info_cap_migration. vfio_iommu_migration_build_caps populates fields but not padding, then vfio_info_add_capability copies the structure and ioctl(VFIO_IOMMU_GET_INFO) later exposes it to userspace. The source says it was found by code inspection and fixed in Linux stable commits.
Likely exposure
Exposure is most plausible on Linux systems using affected kernel code with VFIO type1 IOMMU functionality reachable by local userspace. Environments with virtualization, device passthrough, or VFIO access should prioritize checking. The bundle does not identify affected distributions, appliances, or cloud services.
Exploitation context
No CISA KEV listing is present, and the bundle provides no evidence of exploitation in the wild. The described access path is local userspace through a VFIO ioctl, leaking limited uninitialized kernel stack padding rather than enabling direct code execution.
Researcher notes
The key evidence is the struct padding leak and copy path through VFIO_IOMMU_GET_INFO. The bundle lacks CVSS, CWE, exploit reports, distro mapping, and detailed fixed-version ranges, so validation should rely on kernel commit presence or vendor advisory confirmation.
Mitigation direction
Update to a Linux kernel containing the referenced stable fixes.
Check distribution advisories for backported VFIO fixes.
Restrict VFIO device access to trusted users and workloads.
Prioritize hosts using device passthrough or virtualization features.
Validation and detection
Inventory Linux kernel versions on virtualization and passthrough hosts.
Confirm vendor kernel packages include the referenced stable commits or backports.
Review which users or services can access VFIO device nodes.
Track remediation separately for custom or self-built kernels.
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-2023-54137 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.
0CVSS vectors
3Timeline events
0ADP providers
7Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Dec 24, 2025, 13:06 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.