<?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>Fri, 09 Oct 2026 20:50:20 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-09643</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-09643</link>
      <description>bdu:2026-09643</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-09643</guid>
    </item>
    <item>
      <title>BELL-CVE-2025-39785</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2025-39785</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2025-39785</guid>
    </item>
    <item>
      <title>EUVD-2026-347201</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-347201</link>
      <description>EUVD-2026-347201</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-347201</guid>
    </item>
    <item>
      <title>fkie_cve-2025-39785</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-39785</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;drm/hisilicon/hibmc: fix irq_request()&amp;#39;s irq name variable is local&lt;/p&gt;
&lt;p&gt;The local variable is passed in request_irq (), and there will be use
after free problem, which will make request_irq failed. Using the global
irq name instead of it to fix.&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;drm/hisilicon/hibmc: fix irq_request()&amp;#39;s irq name variable is local&lt;/p&gt;
&lt;p&gt;The local variable is passed in request_irq (), and there will be use
after free problem, which will make request_irq failed. Using the global
irq name instead of it to fix.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-39785</guid>
    </item>
    <item>
      <title>GHSA-h39w-24rm-7gmr</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-h39w-24rm-7gmr</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;drm/hisilicon/hibmc: fix irq_request()&amp;#39;s irq name variable is local&lt;/p&gt;
&lt;p&gt;The local variable is passed in request_irq (), and there will be use
after free problem, which will make request_irq failed. Using the global
irq name instead of it to fix.&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;drm/hisilicon/hibmc: fix irq_request()&amp;#39;s irq name variable is local&lt;/p&gt;
&lt;p&gt;The local variable is passed in request_irq (), and there will be use
after free problem, which will make request_irq failed. Using the global
irq name instead of it to fix.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-h39w-24rm-7gmr</guid>
    </item>
    <item>
      <title>OESA-2025-2774 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2025-2774</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;mm: zswap: properly synchronize freeing resources during CPU hotunplug&lt;/p&gt;
&lt;p&gt;In zswap_compress() and zswap_decompress(), the per-CPU acomp_ctx of the
current CPU at the beginning of the operation is retrieved and used
throughout.  However, since neither preemption nor migration are disabled,
it is possible that the operation continues on a different CPU.&lt;/p&gt;
&lt;p&gt;If the original CPU is hotunplugged while the acomp_ctx is still in use,
we run into a UAF bug as some of the resources attached to the acomp_ctx
are freed during hotunplug in zswap_cpu_comp_dead() (i.e. 
acomp_ctx.buffer, acomp_ctx.req, or acomp_ctx.acomp).&lt;/p&gt;
&lt;p&gt;The problem was introduced in commit 1ec3b5fe6eec (&amp;amp;quot;mm/zswap: move to use
crypto_acomp API for hardware acceleration&amp;amp;quot;) when the switch to the
crypto_acomp API was made.  Prior to that, the per-CPU crypto_comp was
retrieved using get_cpu_ptr() which disables preemption and makes sure the
CPU cannot go away from under us.  Preemption cannot be disabled with the
crypto_acomp API as a sleepable context is needed.&lt;/p&gt;
&lt;p&gt;Use the acomp_ctx.mutex to synchronize CPU hotplug callbacks allocating
and freeing resources with compression/decompression paths.  Make sure
that acomp_ctx.req is NULL when the resources are freed.  In the
compression/decompression paths, check if acomp_ctx.req is NULL after
acquiring the mutex (meaning the CPU was…&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;mm: zswap: properly synchronize freeing resources during CPU hotunplug&lt;/p&gt;
&lt;p&gt;In zswap_compress() and zswap_decompress(), the per-CPU acomp_ctx of the
current CPU at the beginning of the operation is retrieved and used
throughout.  However, since neither preemption nor migration are disabled,
it is possible that the operation continues on a different CPU.&lt;/p&gt;
&lt;p&gt;If the original CPU is hotunplugged while the acomp_ctx is still in use,
we run into a UAF bug as some of the resources attached to the acomp_ctx
are freed during hotunplug in zswap_cpu_comp_dead() (i.e. 
acomp_ctx.buffer, acomp_ctx.req, or acomp_ctx.acomp).&lt;/p&gt;
&lt;p&gt;The problem was introduced in commit 1ec3b5fe6eec (&amp;amp;quot;mm/zswap: move to use
crypto_acomp API for hardware acceleration&amp;amp;quot;) when the switch to the
crypto_acomp API was made.  Prior to that, the per-CPU crypto_comp was
retrieved using get_cpu_ptr() which disables preemption and makes sure the
CPU cannot go away from under us.  Preemption cannot be disabled with the
crypto_acomp API as a sleepable context is needed.&lt;/p&gt;
&lt;p&gt;Use the acomp_ctx.mutex to synchronize CPU hotplug callbacks allocating
and freeing resources with compression/decompression paths.  Make sure
that acomp_ctx.req is NULL when the resources are freed.  In the
compression/decompression paths, check if acomp_ctx.req is NULL after
acquiring the mutex (meaning the CPU was…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2025-2774</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2025-39785</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-39785</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:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 79 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: drm/hisilicon/hibmc: fix irq_request()&amp;#39;s irq name variable is local The local variable is passed in request_irq (), and there will be use after free problem, which will make request_irq failed. Using the global irq name instead of it to fix.&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:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 79 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: drm/hisilicon/hibmc: fix irq_request()&amp;#39;s irq name variable is local The local variable is passed in request_irq (), and there will be use after free problem, which will make request_irq failed. Using the global irq name instead of it to fix.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-39785</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-2040 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2040</link>
      <description>&lt;p&gt;Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um Sicherheitsmechanismen zu umgehen, sowie einen Denial of Service Angriff oder andere nicht spezifizierte Angriffe durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um Sicherheitsmechanismen zu umgehen, sowie einen Denial of Service Angriff oder andere nicht spezifizierte Angriffe durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2040</guid>
    </item>
  </channel>
</rss>
