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:39:41 +0000 https://cve.radiocsirt.org/vuln/bdu:2025-03125 bdu:2025-03125 https://cve.radiocsirt.org/vuln/bdu:2025-03125 https://cve.radiocsirt.org/vuln/bell-cve-2024-49878 <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-49878 https://cve.radiocsirt.org/vuln/certfr-2024-avi-0999 certfr-2024-avi-0999 https://cve.radiocsirt.org/vuln/certfr-2024-avi-0999 https://cve.radiocsirt.org/vuln/euvd-2026-313382 EUVD-2026-313382 https://cve.radiocsirt.org/vuln/euvd-2026-313382 https://cve.radiocsirt.org/vuln/fkie_cve-2024-49878 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>resource: fix region_intersects() vs add_memory_driver_managed()</p> <p>On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows.</p> <p>490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem)</p> <p>Because drivers/dax/kmem.c calls add_memory_driver_managed() during onlining CXL memory, which makes &#34;System RAM (kmem)&#34; a descendant of &#34;CXL Window X&#34;. This confuses region_intersects(), which expects all &#34;System RAM&#34; resources to be at the top level of iomem_resource. This can lead to bugs.</p> <p>For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem,</p> <p>$ dd if=data of=/dev/mem bs=$((1 &lt;&lt; 10)) seek=$((0x490000000 &gt;&gt; 10)) count=1 dd: error writing &#39;/dev/mem&#39;: Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/s</p> <p>the command fails as expected. However, the error code is wrong. It should be &#34;Operation not permitted&#34; instead of &#34;Bad address&#34;. More seriously, the /dev/mem permission checking in devmem_is_allowed() passes incorrectly. Although the accessing is prevented later because ioremap() isn&#39;t allowed to map system RAM, it is a potential security issue. During command executing, the following warning is reported in the kernel log for calling ioremap() on system RAM.</p> <p>ioremap on RAM at 0x00…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>resource: fix region_intersects() vs add_memory_driver_managed()</p> <p>On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows.</p> <p>490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem)</p> <p>Because drivers/dax/kmem.c calls add_memory_driver_managed() during onlining CXL memory, which makes &#34;System RAM (kmem)&#34; a descendant of &#34;CXL Window X&#34;. This confuses region_intersects(), which expects all &#34;System RAM&#34; resources to be at the top level of iomem_resource. This can lead to bugs.</p> <p>For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem,</p> <p>$ dd if=data of=/dev/mem bs=$((1 &lt;&lt; 10)) seek=$((0x490000000 &gt;&gt; 10)) count=1 dd: error writing &#39;/dev/mem&#39;: Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/s</p> <p>the command fails as expected. However, the error code is wrong. It should be &#34;Operation not permitted&#34; instead of &#34;Bad address&#34;. More seriously, the /dev/mem permission checking in devmem_is_allowed() passes incorrectly. Although the accessing is prevented later because ioremap() isn&#39;t allowed to map system RAM, it is a potential security issue. During command executing, the following warning is reported in the kernel log for calling ioremap() on system RAM.</p> <p>ioremap on RAM at 0x00…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2024-49878 https://cve.radiocsirt.org/vuln/ghsa-f3xx-63r9-v2cp <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>resource: fix region_intersects() vs add_memory_driver_managed()</p> <p>On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows.</p> <p>490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem)</p> <p>Because drivers/dax/kmem.c calls add_memory_driver_managed() during onlining CXL memory, which makes &#34;System RAM (kmem)&#34; a descendant of &#34;CXL Window X&#34;. This confuses region_intersects(), which expects all &#34;System RAM&#34; resources to be at the top level of iomem_resource. This can lead to bugs.</p> <p>For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem,</p> <p>$ dd if=data of=/dev/mem bs=$((1 &lt;&lt; 10)) seek=$((0x490000000 &gt;&gt; 10)) count=1 dd: error writing &#39;/dev/mem&#39;: Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/s</p> <p>the command fails as expected. However, the error code is wrong. It should be &#34;Operation not permitted&#34; instead of &#34;Bad address&#34;. More seriously, the /dev/mem permission checking in devmem_is_allowed() passes incorrectly. Although the accessing is prevented later because ioremap() isn&#39;t allowed to map system RAM, it is a potential security issue. During command executing, the following warning is reported in the kernel log for calling ioremap() on system RAM.</p> <p>ioremap on RAM at 0x00…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>resource: fix region_intersects() vs add_memory_driver_managed()</p> <p>On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows.</p> <p>490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem)</p> <p>Because drivers/dax/kmem.c calls add_memory_driver_managed() during onlining CXL memory, which makes &#34;System RAM (kmem)&#34; a descendant of &#34;CXL Window X&#34;. This confuses region_intersects(), which expects all &#34;System RAM&#34; resources to be at the top level of iomem_resource. This can lead to bugs.</p> <p>For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem,</p> <p>$ dd if=data of=/dev/mem bs=$((1 &lt;&lt; 10)) seek=$((0x490000000 &gt;&gt; 10)) count=1 dd: error writing &#39;/dev/mem&#39;: Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/s</p> <p>the command fails as expected. However, the error code is wrong. It should be &#34;Operation not permitted&#34; instead of &#34;Bad address&#34;. More seriously, the /dev/mem permission checking in devmem_is_allowed() passes incorrectly. Although the accessing is prevented later because ioremap() isn&#39;t allowed to map system RAM, it is a potential security issue. During command executing, the following warning is reported in the kernel log for calling ioremap() on system RAM.</p> <p>ioremap on RAM at 0x00…</p> https://cve.radiocsirt.org/vuln/ghsa-f3xx-63r9-v2cp 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-49878 msrc_CVE-2024-49878 https://cve.radiocsirt.org/vuln/msrc_cve-2024-49878 https://cve.radiocsirt.org/vuln/oesa-2024-2370 <p><strong>Affected:</strong> openEuler:20.03-LTS-SP4: kernel</p> <p>The Linux Kernel, the operating system core itself. Security Fix(es): In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: Prevent buffer overflow in setup handler Setup function uvc_function_setup permits control transfer requests with up to 64 bytes of payload (UVC_MAX_REQUEST_SIZE), data stage handler for OUT transfer uses memcpy to copy req-&amp;gt;actual bytes to uvc_event-&amp;gt;data.data array of size 60. This may result in an overflow of 4 bytes.(CVE-2022-48948) In the Linux kernel, the following vulnerability has been resolved: igb: Initialize mailbox message for VF reset When a MAC address is not assigned to the VF, that portion of the message sent to the VF is not set. The memory, however, is allocated from the stack meaning that information may be leaked to the VM. Initialize the message buffer to 0 so that no information is passed to the VM in this case.(CVE-2022-48949) In the Linux kernel, the following vulnerability has been resolved: net: hisilicon: Fix potential use-after-free in hix5hd2_rx() The skb is delivered to napi_gro_receive() which may free it, after calling this, dereferencing skb may trigger use-after-free.(CVE-2022-48960) In the Linux kernel, the following vulnerability has been resolved: net: hisilicon: Fix potential use-after-free in hisi_femac_rx() The skb is delivered to napi_gro_receive() which may free it, after calling this, dereferencing skb may trigger use-after-free.(CVE-2022-48962) In…</p> <p><strong>Affected:</strong> openEuler:20.03-LTS-SP4: kernel</p> <p>The Linux Kernel, the operating system core itself. Security Fix(es): In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: Prevent buffer overflow in setup handler Setup function uvc_function_setup permits control transfer requests with up to 64 bytes of payload (UVC_MAX_REQUEST_SIZE), data stage handler for OUT transfer uses memcpy to copy req-&amp;gt;actual bytes to uvc_event-&amp;gt;data.data array of size 60. This may result in an overflow of 4 bytes.(CVE-2022-48948) In the Linux kernel, the following vulnerability has been resolved: igb: Initialize mailbox message for VF reset When a MAC address is not assigned to the VF, that portion of the message sent to the VF is not set. The memory, however, is allocated from the stack meaning that information may be leaked to the VM. Initialize the message buffer to 0 so that no information is passed to the VM in this case.(CVE-2022-48949) In the Linux kernel, the following vulnerability has been resolved: net: hisilicon: Fix potential use-after-free in hix5hd2_rx() The skb is delivered to napi_gro_receive() which may free it, after calling this, dereferencing skb may trigger use-after-free.(CVE-2022-48960) In the Linux kernel, the following vulnerability has been resolved: net: hisilicon: Fix potential use-after-free in hisi_femac_rx() The skb is delivered to napi_gro_receive() which may free it, after calling this, dereferencing skb may trigger use-after-free.(CVE-2022-48962) In…</p> https://cve.radiocsirt.org/vuln/oesa-2024-2370 https://cve.radiocsirt.org/vuln/opensuse-su-2024:14500-1 <p>kernel-devel-6.11.8-1.1 on GA media</p> <p>kernel-devel-6.11.8-1.1 on GA media</p> https://cve.radiocsirt.org/vuln/opensuse-su-2024:14500-1 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:3984-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:3984-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-49878 <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 165 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: resource: fix region_intersects() vs add_memory_driver_managed() On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows. 490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem) Because drivers/dax/kmem.c calls add_memory_driver_managed() during onlining CXL memory, which makes &#34;System RAM (kmem)&#34; a descendant of &#34;CXL Window X&#34;. This confuses region_intersects(), which expects all &#34;System RAM&#34; resources to be at the top level of iomem_resource. This can lead to bugs. For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 &lt;&lt; 10)) seek=$((0x490000000 &gt;&gt; 10)) count=1 dd: error writing &#39;/dev/mem&#39;: Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/s the command fails as expected. However, the error code is wrong. It should be &#34;Operation not permitted&#34; instead of &#34;Bad address&#34;. More seriously, the /dev/mem permission checking in devmem_is_allowed() passes incorrectly. Although the accessing is prevented later because ioremap() isn&#39;t allowed to map system RAM, it is a potential security issue. During command executing, the following warning is reported in the kernel log for calling ioremap() on system RAM. ioremap on RAM at 0x0000000490…</p> <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 165 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: resource: fix region_intersects() vs add_memory_driver_managed() On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows. 490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem) Because drivers/dax/kmem.c calls add_memory_driver_managed() during onlining CXL memory, which makes &#34;System RAM (kmem)&#34; a descendant of &#34;CXL Window X&#34;. This confuses region_intersects(), which expects all &#34;System RAM&#34; resources to be at the top level of iomem_resource. This can lead to bugs. For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 &lt;&lt; 10)) seek=$((0x490000000 &gt;&gt; 10)) count=1 dd: error writing &#39;/dev/mem&#39;: Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/s the command fails as expected. However, the error code is wrong. It should be &#34;Operation not permitted&#34; instead of &#34;Bad address&#34;. More seriously, the /dev/mem permission checking in devmem_is_allowed() passes incorrectly. Although the accessing is prevented later because ioremap() isn&#39;t allowed to map system RAM, it is a potential security issue. During command executing, the following warning is reported in the kernel log for calling ioremap() on system RAM. ioremap on RAM at 0x0000000490…</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-49878 https://cve.radiocsirt.org/vuln/wid-sec-w-2024-3251 <p>Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere, nicht näher bekannte Auswirkungen zu erzielen..</p> <p>Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere, nicht näher bekannte Auswirkungen zu erzielen..</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2024-3251