<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Sat, 03 Oct 2026 17:53:12 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-11807</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-11807</link>
      <description>bdu:2025-11807</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-11807</guid>
    </item>
    <item>
      <title>BELL-CVE-2025-21694</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2025-21694</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2025-21694</guid>
    </item>
    <item>
      <title>certfr-2025-avi-0184 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian LTS. Elles permettent à un attaquant de p…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2025-avi-0184</link>
      <description>certfr-2025-avi-0184</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2025-avi-0184</guid>
    </item>
    <item>
      <title>EUVD-2026-320783</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-320783</link>
      <description>EUVD-2026-320783</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-320783</guid>
    </item>
    <item>
      <title>fkie_cve-2025-21694</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-21694</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;fs/proc: fix softlockup in __read_vmcore (part 2)&lt;/p&gt;
&lt;p&gt;Since commit 5cbcb62dddf5 (&amp;#34;fs/proc: fix softlockup in __read_vmcore&amp;#34;) the
number of softlockups in __read_vmcore at kdump time have gone down, but
they still happen sometimes.&lt;/p&gt;
&lt;p&gt;In a memory constrained environment like the kdump image, a softlockup is
not just a harmless message, but it can interfere with things like RCU
freeing memory, causing the crashdump to get stuck.&lt;/p&gt;
&lt;p&gt;The second loop in __read_vmcore has a lot more opportunities for natural
sleep points, like scheduling out while waiting for a data write to
happen, but apparently that is not always enough.&lt;/p&gt;
&lt;p&gt;Add a cond_resched() to the second loop in __read_vmcore to (hopefully)
get rid of the softlockups.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;fs/proc: fix softlockup in __read_vmcore (part 2)&lt;/p&gt;
&lt;p&gt;Since commit 5cbcb62dddf5 (&amp;#34;fs/proc: fix softlockup in __read_vmcore&amp;#34;) the
number of softlockups in __read_vmcore at kdump time have gone down, but
they still happen sometimes.&lt;/p&gt;
&lt;p&gt;In a memory constrained environment like the kdump image, a softlockup is
not just a harmless message, but it can interfere with things like RCU
freeing memory, causing the crashdump to get stuck.&lt;/p&gt;
&lt;p&gt;The second loop in __read_vmcore has a lot more opportunities for natural
sleep points, like scheduling out while waiting for a data write to
happen, but apparently that is not always enough.&lt;/p&gt;
&lt;p&gt;Add a cond_resched() to the second loop in __read_vmcore to (hopefully)
get rid of the softlockups.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-21694</guid>
    </item>
    <item>
      <title>GHSA-8mjp-767h-9569</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-8mjp-767h-9569</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;fs/proc: fix softlockup in __read_vmcore (part 2)&lt;/p&gt;
&lt;p&gt;Since commit 5cbcb62dddf5 (&amp;#34;fs/proc: fix softlockup in __read_vmcore&amp;#34;) the
number of softlockups in __read_vmcore at kdump time have gone down, but
they still happen sometimes.&lt;/p&gt;
&lt;p&gt;In a memory constrained environment like the kdump image, a softlockup is
not just a harmless message, but it can interfere with things like RCU
freeing memory, causing the crashdump to get stuck.&lt;/p&gt;
&lt;p&gt;The second loop in __read_vmcore has a lot more opportunities for natural
sleep points, like scheduling out while waiting for a data write to
happen, but apparently that is not always enough.&lt;/p&gt;
&lt;p&gt;Add a cond_resched() to the second loop in __read_vmcore to (hopefully)
get rid of the softlockups.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;fs/proc: fix softlockup in __read_vmcore (part 2)&lt;/p&gt;
&lt;p&gt;Since commit 5cbcb62dddf5 (&amp;#34;fs/proc: fix softlockup in __read_vmcore&amp;#34;) the
number of softlockups in __read_vmcore at kdump time have gone down, but
they still happen sometimes.&lt;/p&gt;
&lt;p&gt;In a memory constrained environment like the kdump image, a softlockup is
not just a harmless message, but it can interfere with things like RCU
freeing memory, causing the crashdump to get stuck.&lt;/p&gt;
&lt;p&gt;The second loop in __read_vmcore has a lot more opportunities for natural
sleep points, like scheduling out while waiting for a data write to
happen, but apparently that is not always enough.&lt;/p&gt;
&lt;p&gt;Add a cond_resched() to the second loop in __read_vmcore to (hopefully)
get rid of the softlockups.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-8mjp-767h-9569</guid>
    </item>
    <item>
      <title>ICSA-23-348-10 — Siemens SIMATIC S7-1500</title>
      <link>https://cve.radiocsirt.org/vuln/icsa-23-348-10</link>
      <description>&lt;p&gt;expat 2.1.0 and earlier does not properly handle entities expansion unless an application developer uses the XML_SetEntityDeclHandler function, which allows remote attackers to cause a denial of service (resource consumption), send HTTP requests to intranet servers, or read arbitrary files via a crafted XML document, aka an XML External Entity (XXE) issue.  NOTE: it could be argued that because expat already provides the ability to disable external entity expansion, the responsibility for resolving this issue lies with application developers; according to this argument, this entry should be REJECTed, and each affected application would need its own CVE. shadow: TOCTOU (time-of-check time-of-use) race condition when copying and removing directory trees run-mailcap in the Debian mime-support package before 3.52-1+deb7u1 allows context-dependent attackers to execute arbitrary commands via shell metacharacters in a filename. In Python (aka CPython) up to 3.10.8, the mailcap module does not add escape characters into commands discovered in the system mailcap file. This may allow attackers to inject shell commands into applications that call mailcap.findmatch with untrusted input (if they lack validation of user-provided filenames or arguments). The fix is also back-ported to 3.7, 3.8, 3.9 Use-after-free vulnerability in bzip2recover in bzip2 1.0.6 allows remote attackers to cause a denial of service (crash) via a crafted bzip2 file, related to block ends set to before the start o…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;expat 2.1.0 and earlier does not properly handle entities expansion unless an application developer uses the XML_SetEntityDeclHandler function, which allows remote attackers to cause a denial of service (resource consumption), send HTTP requests to intranet servers, or read arbitrary files via a crafted XML document, aka an XML External Entity (XXE) issue.  NOTE: it could be argued that because expat already provides the ability to disable external entity expansion, the responsibility for resolving this issue lies with application developers; according to this argument, this entry should be REJECTed, and each affected application would need its own CVE. shadow: TOCTOU (time-of-check time-of-use) race condition when copying and removing directory trees run-mailcap in the Debian mime-support package before 3.52-1+deb7u1 allows context-dependent attackers to execute arbitrary commands via shell metacharacters in a filename. In Python (aka CPython) up to 3.10.8, the mailcap module does not add escape characters into commands discovered in the system mailcap file. This may allow attackers to inject shell commands into applications that call mailcap.findmatch with untrusted input (if they lack validation of user-provided filenames or arguments). The fix is also back-ported to 3.7, 3.8, 3.9 Use-after-free vulnerability in bzip2recover in bzip2 1.0.6 allows remote attackers to cause a denial of service (crash) via a crafted bzip2 file, related to block ends set to before the start o…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/icsa-23-348-10</guid>
    </item>
    <item>
      <title>msrc_CVE-2025-21694 — fs/proc: fix softlockup in __read_vmcore (part 2)</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2025-21694</link>
      <description>msrc_CVE-2025-21694</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2025-21694</guid>
    </item>
    <item>
      <title>OESA-2025-1159 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2025-1159</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net: wwan: t7xx: Fix FSM command timeout issue&lt;/p&gt;
&lt;p&gt;When driver processes the internal state change command, it use an
asynchronous thread to process the command operation. If the main
thread detects that the task has timed out, the asynchronous thread
will panic when executing the completion notification because the
main thread completion object has been released.&lt;/p&gt;
&lt;p&gt;BUG: unable to handle page fault for address: fffffffffffffff8
PGD 1f283a067 P4D 1f283a067 PUD 1f283c067 PMD 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
RIP: 0010:complete_all+0x3e/0xa0
[...]
Call Trace:
 &amp;amp;lt;TASK&amp;amp;gt;
 ? __die_body+0x68/0xb0
 ? page_fault_oops+0x379/0x3e0
 ? exc_page_fault+0x69/0xa0
 ? asm_exc_page_fault+0x22/0x30
 ? complete_all+0x3e/0xa0
 fsm_main_thread+0xa3/0x9c0 [mtk_t7xx (HASH:1400 5)]
 ? __pfx_autoremove_wake_function+0x10/0x10
 kthread+0xd8/0x110
 ? __pfx_fsm_main_thread+0x10/0x10 [mtk_t7xx (HASH:1400 5)]
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x38/0x50
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1b/0x30
 &amp;amp;lt;/TASK&amp;amp;gt;
[...]
CR2: fffffffffffffff8
---[ end trace 0000000000000000 ]---&lt;/p&gt;
&lt;p&gt;Use the reference counter to ensure safe release as Sergey suggests:
https://lore.kernel.org/all/da90f64c-260a-4329-87bf-1f9ff20a5951@gmail.com/(CVE-2024-39282)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;i3c: mipi-i3c-hci: Mask ring interrupts bef…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net: wwan: t7xx: Fix FSM command timeout issue&lt;/p&gt;
&lt;p&gt;When driver processes the internal state change command, it use an
asynchronous thread to process the command operation. If the main
thread detects that the task has timed out, the asynchronous thread
will panic when executing the completion notification because the
main thread completion object has been released.&lt;/p&gt;
&lt;p&gt;BUG: unable to handle page fault for address: fffffffffffffff8
PGD 1f283a067 P4D 1f283a067 PUD 1f283c067 PMD 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
RIP: 0010:complete_all+0x3e/0xa0
[...]
Call Trace:
 &amp;amp;lt;TASK&amp;amp;gt;
 ? __die_body+0x68/0xb0
 ? page_fault_oops+0x379/0x3e0
 ? exc_page_fault+0x69/0xa0
 ? asm_exc_page_fault+0x22/0x30
 ? complete_all+0x3e/0xa0
 fsm_main_thread+0xa3/0x9c0 [mtk_t7xx (HASH:1400 5)]
 ? __pfx_autoremove_wake_function+0x10/0x10
 kthread+0xd8/0x110
 ? __pfx_fsm_main_thread+0x10/0x10 [mtk_t7xx (HASH:1400 5)]
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x38/0x50
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1b/0x30
 &amp;amp;lt;/TASK&amp;amp;gt;
[...]
CR2: fffffffffffffff8
---[ end trace 0000000000000000 ]---&lt;/p&gt;
&lt;p&gt;Use the reference counter to ensure safe release as Sergey suggests:
https://lore.kernel.org/all/da90f64c-260a-4329-87bf-1f9ff20a5951@gmail.com/(CVE-2024-39282)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;i3c: mipi-i3c-hci: Mask ring interrupts bef…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2025-1159</guid>
    </item>
    <item>
      <title>RHSA-2025:6966 — Red Hat Security Advisory: kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2025:6966</link>
      <description>&lt;p&gt;kernel: xen-netfront: Fix NULL sring after live migration kernel: fscache: Fix oops due to race with cookie_lru and use_cookie kernel: tracing: Free buffers when a used dynamic event is removed kernel: net: tun: Fix use-after-free in tun_detach() kernel: hwmon: (ibmpex) Fix possible UAF when ibmpex_register_bmc() fails kernel: erofs/zmap.c: Fix incorrect offset calculation kernel: arm64/mm: fix incorrect file_map_count for non-leaf pmd/pud kernel: s390: avoid using global register for current_stack_pointer kernel: erofs: fix missing xas_retry() in fscache mode kernel: rpmsg: qcom_smd: Fix refcount leak in qcom_smd_parse_edge kernel: remoteproc: k3-r5: Fix refcount leak in k3_r5_cluster_of_init kernel: of: check previous kernel&amp;#39;s ima-kexec-buffer against memory bounds kernel: coresight: Clear the connection field properly kernel: Linux kernel: Denial of Service in coresight: trbe kernel: rpmsg: char: Avoid double destroy of default endpoint kernel: coresight: cti: Fix hang in cti_disable_hw() kernel: lib/fonts: fix undefined behavior in bit shift for get_default_font kernel: Kernel: Denial of Service in pci_endpoint_test due to zero-length DMA mapping kernel: Linux kernel: Denial of Service in erofs due to memory leak kernel: erofs: fix missing unmap if z_erofs_get_extent_compressedlen() fails kernel: pipe: wakeup wr_wait after setting max_usage kernel: ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir() kernel: qed/qed_sriov: guard against NULL derefs from qed_…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel: xen-netfront: Fix NULL sring after live migration kernel: fscache: Fix oops due to race with cookie_lru and use_cookie kernel: tracing: Free buffers when a used dynamic event is removed kernel: net: tun: Fix use-after-free in tun_detach() kernel: hwmon: (ibmpex) Fix possible UAF when ibmpex_register_bmc() fails kernel: erofs/zmap.c: Fix incorrect offset calculation kernel: arm64/mm: fix incorrect file_map_count for non-leaf pmd/pud kernel: s390: avoid using global register for current_stack_pointer kernel: erofs: fix missing xas_retry() in fscache mode kernel: rpmsg: qcom_smd: Fix refcount leak in qcom_smd_parse_edge kernel: remoteproc: k3-r5: Fix refcount leak in k3_r5_cluster_of_init kernel: of: check previous kernel&amp;#39;s ima-kexec-buffer against memory bounds kernel: coresight: Clear the connection field properly kernel: Linux kernel: Denial of Service in coresight: trbe kernel: rpmsg: char: Avoid double destroy of default endpoint kernel: coresight: cti: Fix hang in cti_disable_hw() kernel: lib/fonts: fix undefined behavior in bit shift for get_default_font kernel: Kernel: Denial of Service in pci_endpoint_test due to zero-length DMA mapping kernel: Linux kernel: Denial of Service in erofs due to memory leak kernel: erofs: fix missing unmap if z_erofs_get_extent_compressedlen() fails kernel: pipe: wakeup wr_wait after setting max_usage kernel: ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir() kernel: qed/qed_sriov: guard against NULL derefs from qed_…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2025:6966</guid>
    </item>
    <item>
      <title>SSA-265688 — SSA-265688: Vulnerabilities in the additional GNU/Linux subsystem of the SIMATIC S7-1500 TM MFP V1.1</title>
      <link>https://cve.radiocsirt.org/vuln/ssa-265688</link>
      <description>&lt;p&gt;An out-of-bounds (OOB) memory write flaw was found in the NFSD in the Linux kernel. Missing sanity may lead to a write beyond bmval[bmlen-1] in nfsd4_decode_bitmap4 in fs/nfsd/nfs4xdr.c. In this flaw, a local attacker with user privilege may gain access to out-of-bounds memory, leading to a system integrity and confidentiality threat. fs/nfsd/trace.h in the Linux kernel before 5.13.4 might allow remote attackers to cause a denial of service (out-of-bounds read in strlen) by sending NFS traffic when the trace event framework is being used for nfsd. SUNRPC: null pointer dereference in svc_rqst_free(). When alloc_pages_node() returns null in svc_rqst_alloc(), the null rq_scratch_page pointer will be dereferenced when calling put_page() in svc_rqst_free(). NFSD: READDIR buffer overflow. If a client sends a READDIR count argument that is too small (say, zero), then the buffer size calculation in the new init_dirlist helper functions results in an underflow, allowing the XDR stream functions to write beyond the actual buffer. This calculation has always been suspect. NFSD has never sanity- checked the READDIR count argument, but the old entry encoders managed the problem correctly. With the commits below, entry encoding changed, exposing the underflow to the pointer arithmetic in xdr_reserve_space(). Modern NFS clients attempt to retrieve as much data as possible for each READDIR request. nfsd: NULL dereference in nfs3svc_encode_getaclres. A NULL pointer dereference vulnerability…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;An out-of-bounds (OOB) memory write flaw was found in the NFSD in the Linux kernel. Missing sanity may lead to a write beyond bmval[bmlen-1] in nfsd4_decode_bitmap4 in fs/nfsd/nfs4xdr.c. In this flaw, a local attacker with user privilege may gain access to out-of-bounds memory, leading to a system integrity and confidentiality threat. fs/nfsd/trace.h in the Linux kernel before 5.13.4 might allow remote attackers to cause a denial of service (out-of-bounds read in strlen) by sending NFS traffic when the trace event framework is being used for nfsd. SUNRPC: null pointer dereference in svc_rqst_free(). When alloc_pages_node() returns null in svc_rqst_alloc(), the null rq_scratch_page pointer will be dereferenced when calling put_page() in svc_rqst_free(). NFSD: READDIR buffer overflow. If a client sends a READDIR count argument that is too small (say, zero), then the buffer size calculation in the new init_dirlist helper functions results in an underflow, allowing the XDR stream functions to write beyond the actual buffer. This calculation has always been suspect. NFSD has never sanity- checked the READDIR count argument, but the old entry encoders managed the problem correctly. With the commits below, entry encoding changed, exposing the underflow to the pointer arithmetic in xdr_reserve_space(). Modern NFS clients attempt to retrieve as much data as possible for each READDIR request. nfsd: NULL dereference in nfs3svc_encode_getaclres. A NULL pointer dereference vulnerability…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ssa-265688</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2025-21694</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-21694</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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 160 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: fs/proc: fix softlockup in __read_vmcore (part 2) Since commit 5cbcb62dddf5 (&amp;#34;fs/proc: fix softlockup in __read_vmcore&amp;#34;) the number of softlockups in __read_vmcore at kdump time have gone down, but they still happen sometimes. In a memory constrained environment like the kdump image, a softlockup is not just a harmless message, but it can interfere with things like RCU freeing memory, causing the crashdump to get stuck. The second loop in __read_vmcore has a lot more opportunities for natural sleep points, like scheduling out while waiting for a data write to happen, but apparently that is not always enough. Add a cond_resched() to the second loop in __read_vmcore to (hopefully) get rid of the softlockups.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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 160 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: fs/proc: fix softlockup in __read_vmcore (part 2) Since commit 5cbcb62dddf5 (&amp;#34;fs/proc: fix softlockup in __read_vmcore&amp;#34;) the number of softlockups in __read_vmcore at kdump time have gone down, but they still happen sometimes. In a memory constrained environment like the kdump image, a softlockup is not just a harmless message, but it can interfere with things like RCU freeing memory, causing the crashdump to get stuck. The second loop in __read_vmcore has a lot more opportunities for natural sleep points, like scheduling out while waiting for a data write to happen, but apparently that is not always enough. Add a cond_resched() to the second loop in __read_vmcore to (hopefully) get rid of the softlockups.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-21694</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-0362 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-0362</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann diese Schwachstellen ausnutzen, um einen Denial-of-Service-Zustand oder andere nicht spezifizierte Effekte zu erzeugen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann diese Schwachstellen ausnutzen, um einen Denial-of-Service-Zustand oder andere nicht spezifizierte Effekte zu erzeugen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2025-0362</guid>
    </item>
  </channel>
</rss>
