<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-04T04:07:54.776112+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/bdu:2025-01653</id>
    <title>bdu:2025-01653</title>
    <updated>2026-10-04T04:07:55.589547+00:00</updated>
    <content>bdu:2025-01653</content>
    <link href="https://cve.radiocsirt.org/vuln/bdu:2025-01653"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/bell-cve-2024-46846</id>
    <title>BELL-CVE-2024-46846</title>
    <updated>2026-10-04T04:07:55.589663+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/bell-cve-2024-46846"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/certfr-2024-avi-0837</id>
    <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>
    <updated>2026-10-04T04:07:55.589736+00:00</updated>
    <content>certfr-2024-avi-0837</content>
    <link href="https://cve.radiocsirt.org/vuln/certfr-2024-avi-0837"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-313312</id>
    <title>EUVD-2026-313312</title>
    <updated>2026-10-04T04:07:55.589778+00:00</updated>
    <content>EUVD-2026-313312</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-313312"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2024-46846</id>
    <title>fkie_cve-2024-46846</title>
    <updated>2026-10-04T04:07:55.589803+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>spi: rockchip: Resolve unbalanced runtime PM / system PM handling</p>
<p>Commit e882575efc77 ("spi: rockchip: Suspend and resume the bus during
NOIRQ_SYSTEM_SLEEP_PM ops") 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.</p>
<p>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.</p>
<p>Also, refactor some of the resume() error handling, because it's not
actually a good idea to re-disable clocks on failure.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2024-46846"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-7h72-pm8j-jj46</id>
    <title>GHSA-7h72-pm8j-jj46</title>
    <updated>2026-10-04T04:07:55.589856+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>spi: rockchip: Resolve unbalanced runtime PM / system PM handling</p>
<p>Commit e882575efc77 ("spi: rockchip: Suspend and resume the bus during
NOIRQ_SYSTEM_SLEEP_PM ops") 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.</p>
<p>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.</p>
<p>Also, refactor some of the resume() error handling, because it's not
actually a good idea to re-disable clocks on failure.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-7h72-pm8j-jj46"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/msrc_cve-2024-46846</id>
    <title>msrc_CVE-2024-46846 — spi: rockchip: Resolve unbalanced runtime PM / system PM handling</title>
    <updated>2026-10-04T04:07:55.589892+00:00</updated>
    <content>msrc_CVE-2024-46846</content>
    <link href="https://cve.radiocsirt.org/vuln/msrc_cve-2024-46846"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/oesa-2024-2219</id>
    <title>OESA-2024-2219 — kernel security update</title>
    <updated>2026-10-04T04:07:55.589932+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><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:

bpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro()

set_memory_rox() can fail, leaving memory unprotected.

Check return and bail out when bpf_jit_binary_lock_ro() returns
an error.(CVE-2024-42067)

In the Linux kernel, the following vulnerability has been resolved:

sysctl: always initialize i_uid/i_gid

Always initialize i_uid/i_gid inside the sysfs core so set_ownership()
can safely skip setting them.

Commit 5ec27ec735ba (&amp;quot;fs/proc/proc_sysctl.c: fix the default values of
i_uid/i_gid on /proc/sys inodes.&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)

In the Linux kernel, the following vulnerability has been resolved:

parisc: fix a possible DMA corruption

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.

This commit changes ARCH_DMA_MINALIGN to be 128 on PA20 and 32 on PA1.1 -
that&amp;apos;s the largest possible cache line size.

As different parisc microarchitectur…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/oesa-2024-2219"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/suse-su-2024:3984-1</id>
    <title>SUSE-SU-2024:3984-1 — Security update for the Linux Kernel</title>
    <updated>2026-10-04T04:07:55.590816+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Security update for the Linux Kernel</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/suse-su-2024:3984-1"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-46846</id>
    <title>UBUNTU-CVE-2024-46846</title>
    <updated>2026-10-04T04:07:55.591129+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><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: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</p>
<p>In the Linux kernel, the following vulnerability has been resolved: spi: rockchip: Resolve unbalanced runtime PM / system PM handling Commit e882575efc77 ("spi: rockchip: Suspend and resume the bus during NOIRQ_SYSTEM_SLEEP_PM ops") 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's not actually a good idea to re-disable clocks on failure.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-46846"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-3050</id>
    <title>WID-SEC-W-2024-3050 — Linux Kernel: Mehrere Schwachstellen</title>
    <updated>2026-10-04T04:07:55.591468+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>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.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/wid-sec-w-2024-3050"/>
  </entry>
</feed>
