Answer in brief
CVE-2026-53060 records a Unknown severity vulnerability in dm cache metadata: fix memory leak on metadata abort retry. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=b45e77b79215405bd039a690f5b06cc03e8ed27d <14f60e957f34f95a626caec76a8fae88cf4c397f || >=28d307f380df88a598bc0186d527462902d9bda1 <6b97cc7a42905755c56bbddc33aa8b792205caee || >=f74b7c5a85e22cd9091845e0d62a1dd89d0f855f <d1a79620c419a0af1911f99c873014b30740e303 || >=352b837a5541690d4f843819028cf2b8be83d424 <15c30997dca681f90dbf2d45ee629c1828bf0c0d || >=352b837a5541690d4f843819028cf2b8be83d424 <b0bd35535bdb6f58505f3a30ee5793986943997a || >=352b837a5541690d4f843819028cf2b8be83d424 <322a3b70368d49e39591fe9fc6c07d262128b05f || >=352b837a5541690d4f843819028cf2b8be83d424 <4311ca59a1891d33c4c8b7946f98c34f167fe833 || >=352b837a5541690d4f843819028cf2b8be83d424 <044ca491d4086dc5bf233e9fcb71db52df32f633 || 6e237cacda8b4e976849e7bff9fe7dff0e968586 || 3972ae47d0ee9b5b434af5d0cca6cdfd1e239d4f || 9958f5ffc44530b650fb4cc9038a4d167fa4f5c1 || f472bfc95d9c9653172dbdad39219b32fabf9b92 || bdd4e106929ac943f3226d8f03754b480701e97b || >=5.10.163 <5.10.258 || >=5.15.87 <5.15.209 || >=6.1.4 <6.1.175 || >=4.9.337 <4.10 || >=4.14.303 <4.15 || >=4.19.270 <4.20 || >=5.4.229 <5.5 || >=6.0.18 <6.1 | 14f60e957f34f95a626caec76a8fae88cf4c397f, 6b97cc7a42905755c56bbddc33aa8b792205caee, d1a79620c419a0af1911f99c873014b30740e303, 15c30997dca681f90dbf2d45ee629c1828bf0c0d, b0bd35535bdb6f58505f3a30ee5793986943997a, 322a3b70368d49e39591fe9fc6c07d262128b05f, 4311ca59a1891d33c4c8b7946f98c34f167fe833, 044ca491d4086dc5bf233e9fcb71db52df32f633, 5.10.258, 5.15.209, 6.1.175, 4.10, 4.15, 4.20, 5.5, 6.1 |
| Linux/Linuxgeneric | 6.2 | Not reported |
Published upstream
Jun 24, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Nov 6, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Jun 24, 2026
In the Linux kernel, the following vulnerability has been resolved: dm cache metadata: fix memory leak on metadata abort retry When failing to acquire the root_lock in dm_cache_metadata_abort because the block_manager is read-only, the temporary block_manager created outside the root_lock is not properly released, causing a memory leak. Reproduce steps: This can be reproduced by reloading a new table while the metadata is read-only. While the second call to dm_cache_metadata_abort is caused by lack of support for table preload in dm-cache, mentioned in commit 9b1cc9f251af ("dm cache: share cache-metadata object across inactive and active DM tables"), it exposes the memory leak in dm_cache_metadata_abort when the function is called multiple times. Specifically, dm-cache fails to sync the new cache object's mode during preresume, creating the reproducer condition. This issue could also occur through concurrent metadata_operation_failed calls due to races in cache mode updates, but the table preload scenario below provides a reliable reproducer. 1. Create a cache device with some faulty trailing metadata blocks dmsetup create cmeta <<EOF 0 200 linear /dev/sdc 0 200 7992 error EOF dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 262144 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 131072 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 1 writethrough smq 0" 2. Suspend and resume the cache to start a new metadata transaction and trigger metadata io errors on the next metadata commit. dmsetup suspend cache dmsetup resume cache 3. Write to the cache device to update metadata fio --filename=/dev/mapper/cache --name test --rw=randwrite --bs=4k \ --randrepeat=0 --direct=1 --size 64k 4. Preload the same table dmsetup reload cache --table "$(dmsetup table cache)" 5. Resume the new table. This triggers the memory leak. dmsetup suspend cache dmsetup resume cache kmemleak logs: <snip> unreferenced object 0xffff8880080c2010 (size 16): comm "dmsetup", pid 132, jiffies 4294982580 hex dump (first 16 bytes): 00 38 b9 07 80 88 ff ff 6a 6b 6b 6b 6b 6b 6b a5 ... backtrace (crc 3118f31c): kmemleak_alloc+0x28/0x40 __kmalloc_cache_noprof+0x3d9/0x510 dm_block_manager_create+0x51/0x140 dm_cache_metadata_abort+0x85/0x320 metadata_operation_failed+0x103/0x1e0 cache_preresume+0xacd/0xe70 dm_table_resume_targets+0xd3/0x320 __dm_resume+0x1b/0xf0 dm_resume+0x127/0x170 <snip>
Quoted source text, attributed separately from HOL analysis.