libdm CVE-2026-19617

Exploitation requires two concrete preconditions: (1) the target system must use LVM and have the libdm-based LVM2 stack installed and active; (2) the attacker must be able to write or present a block device containing crafted LVM metadata to the target system - this implies control over shared storage infrastructure (SAN, iSCSI, NFS-backed VM images, or hypervisor-controlled virtual disks), not direct network socket access. A trigger event must then occur: an LVM command must parse the malicious metadata, either automatically (vgscan/pvscan at boot, udev hotplug handlers) or via explicit administrative action. Impact is limited to denial of service - process crash - with no evidence of code execution potential from the description. Exploitation is not possible via direct network connection to the host; the attack surface is the block-device layer. The PR:N assignment in the provided CVSS vector implies no privileges on the target system are required, but write access to storage infrastructure accessible to the target is an implied prerequisite. The 'remote attacker' label in the description most likely refers to an attacker remote to the target host but with access to shared storage, not unauthenticated internet exploitation.

The provided CVSS 3.1 vector (AV:L/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N, 5.7) contains three significant inconsistencies with the vulnerability description: (1) the vector records no availability impact (A:N) despite an explicitly described crash/DoS outcome; (2) it records confidentiality and integrity impacts (C:L/I:L) not supported by the description, which attributes only DoS; and (3) the 'remote attacker' framing in the description conflicts with AV:L. These discrepancies strongly suggest the vector was either applied to a different scope interpretation or recorded in error - security teams should not rely on it without vendor confirmation. No EPSS score was provided. The vulnerability is not listed in CISA KEV and no POC is publicly known, indicating no confirmed active exploitation. Real-world risk is moderate: exploitation requires an attacker to control or influence block-device-level storage accessible to the target, which is non-trivial in hardened environments but realistic in multi-tenant cloud, SAN, or hypervisor deployments. Systems with automated LVM scanning at boot or during storage hotplug events face higher practical risk due to reduced opportunity for human-in-the-loop detection.

An attacker with access to shared storage infrastructure - an iSCSI target, SAN LUN, or hypervisor managing VM disk images - writes a crafted LVM volume group metadata header containing configuration structures nested beyond the process stack capacity. When the target Linux system executes any LVM command against that device - whether automatically via vgscan at boot, via udev storage hotplug rules, or via explicit administrator action - the libdm parser descends the nested structure without bound, exhausting the call stack and crashing the LVM process. No public POC has been identified at time of analysis.