CVE-2026-72100

CVE-2026-72100 is a deadlock vulnerability in dm-integrity where the limit validation function dm_integrity_check_limits executes after a spinlock is acquired on the integrity metadata. If the check fails, the lock is never released, freezing I/O on the affected mapped device. The patch is trivial — move the validation before lock acquisition — but the real concern is what this pattern reveals about dm-integrity's error-handling architecture. This is a validation graft: validation logic added after locking code was written, without auditing resource acquisition order. The device mapper framework provides flexible target registration but enforces no contract requiring validation to precede resource acquisition. Each DM target becomes a separate microcosm with its own assumptions, and those assumptions get validated only under bug reports. The immediate priority for defenders: audit dm-integrity's other code paths for the same inverted pattern. When one validation graft fails this way, siblings often exist nearby. Check dm-integrity git history for the 6.x cycle for other pre-lock validation work that may not have been CVE'd. The discussion notes this pattern has appeared in dm-multipath, several block drivers, and the SCSI target subsystem — the same genealogy likely applies here. On blast radius: the critical unknown is whether the deadlock propagates to the underlying block device or isolates to just the dm-integrity mapping. If it propagates, a single malicious or misconfigured workload can wedge shared storage infrastructure beneath LVM or container storage backends. The CVSS 8.8 captures availability impact but likely underweights the dependency depth — one wedged bio can poison range tracking, potentially causing subsequent legitimate I/O to block or corrupt integrity state. This compounds the DoS with silent data integrity risk. The EPSS of 0.0056 suggests low probability of targeted exploitation, but the relevant trigger population isn't attackers — it's automated test infrastructure, storage benchmarking, and container orchestration platforms generating malformed I/O patterns. The question for your environment: can dm_integrity_check_limits fail under normal (non-malicious) conditions, or is it purely a guard against crafted inputs? If the former, you may already have untriggered denial-of-service conditions in production.

Reviewed through automated stages and approved by a human before publication.