CVE-2026-72102 is a use-after-free in the device-mapper subsystem stemming from an implicit ownership transfer in the dm_swap_table API that most developers never expect. When dm_swap_table succeeds, the table passed to it is no longer owned by the caller — ownership transfers to the mapped device's resume machinery. This transfer is not documented in the API contract. The bug occurred because the error handler in dm_early_create called dm_table_destroy on a table it no longer owned, after dm_swap_table had already taken possession. The patch simply removes that erroneous destroy call, which fixes the crash but leaves the implicit ownership transfer intact. Be aware that this creates a new failure mode: if dm_resume fails after ownership transfer, the table now leaks rather than being double-freed. Under memory pressure or rapid device creation/destruction cycles, this leak becomes a denial-of-service vector that may be harder to detect than a crash. The deeper risk is structural — the API's real semantics diverge from what developers reasonably expect, and this pattern of implicit ownership transfer has caused similar bugs in VFS superblock lifecycle and the driver model. Audit any other code paths that call dm_swap_table or dm_early_create for similar error-handling assumptions. The fix is correct for this instance, but it does not prevent the next developer from hitting the same trap when they encounter dm_swap_table in isolation. The knowledge that ownership transfers lives in commit history, not in type system guarantees or API documentation — treat it as a one-off until the subsystem formalizes object lifecycle ownership in its contracts.
CVE-2026-72102
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedIn the Linux kernel, the following vulnerability has been resolved: dm_early_create: fix freeing used table on dm_resume failure If dm_resume fails, the kernel attempts to free table with dm_table_destroy, but the table was already instantiated with dm_swap_table. This commit skips the call to dm_table_destroy in this case.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysisA detailed technical summary for this CVE is being prepared.
CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Local
- Complexity
- Low
- Privileges
- Low
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- High
- Availability
- High
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
From vendor dataThere is no version to upgrade to and no patch to apply. Every affected install stays exposed until the vendor ships a fix — or somebody else builds one.
Free. We build fixes in the order the community asks for them — and we’ll tell you the moment this one lands.
We develop and verify an original fix where the vendor hasn’t, from $4,900. Deployed to your staging first — never straight to production.
Scope it with usSee what else the community needs solved on the solutions-needed board.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2026-72102 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesCVE-2026-72102 is a use-after-free in the device-mapper subsystem stemming from an implicit ownership transfer in the dm_swap_table API that most developers never expect. When dm_swap_table succeeds, the table passed to it is no longer owned by the caller — ownership transfers to the mapped device's resume machinery. This transfer is not documented in the API contract. The bug occurred because the error handler in dm_early_create called dm_table_destroy on a table it no longer owned, after dm_swap_table had already taken possession. The patch simply removes that erroneous destroy call, which fixes the crash but leaves the implicit ownership transfer intact. Be aware that this creates a new failure mode: if dm_resume fails after ownership transfer, the table now leaks rather than being double-freed. Under memory pressure or rapid device creation/destruction cycles, this leak becomes a denial-of-service vector that may be harder to detect than a crash. The deeper risk is structural — the API's real semantics diverge from what developers reasonably expect, and this pattern of implicit ownership transfer has caused similar bugs in VFS superblock lifecycle and the driver model. Audit any other code paths that call dm_swap_table or dm_early_create for similar error-handling assumptions. The fix is correct for this instance, but it does not prevent the next developer from hitting the same trap when they encounter dm_swap_table in isolation. The knowledge that ownership transfers lives in commit history, not in type system guarantees or API documentation — treat it as a one-off until the subsystem formalizes object lifecycle ownership in its contracts.
Practitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2026-72102 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data