<?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-03T02:40:56.394505+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-00535</id>
    <title>bdu:2025-00535</title>
    <updated>2026-10-03T02:40:56.751300+00:00</updated>
    <content>bdu:2025-00535</content>
    <link href="https://cve.radiocsirt.org/vuln/bdu:2025-00535"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/bell-cve-2024-53152</id>
    <title>BELL-CVE-2024-53152</title>
    <updated>2026-10-03T02:40:56.751339+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p><strong>Affected:</strong> Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/bell-cve-2024-53152"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/certfr-2025-avi-0152</id>
    <title>certfr-2025-avi-0152 — De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Certaines d'entre elles permettent à un a…</title>
    <updated>2026-10-03T02:40:56.751370+00:00</updated>
    <content>certfr-2025-avi-0152</content>
    <link href="https://cve.radiocsirt.org/vuln/certfr-2025-avi-0152"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-313630</id>
    <title>EUVD-2026-313630</title>
    <updated>2026-10-03T02:40:56.751388+00:00</updated>
    <content>EUVD-2026-313630</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-313630"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2024-53152</id>
    <title>fkie_cve-2024-53152</title>
    <updated>2026-10-03T02:40:56.751399+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>PCI: tegra194: Move controller cleanups to pex_ep_event_pex_rst_deassert()</p>
<p>Currently, the endpoint cleanup function dw_pcie_ep_cleanup() and EPF
deinit notify function pci_epc_deinit_notify() are called during the
execution of pex_ep_event_pex_rst_assert() i.e., when the host has asserted
PERST#. But quickly after this step, refclk will also be disabled by the
host.</p>
<p>All of the tegra194 endpoint SoCs supported as of now depend on the refclk
from the host for keeping the controller operational. Due to this
limitation, any access to the hardware registers in the absence of refclk
will result in a whole endpoint crash. Unfortunately, most of the
controller cleanups require accessing the hardware registers (like eDMA
cleanup performed in dw_pcie_ep_cleanup(), etc...). So these cleanup
functions can cause the crash in the endpoint SoC once host asserts PERST#.</p>
<p>One way to address this issue is by generating the refclk in the endpoint
itself and not depending on the host. But that is not always possible as
some of the endpoint designs do require the endpoint to consume refclk from
the host.</p>
<p>Thus, fix this crash by moving the controller cleanups to the start of
the pex_ep_event_pex_rst_deassert() function. This function is called
whenever the host has deasserted PERST# and it is guaranteed that the
refclk would be active at this point. So at the start of this function
(after enabling resources) the controller cl…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2024-53152"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-vhcm-pjgm-q2wv</id>
    <title>GHSA-vhcm-pjgm-q2wv</title>
    <updated>2026-10-03T02:40:56.751442+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>PCI: tegra194: Move controller cleanups to pex_ep_event_pex_rst_deassert()</p>
<p>Currently, the endpoint cleanup function dw_pcie_ep_cleanup() and EPF
deinit notify function pci_epc_deinit_notify() are called during the
execution of pex_ep_event_pex_rst_assert() i.e., when the host has asserted
PERST#. But quickly after this step, refclk will also be disabled by the
host.</p>
<p>All of the tegra194 endpoint SoCs supported as of now depend on the refclk
from the host for keeping the controller operational. Due to this
limitation, any access to the hardware registers in the absence of refclk
will result in a whole endpoint crash. Unfortunately, most of the
controller cleanups require accessing the hardware registers (like eDMA
cleanup performed in dw_pcie_ep_cleanup(), etc...). So these cleanup
functions can cause the crash in the endpoint SoC once host asserts PERST#.</p>
<p>One way to address this issue is by generating the refclk in the endpoint
itself and not depending on the host. But that is not always possible as
some of the endpoint designs do require the endpoint to consume refclk from
the host.</p>
<p>Thus, fix this crash by moving the controller cleanups to the start of
the pex_ep_event_pex_rst_deassert() function. This function is called
whenever the host has deasserted PERST# and it is guaranteed that the
refclk would be active at this point. So at the start of this function
(after enabling resources) the controller cl…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-vhcm-pjgm-q2wv"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/rhsa-2025:6966</id>
    <title>RHSA-2025:6966 — Red Hat Security Advisory: kernel security update</title>
    <updated>2026-10-03T02:40:56.751472+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>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'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_…</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/rhsa-2025:6966"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-53152</id>
    <title>UBUNTU-CVE-2024-53152</title>
    <updated>2026-10-03T02:40:56.752075+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 70 more</p>
<p>In the Linux kernel, the following vulnerability has been resolved: PCI: tegra194: Move controller cleanups to pex_ep_event_pex_rst_deassert() Currently, the endpoint cleanup function dw_pcie_ep_cleanup() and EPF deinit notify function pci_epc_deinit_notify() are called during the execution of pex_ep_event_pex_rst_assert() i.e., when the host has asserted PERST#. But quickly after this step, refclk will also be disabled by the host. All of the tegra194 endpoint SoCs supported as of now depend on the refclk from the host for keeping the controller operational. Due to this limitation, any access to the hardware registers in the absence of refclk will result in a whole endpoint crash. Unfortunately, most of the controller cleanups require accessing the hardware registers (like eDMA cleanup performed in dw_pcie_ep_cleanup(), etc...). So these cleanup functions can cause the crash in the endpoint SoC once host asserts PERST#. One way to address this issue is by generating the refclk in the endpoint itself and not depending on the host. But that is not always possible as some of the endpoint designs do require the endpoint to consume refclk from the host. Thus, fix this crash by moving the controller cleanups to the start of the pex_ep_event_pex_rst_deassert() function. This function is called whenever the host has deasserted PERST# and it is guaranteed that the refclk would be active at this point. So at the start of this function (after enabling resources) the controller cleanup…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-53152"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-3756</id>
    <title>WID-SEC-W-2024-3756 — Linux Kernel: Mehrere Schwachstellen</title>
    <updated>2026-10-03T02:40:56.752243+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Zustand herbeizuführen, Daten zu manipulieren oder nicht näher spezifizierte Auswirkungen zu erzielen.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/wid-sec-w-2024-3756"/>
  </entry>
</feed>
