https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 05 Oct 2026 05:42:16 +0000 https://cve.radiocsirt.org/vuln/bell-cve-2026-53060 <p><strong>Affected:</strong> Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> https://cve.radiocsirt.org/vuln/bell-cve-2026-53060 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0862 certfr-2026-avi-0862 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0862 https://cve.radiocsirt.org/vuln/euvd-2026-329957 EUVD-2026-329957 https://cve.radiocsirt.org/vuln/euvd-2026-329957 https://cve.radiocsirt.org/vuln/fkie_cve-2026-53060 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>dm cache metadata: fix memory leak on metadata abort retry</p> <p>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.</p> <p>Reproduce steps:</p> <p>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 (&#34;dm cache: share cache-metadata object across inactive and active DM tables&#34;), 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&#39;s mode during preresume, creating the reproducer condition.</p> <p>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.</p> <p>1. Create a cache device with some faulty trailing metadata blocks</p> <p>dmsetup create cmeta &lt;&lt;EOF 0 200 linear /dev/sdc 0 200 7992 error EOF dmsetup create cdata --table &#34;0 131072 linear /dev/sdc 8192&#34; dmsetup create corig --table &#34;0 262144 linear /dev/sdc 262144&#34; dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table &#34;0 131072 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 1 w…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>dm cache metadata: fix memory leak on metadata abort retry</p> <p>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.</p> <p>Reproduce steps:</p> <p>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 (&#34;dm cache: share cache-metadata object across inactive and active DM tables&#34;), 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&#39;s mode during preresume, creating the reproducer condition.</p> <p>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.</p> <p>1. Create a cache device with some faulty trailing metadata blocks</p> <p>dmsetup create cmeta &lt;&lt;EOF 0 200 linear /dev/sdc 0 200 7992 error EOF dmsetup create cdata --table &#34;0 131072 linear /dev/sdc 8192&#34; dmsetup create corig --table &#34;0 262144 linear /dev/sdc 262144&#34; dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table &#34;0 131072 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 1 w…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-53060 https://cve.radiocsirt.org/vuln/ghsa-w7r8-qc4c-gqhh <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>dm cache metadata: fix memory leak on metadata abort retry</p> <p>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.</p> <p>Reproduce steps:</p> <p>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 (&#34;dm cache: share cache-metadata object across inactive and active DM tables&#34;), 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&#39;s mode during preresume, creating the reproducer condition.</p> <p>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.</p> <p>1. Create a cache device with some faulty trailing metadata blocks</p> <p>dmsetup create cmeta &lt;&lt;EOF 0 200 linear /dev/sdc 0 200 7992 error EOF dmsetup create cdata --table &#34;0 131072 linear /dev/sdc 8192&#34; dmsetup create corig --table &#34;0 262144 linear /dev/sdc 262144&#34; dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table &#34;0 131072 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 1 w…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>dm cache metadata: fix memory leak on metadata abort retry</p> <p>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.</p> <p>Reproduce steps:</p> <p>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 (&#34;dm cache: share cache-metadata object across inactive and active DM tables&#34;), 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&#39;s mode during preresume, creating the reproducer condition.</p> <p>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.</p> <p>1. Create a cache device with some faulty trailing metadata blocks</p> <p>dmsetup create cmeta &lt;&lt;EOF 0 200 linear /dev/sdc 0 200 7992 error EOF dmsetup create cdata --table &#34;0 131072 linear /dev/sdc 8192&#34; dmsetup create corig --table &#34;0 262144 linear /dev/sdc 262144&#34; dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table &#34;0 131072 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 1 w…</p> https://cve.radiocsirt.org/vuln/ghsa-w7r8-qc4c-gqhh https://cve.radiocsirt.org/vuln/msrc_cve-2026-53060 msrc_CVE-2026-53060 https://cve.radiocsirt.org/vuln/msrc_cve-2026-53060 https://cve.radiocsirt.org/vuln/opensuse-su-2026:21388-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/opensuse-su-2026:21388-1 https://cve.radiocsirt.org/vuln/suse-su-2026:22742-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/suse-su-2026:22742-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-53060 <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:18.04:LTS: linux, Ubuntu:Pro:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.0 and 238 more</p> <p>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 (&#34;dm cache: share cache-metadata object across inactive and active DM tables&#34;), 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&#39;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 &lt;&lt;EOF 0 200 linear /dev/sdc 0 200 7992 error EOF dmsetup create cdata --table &#34;0 131072 linear /dev/sdc 8192&#34; dmsetup create corig --table &#34;0 262144 linear /dev/sdc 262144&#34; dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table &#34;0 131072 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 1 writethr…</p> <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:18.04:LTS: linux, Ubuntu:Pro:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.0 and 238 more</p> <p>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 (&#34;dm cache: share cache-metadata object across inactive and active DM tables&#34;), 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&#39;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 &lt;&lt;EOF 0 200 linear /dev/sdc 0 200 7992 error EOF dmsetup create cdata --table &#34;0 131072 linear /dev/sdc 8192&#34; dmsetup create corig --table &#34;0 262144 linear /dev/sdc 262144&#34; dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table &#34;0 131072 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 1 writethr…</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-53060 https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2077 <p>Ein entfernter Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um Sicherheitsvorkehrungen zu umgehen, einen Denial-of-Service-Zustand herbeizuführen und weitere, nicht näher spezifizierte Auswirkungen zu erzielen.</p> <p>Ein entfernter Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um Sicherheitsvorkehrungen zu umgehen, einen Denial-of-Service-Zustand herbeizuführen und weitere, nicht näher spezifizierte Auswirkungen zu erzielen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2077