CVE-2021-47343

What it actually does

In the Linux kernel dm btree remove path, remove_raw() failure from an IO read error leaves shadow_spine::root uninitialized; the uninitialized value is then assigned to new_root, so pmd->details_root or pmd->root holds an invalid pointer that later triggers out-of-bounds memory access or a general protection fault when the details_info tree is read.

Why it matters to the business

Storage management operations on Linux systems using device-mapper thin provisioning can crash or corrupt memory, causing downtime, loss of thin-pool metadata access, and potential data-integrity problems during routine device deletion or pool maintenance.

How an attack unfolds

An attacker with local access that can issue device-mapper messages or induce IO errors during btree removal triggers the uninitialized-root assignment; subsequent metadata operations then dereference the invalid pointer, resulting in a kernel fault that may be turned into memory corruption for privilege escalation.

How to fix it

Upgrade the Linux kernel to a version containing the upstream fix that only assigns new_root after successful removal; apply the patch or distribution kernel update that resolves the assignment of uninitialized shadow_spine::root.

How to confirm the fix worked

Confirm the running kernel contains the commit that gates the new_root assignment on removal success; reproduce a dm btree remove under injected IO error and verify no uninitialized pointer is propagated to pmd structures; inspect kernel logs for absence of the described general protection fault in metadata_ll_load_ie.

Typical attack path

1. Obtain local access and issue dm-pool delete or equivalent thin-device message
2. Force or wait for an IO read error inside remove_raw() during shadowing
3. Allow the uninitialized root value to be written into pmd->root or pmd->details_root
4. Trigger a follow-on read of the details_info tree that dereferences the invalid pointer

How to detect it

Search kernel logs and crash dumps for general protection faults referencing metadata_ll_load_ie, sm_metadata_count_is_more_than_one, or dm_btree_remove; correlate with preceding device-mapper ioctl or pool-message activity that performs thin-device deletion.

• metadata_ll_load_ie+0x14/0x30
• general protection fault, probably for non-canonical address
• dm_btree_remove+0xf4/0x1c0
• dm_pool_delete_thin_device+0xc3/0x140
• pool_message+0x218/0x2b0

What your security team should do

• Prioritize kernel updates on systems using dm-thin provisioning
• Harden IO paths and monitor for unexpected read errors on thin-pool metadata devices
• Review device-mapper message audit logs for unusual thin-device deletion activity