<?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>Sun, 04 Oct 2026 08:37:59 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-01653</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-01653</link>
      <description>bdu:2025-01653</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-01653</guid>
    </item>
    <item>
      <title>BELL-CVE-2024-46846</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2024-46846</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-2024-46846</guid>
    </item>
    <item>
      <title>certfr-2024-avi-0837 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian. Elles permettent à un attaquant de provo…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2024-avi-0837</link>
      <description>certfr-2024-avi-0837</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2024-avi-0837</guid>
    </item>
    <item>
      <title>EUVD-2026-313312</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-313312</link>
      <description>EUVD-2026-313312</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-313312</guid>
    </item>
    <item>
      <title>fkie_cve-2024-46846</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2024-46846</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;spi: rockchip: Resolve unbalanced runtime PM / system PM handling&lt;/p&gt;
&lt;p&gt;Commit e882575efc77 (&amp;#34;spi: rockchip: Suspend and resume the bus during
NOIRQ_SYSTEM_SLEEP_PM ops&amp;#34;) stopped respecting runtime PM status and
simply disabled clocks unconditionally when suspending the system. This
causes problems when the device is already runtime suspended when we go
to sleep -- in which case we double-disable clocks and produce a
WARNing.&lt;/p&gt;
&lt;p&gt;Switch back to pm_runtime_force_{suspend,resume}(), because that still
seems like the right thing to do, and the aforementioned commit makes no
explanation why it stopped using it.&lt;/p&gt;
&lt;p&gt;Also, refactor some of the resume() error handling, because it&amp;#39;s not
actually a good idea to re-disable clocks on failure.&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;spi: rockchip: Resolve unbalanced runtime PM / system PM handling&lt;/p&gt;
&lt;p&gt;Commit e882575efc77 (&amp;#34;spi: rockchip: Suspend and resume the bus during
NOIRQ_SYSTEM_SLEEP_PM ops&amp;#34;) stopped respecting runtime PM status and
simply disabled clocks unconditionally when suspending the system. This
causes problems when the device is already runtime suspended when we go
to sleep -- in which case we double-disable clocks and produce a
WARNing.&lt;/p&gt;
&lt;p&gt;Switch back to pm_runtime_force_{suspend,resume}(), because that still
seems like the right thing to do, and the aforementioned commit makes no
explanation why it stopped using it.&lt;/p&gt;
&lt;p&gt;Also, refactor some of the resume() error handling, because it&amp;#39;s not
actually a good idea to re-disable clocks on failure.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2024-46846</guid>
    </item>
    <item>
      <title>GHSA-7h72-pm8j-jj46</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-7h72-pm8j-jj46</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;spi: rockchip: Resolve unbalanced runtime PM / system PM handling&lt;/p&gt;
&lt;p&gt;Commit e882575efc77 (&amp;#34;spi: rockchip: Suspend and resume the bus during
NOIRQ_SYSTEM_SLEEP_PM ops&amp;#34;) stopped respecting runtime PM status and
simply disabled clocks unconditionally when suspending the system. This
causes problems when the device is already runtime suspended when we go
to sleep -- in which case we double-disable clocks and produce a
WARNing.&lt;/p&gt;
&lt;p&gt;Switch back to pm_runtime_force_{suspend,resume}(), because that still
seems like the right thing to do, and the aforementioned commit makes no
explanation why it stopped using it.&lt;/p&gt;
&lt;p&gt;Also, refactor some of the resume() error handling, because it&amp;#39;s not
actually a good idea to re-disable clocks on failure.&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;spi: rockchip: Resolve unbalanced runtime PM / system PM handling&lt;/p&gt;
&lt;p&gt;Commit e882575efc77 (&amp;#34;spi: rockchip: Suspend and resume the bus during
NOIRQ_SYSTEM_SLEEP_PM ops&amp;#34;) stopped respecting runtime PM status and
simply disabled clocks unconditionally when suspending the system. This
causes problems when the device is already runtime suspended when we go
to sleep -- in which case we double-disable clocks and produce a
WARNing.&lt;/p&gt;
&lt;p&gt;Switch back to pm_runtime_force_{suspend,resume}(), because that still
seems like the right thing to do, and the aforementioned commit makes no
explanation why it stopped using it.&lt;/p&gt;
&lt;p&gt;Also, refactor some of the resume() error handling, because it&amp;#39;s not
actually a good idea to re-disable clocks on failure.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-7h72-pm8j-jj46</guid>
    </item>
    <item>
      <title>msrc_CVE-2024-46846 — spi: rockchip: Resolve unbalanced runtime PM / system PM handling</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2024-46846</link>
      <description>msrc_CVE-2024-46846</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2024-46846</guid>
    </item>
    <item>
      <title>OESA-2024-2219 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2024-2219</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):&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
bpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro()&#13;
&#13;
set_memory_rox() can fail, leaving memory unprotected.&#13;
&#13;
Check return and bail out when bpf_jit_binary_lock_ro() returns
an error.(CVE-2024-42067)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
sysctl: always initialize i_uid/i_gid&#13;
&#13;
Always initialize i_uid/i_gid inside the sysfs core so set_ownership()
can safely skip setting them.&#13;
&#13;
Commit 5ec27ec735ba (&amp;amp;quot;fs/proc/proc_sysctl.c: fix the default values of
i_uid/i_gid on /proc/sys inodes.&amp;amp;quot;) added defaults for i_uid/i_gid when
set_ownership() was not implemented. It also missed adjusting
net_ctl_set_ownership() to use the same default values in case the
computation of a better value failed.(CVE-2024-42312)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
parisc: fix a possible DMA corruption&#13;
&#13;
ARCH_DMA_MINALIGN was defined as 16 - this is too small - it may be
possible that two unrelated 16-byte allocations share a cache line. If
one of these allocations is written using DMA and the other is written
using cached write, the value that was written with DMA may be
corrupted.&#13;
&#13;
This commit changes ARCH_DMA_MINALIGN to be 128 on PA20 and 32 on PA1.1 -
that&amp;amp;apos;s the largest possible cache line size.&#13;
&#13;
As different parisc microarchitectur…&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):&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
bpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro()&#13;
&#13;
set_memory_rox() can fail, leaving memory unprotected.&#13;
&#13;
Check return and bail out when bpf_jit_binary_lock_ro() returns
an error.(CVE-2024-42067)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
sysctl: always initialize i_uid/i_gid&#13;
&#13;
Always initialize i_uid/i_gid inside the sysfs core so set_ownership()
can safely skip setting them.&#13;
&#13;
Commit 5ec27ec735ba (&amp;amp;quot;fs/proc/proc_sysctl.c: fix the default values of
i_uid/i_gid on /proc/sys inodes.&amp;amp;quot;) added defaults for i_uid/i_gid when
set_ownership() was not implemented. It also missed adjusting
net_ctl_set_ownership() to use the same default values in case the
computation of a better value failed.(CVE-2024-42312)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
parisc: fix a possible DMA corruption&#13;
&#13;
ARCH_DMA_MINALIGN was defined as 16 - this is too small - it may be
possible that two unrelated 16-byte allocations share a cache line. If
one of these allocations is written using DMA and the other is written
using cached write, the value that was written with DMA may be
corrupted.&#13;
&#13;
This commit changes ARCH_DMA_MINALIGN to be 128 on PA20 and 32 on PA1.1 -
that&amp;amp;apos;s the largest possible cache line size.&#13;
&#13;
As different parisc microarchitectur…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2024-2219</guid>
    </item>
    <item>
      <title>SUSE-SU-2024:3984-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2024:3984-1</link>
      <description>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/suse-su-2024:3984-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2024-46846</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-46846</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 89 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: spi: rockchip: Resolve unbalanced runtime PM / system PM handling Commit e882575efc77 (&amp;#34;spi: rockchip: Suspend and resume the bus during NOIRQ_SYSTEM_SLEEP_PM ops&amp;#34;) stopped respecting runtime PM status and simply disabled clocks unconditionally when suspending the system. This causes problems when the device is already runtime suspended when we go to sleep -- in which case we double-disable clocks and produce a WARNing. Switch back to pm_runtime_force_{suspend,resume}(), because that still seems like the right thing to do, and the aforementioned commit makes no explanation why it stopped using it. Also, refactor some of the resume() error handling, because it&amp;#39;s not actually a good idea to re-disable clocks on failure.&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 89 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: spi: rockchip: Resolve unbalanced runtime PM / system PM handling Commit e882575efc77 (&amp;#34;spi: rockchip: Suspend and resume the bus during NOIRQ_SYSTEM_SLEEP_PM ops&amp;#34;) stopped respecting runtime PM status and simply disabled clocks unconditionally when suspending the system. This causes problems when the device is already runtime suspended when we go to sleep -- in which case we double-disable clocks and produce a WARNing. Switch back to pm_runtime_force_{suspend,resume}(), because that still seems like the right thing to do, and the aforementioned commit makes no explanation why it stopped using it. Also, refactor some of the resume() error handling, because it&amp;#39;s not actually a good idea to re-disable clocks on failure.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-46846</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-3050 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-3050</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen und andere nicht spezifizierte Auswirkungen zu verursachen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen und andere nicht spezifizierte Auswirkungen zu verursachen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-3050</guid>
    </item>
  </channel>
</rss>
