https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 21:54:28 +0000 https://cve.radiocsirt.org/vuln/bdu:2025-03156 bdu:2025-03156 https://cve.radiocsirt.org/vuln/bdu:2025-03156 https://cve.radiocsirt.org/vuln/bell-cve-2024-50279 <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> https://cve.radiocsirt.org/vuln/bell-cve-2024-50279 https://cve.radiocsirt.org/vuln/certfr-2024-avi-1031 certfr-2024-avi-1031 https://cve.radiocsirt.org/vuln/certfr-2024-avi-1031 https://cve.radiocsirt.org/vuln/cnvd-2024-46392 cnvd-2024-46392 https://cve.radiocsirt.org/vuln/cnvd-2024-46392 https://cve.radiocsirt.org/vuln/euvd-2026-313570 EUVD-2026-313570 https://cve.radiocsirt.org/vuln/euvd-2026-313570 https://cve.radiocsirt.org/vuln/fkie_cve-2024-50279 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>dm cache: fix out-of-bounds access to the dirty bitset when resizing</p> <p>dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access.</p> <p>Reproduce steps:</p> <p>1. create a cache device of 1024 cache blocks (128 bytes dirty bitset)</p> <p>dmsetup create cmeta --table &#34;0 8192 linear /dev/sdc 0&#34; dmsetup create cdata --table &#34;0 131072 linear /dev/sdc 8192&#34; dmsetup create corig --table &#34;0 524288 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 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0&#34;</p> <p>2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80)</p> <p>dmsetup suspend cache dmsetup reload cdata --table &#34;0 65536 linear /dev/sdc 8192&#34; dmsetup resume cdata dmsetup resume cache</p> <p>KASAN reports:</p> <p>BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131</p> <p>(...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0</p> <p>(...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>dm cache: fix out-of-bounds access to the dirty bitset when resizing</p> <p>dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access.</p> <p>Reproduce steps:</p> <p>1. create a cache device of 1024 cache blocks (128 bytes dirty bitset)</p> <p>dmsetup create cmeta --table &#34;0 8192 linear /dev/sdc 0&#34; dmsetup create cdata --table &#34;0 131072 linear /dev/sdc 8192&#34; dmsetup create corig --table &#34;0 524288 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 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0&#34;</p> <p>2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80)</p> <p>dmsetup suspend cache dmsetup reload cdata --table &#34;0 65536 linear /dev/sdc 8192&#34; dmsetup resume cdata dmsetup resume cache</p> <p>KASAN reports:</p> <p>BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131</p> <p>(...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0</p> <p>(...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2024-50279 https://cve.radiocsirt.org/vuln/ghsa-v6rg-qv6j-p6gp <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>dm cache: fix out-of-bounds access to the dirty bitset when resizing</p> <p>dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access.</p> <p>Reproduce steps:</p> <p>1. create a cache device of 1024 cache blocks (128 bytes dirty bitset)</p> <p>dmsetup create cmeta --table &#34;0 8192 linear /dev/sdc 0&#34; dmsetup create cdata --table &#34;0 131072 linear /dev/sdc 8192&#34; dmsetup create corig --table &#34;0 524288 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 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0&#34;</p> <p>2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80)</p> <p>dmsetup suspend cache dmsetup reload cdata --table &#34;0 65536 linear /dev/sdc 8192&#34; dmsetup resume cdata dmsetup resume cache</p> <p>KASAN reports:</p> <p>BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131</p> <p>(...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0</p> <p>(...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>dm cache: fix out-of-bounds access to the dirty bitset when resizing</p> <p>dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access.</p> <p>Reproduce steps:</p> <p>1. create a cache device of 1024 cache blocks (128 bytes dirty bitset)</p> <p>dmsetup create cmeta --table &#34;0 8192 linear /dev/sdc 0&#34; dmsetup create cdata --table &#34;0 131072 linear /dev/sdc 8192&#34; dmsetup create corig --table &#34;0 524288 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 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0&#34;</p> <p>2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80)</p> <p>dmsetup suspend cache dmsetup reload cdata --table &#34;0 65536 linear /dev/sdc 8192&#34; dmsetup resume cdata dmsetup resume cache</p> <p>KASAN reports:</p> <p>BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131</p> <p>(...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0</p> <p>(...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00…</p> https://cve.radiocsirt.org/vuln/ghsa-v6rg-qv6j-p6gp https://cve.radiocsirt.org/vuln/icsa-25-226-07 <p>nfsd: NULL dereference in nfs3svc_encode_getaclres. scsi: core: use-after-free vulnerability. NFSD: vulnerability caused by loff_t overflow on the server when a client reads near the maximum offset, causing the server to return an EINVAL error, which the client retries indefinitely, instead of handling out-of-range READ requests by returning a short result with an EOF flag. NFSD: Vulnerability caused by an underflow in ia_size due to a mismatch between signed and unsigned 64-bit file size values, which can cause issues when handling large file sizes from NFS clients. NFSD: Vulnerability handling large file sizes for NFSv3 improperly capping client size values larger than s64_max, leading to unexpected behavior and potential data corruption. sh: cpuinfo: warning for CONFIG_CPUMASK_OFFSTACK. When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS are selected, cpu_max_bits_warn() generates a runtime warning when showing /proc/cpuinfo. A failure in the -fstack-protector feature in GCC-based toolchains that target AArch64 allows an attacker to exploit an existing buffer overflow in dynamically-sized local variables in your application without this being detected. This stack-protector failure only applies to C99-style dynamically-sized local variables or those created using alloca(). The stack-protector operates as intended for statically-sized local variables.</p> <p>The default behavior when the stack-protector detects an overflow is to terminate your application, resulting…</p> <p>nfsd: NULL dereference in nfs3svc_encode_getaclres. scsi: core: use-after-free vulnerability. NFSD: vulnerability caused by loff_t overflow on the server when a client reads near the maximum offset, causing the server to return an EINVAL error, which the client retries indefinitely, instead of handling out-of-range READ requests by returning a short result with an EOF flag. NFSD: Vulnerability caused by an underflow in ia_size due to a mismatch between signed and unsigned 64-bit file size values, which can cause issues when handling large file sizes from NFS clients. NFSD: Vulnerability handling large file sizes for NFSv3 improperly capping client size values larger than s64_max, leading to unexpected behavior and potential data corruption. sh: cpuinfo: warning for CONFIG_CPUMASK_OFFSTACK. When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS are selected, cpu_max_bits_warn() generates a runtime warning when showing /proc/cpuinfo. A failure in the -fstack-protector feature in GCC-based toolchains that target AArch64 allows an attacker to exploit an existing buffer overflow in dynamically-sized local variables in your application without this being detected. This stack-protector failure only applies to C99-style dynamically-sized local variables or those created using alloca(). The stack-protector operates as intended for statically-sized local variables.</p> <p>The default behavior when the stack-protector detects an overflow is to terminate your application, resulting…</p> https://cve.radiocsirt.org/vuln/icsa-25-226-07 https://cve.radiocsirt.org/vuln/msrc_cve-2024-50279 msrc_CVE-2024-50279 https://cve.radiocsirt.org/vuln/msrc_cve-2024-50279 https://cve.radiocsirt.org/vuln/oesa-2024-2537 <p><strong>Affected:</strong> openEuler:24.03-LTS: kernel</p> <p>The Linux Kernel, the operating system core itself. Security Fix(es): In the Linux kernel, the following vulnerability has been resolved: xhci: Handle TD clearing for multiple streams case When multiple streams are in use, multiple TDs might be in flight when an endpoint is stopped. We need to issue a Set TR Dequeue Pointer for each, to ensure everything is reset properly and the caches cleared. Change the logic so that any N&amp;gt;1 TDs found active for different streams are deferred until after the first one is processed, calling xhci_invalidate_cancelled_tds() again from xhci_handle_cmd_set_deq() to queue another command until we are done with all of them. Also change the error/&amp;quot;should never happen&amp;quot; paths to ensure we at least clear any affected TDs, even if we can&amp;apos;t issue a command to clear the hardware cache, and complain loudly with an xhci_warn() if this ever happens. This problem case dates back to commit e9df17eb1408 (&amp;quot;USB: xhci: Correct assumptions about number of rings per endpoint.&amp;quot;) early on in the XHCI driver&amp;apos;s life, when stream support was first added. It was then identified but not fixed nor made into a warning in commit 674f8438c121 (&amp;quot;xhci: split handling halted endpoints into two steps&amp;quot;), which added a FIXME comment for the problem case (without materially changing the behavior as far as I can tell, though the new logic made the problem more obvious). Then later, in commit 94f339147fc3 (&amp;quot;xhci: Fix failure…</p> <p><strong>Affected:</strong> openEuler:24.03-LTS: kernel</p> <p>The Linux Kernel, the operating system core itself. Security Fix(es): In the Linux kernel, the following vulnerability has been resolved: xhci: Handle TD clearing for multiple streams case When multiple streams are in use, multiple TDs might be in flight when an endpoint is stopped. We need to issue a Set TR Dequeue Pointer for each, to ensure everything is reset properly and the caches cleared. Change the logic so that any N&amp;gt;1 TDs found active for different streams are deferred until after the first one is processed, calling xhci_invalidate_cancelled_tds() again from xhci_handle_cmd_set_deq() to queue another command until we are done with all of them. Also change the error/&amp;quot;should never happen&amp;quot; paths to ensure we at least clear any affected TDs, even if we can&amp;apos;t issue a command to clear the hardware cache, and complain loudly with an xhci_warn() if this ever happens. This problem case dates back to commit e9df17eb1408 (&amp;quot;USB: xhci: Correct assumptions about number of rings per endpoint.&amp;quot;) early on in the XHCI driver&amp;apos;s life, when stream support was first added. It was then identified but not fixed nor made into a warning in commit 674f8438c121 (&amp;quot;xhci: split handling halted endpoints into two steps&amp;quot;), which added a FIXME comment for the problem case (without materially changing the behavior as far as I can tell, though the new logic made the problem more obvious). Then later, in commit 94f339147fc3 (&amp;quot;xhci: Fix failure…</p> https://cve.radiocsirt.org/vuln/oesa-2024-2537 https://cve.radiocsirt.org/vuln/ssa-355557 <p>nfsd: NULL dereference in nfs3svc_encode_getaclres. scsi: core: use-after-free vulnerability. NFSD: vulnerability caused by loff_t overflow on the server when a client reads near the maximum offset, causing the server to return an EINVAL error, which the client retries indefinitely, instead of handling out-of-range READ requests by returning a short result with an EOF flag. NFSD: Vulnerability caused by an underflow in ia_size due to a mismatch between signed and unsigned 64-bit file size values, which can cause issues when handling large file sizes from NFS clients. NFSD: Vulnerability handling large file sizes for NFSv3 improperly capping client size values larger than s64_max, leading to unexpected behavior and potential data corruption. sh: cpuinfo: warning for CONFIG_CPUMASK_OFFSTACK. When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS are selected, cpu_max_bits_warn() generates a runtime warning when showing /proc/cpuinfo. A failure in the -fstack-protector feature in GCC-based toolchains that target AArch64 allows an attacker to exploit an existing buffer overflow in dynamically-sized local variables in your application without this being detected. This stack-protector failure only applies to C99-style dynamically-sized local variables or those created using alloca(). The stack-protector operates as intended for statically-sized local variables.</p> <p>The default behavior when the stack-protector detects an overflow is to terminate your application, resulting…</p> <p>nfsd: NULL dereference in nfs3svc_encode_getaclres. scsi: core: use-after-free vulnerability. NFSD: vulnerability caused by loff_t overflow on the server when a client reads near the maximum offset, causing the server to return an EINVAL error, which the client retries indefinitely, instead of handling out-of-range READ requests by returning a short result with an EOF flag. NFSD: Vulnerability caused by an underflow in ia_size due to a mismatch between signed and unsigned 64-bit file size values, which can cause issues when handling large file sizes from NFS clients. NFSD: Vulnerability handling large file sizes for NFSv3 improperly capping client size values larger than s64_max, leading to unexpected behavior and potential data corruption. sh: cpuinfo: warning for CONFIG_CPUMASK_OFFSTACK. When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS are selected, cpu_max_bits_warn() generates a runtime warning when showing /proc/cpuinfo. A failure in the -fstack-protector feature in GCC-based toolchains that target AArch64 allows an attacker to exploit an existing buffer overflow in dynamically-sized local variables in your application without this being detected. This stack-protector failure only applies to C99-style dynamically-sized local variables or those created using alloca(). The stack-protector operates as intended for statically-sized local variables.</p> <p>The default behavior when the stack-protector detects an overflow is to terminate your application, resulting…</p> https://cve.radiocsirt.org/vuln/ssa-355557 https://cve.radiocsirt.org/vuln/suse-su-2024:4313-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/suse-su-2024:4313-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-50279 <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, 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 and 194 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: dm cache: fix out-of-bounds access to the dirty bitset when resizing dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access. Reproduce steps: 1. create a cache device of 1024 cache blocks (128 bytes dirty bitset) dmsetup create cmeta --table &#34;0 8192 linear /dev/sdc 0&#34; dmsetup create cdata --table &#34;0 131072 linear /dev/sdc 8192&#34; dmsetup create corig --table &#34;0 524288 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 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0&#34; 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80) dmsetup suspend cache dmsetup reload cdata --table &#34;0 65536 linear /dev/sdc 8192&#34; dmsetup resume cdata dmsetup resume cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 &gt;f…</p> <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, 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 and 194 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: dm cache: fix out-of-bounds access to the dirty bitset when resizing dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access. Reproduce steps: 1. create a cache device of 1024 cache blocks (128 bytes dirty bitset) dmsetup create cmeta --table &#34;0 8192 linear /dev/sdc 0&#34; dmsetup create cdata --table &#34;0 131072 linear /dev/sdc 8192&#34; dmsetup create corig --table &#34;0 524288 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 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0&#34; 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80) dmsetup suspend cache dmsetup reload cdata --table &#34;0 65536 linear /dev/sdc 8192&#34; dmsetup resume cdata dmsetup resume cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 &gt;f…</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-50279 https://cve.radiocsirt.org/vuln/wid-sec-w-2024-3497 <p>Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Zustand herbeizuführen oderum einen nicht näher spezifizierten Angriff durchzuführen.</p> <p>Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Zustand herbeizuführen oderum einen nicht näher spezifizierten Angriff durchzuführen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2024-3497