CVE-2022-50092
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-06-18

Last updated on: 2025-11-18

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: dm thin: fix use-after-free crash in dm_sm_register_threshold_callback Fault inject on pool metadata device reports: BUG: KASAN: use-after-free in dm_pool_register_metadata_threshold+0x40/0x80 Read of size 8 at addr ffff8881b9d50068 by task dmsetup/950 CPU: 7 PID: 950 Comm: dmsetup Tainted: G W 5.19.0-rc6 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x34/0x44 print_address_description.constprop.0.cold+0xeb/0x3f4 kasan_report.cold+0xe6/0x147 dm_pool_register_metadata_threshold+0x40/0x80 pool_ctr+0xa0a/0x1150 dm_table_add_target+0x2c8/0x640 table_load+0x1fd/0x430 ctl_ioctl+0x2c4/0x5a0 dm_ctl_ioctl+0xa/0x10 __x64_sys_ioctl+0xb3/0xd0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 This can be easily reproduced using: echo offline > /sys/block/sda/device/state dd if=/dev/zero of=/dev/mapper/thin bs=4k count=10 dmsetup load pool --table "0 20971520 thin-pool /dev/sda /dev/sdb 128 0 0" If a metadata commit fails, the transaction will be aborted and the metadata space maps will be destroyed. If a DM table reload then happens for this failed thin-pool, a use-after-free will occur in dm_sm_register_threshold_callback (called from dm_pool_register_metadata_threshold). Fix this by in dm_pool_register_metadata_threshold() by returning the -EINVAL error if the thin-pool is in fail mode. Also fail pool_ctr() with a new error message: "Error registering metadata threshold".
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-06-18
Last Modified
2025-11-18
Generated
2026-05-07
AI Q&A
2025-06-18
EPSS Evaluated
2026-05-05
NVD
Affected Vendors & Products
Showing 5 associated CPEs
Vendor Product Version / Range
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-416 The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is a use-after-free bug in the Linux kernel's device mapper thin provisioning code (dm thin). It occurs when a metadata commit fails for a thin-pool device, causing the transaction to abort and metadata space maps to be destroyed. If the device mapper table is then reloaded for this failed thin-pool, a use-after-free happens in the function dm_sm_register_threshold_callback, which can lead to a kernel crash. The issue is fixed by checking if the thin-pool is in fail mode and returning an error to prevent the use-after-free.


How can this vulnerability impact me? :

This vulnerability can cause a kernel crash (use-after-free) when managing thin-provisioned storage pools in Linux. This can lead to system instability or denial of service if exploited, potentially disrupting services or applications relying on the affected storage.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by observing a use-after-free crash related to dmsetup and dm_pool_register_metadata_threshold in the Linux kernel. The crash may produce KASAN BUG reports with messages like 'use-after-free in dm_pool_register_metadata_threshold'. The provided reproduction commands include: 1. echo offline > /sys/block/sda/device/state 2. dd if=/dev/zero of=/dev/mapper/thin bs=4k count=10 3. dmsetup load pool --table "0 20971520 thin-pool /dev/sda /dev/sdb 128 0 0" Monitoring kernel logs (e.g., dmesg) for such KASAN reports and running these commands in a controlled environment can help detect the vulnerability.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation involves ensuring that the Linux kernel is updated to a version where this vulnerability is fixed. The fix involves returning an error (-EINVAL) if the thin-pool is in fail mode during dm_pool_register_metadata_threshold(), preventing the use-after-free. Until the patch is applied, avoid operations that cause metadata commit failures and DM table reloads on thin-pools, as these trigger the vulnerability.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart