<?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-03T14:44:02.851425+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-03119</id>
    <title>bdu:2025-03119</title>
    <updated>2026-10-03T14:44:03.260567+00:00</updated>
    <content>bdu:2025-03119</content>
    <link href="https://cve.radiocsirt.org/vuln/bdu:2025-03119"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/bell-cve-2024-49856</id>
    <title>BELL-CVE-2024-49856</title>
    <updated>2026-10-03T14:44:03.260636+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-49856"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/certfr-2024-avi-1101</id>
    <title>certfr-2024-avi-1101 — 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-03T14:44:03.260671+00:00</updated>
    <content>certfr-2024-avi-1101</content>
    <link href="https://cve.radiocsirt.org/vuln/certfr-2024-avi-1101"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-313372</id>
    <title>EUVD-2026-313372</title>
    <updated>2026-10-03T14:44:03.260691+00:00</updated>
    <content>EUVD-2026-313372</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-313372"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2024-49856</id>
    <title>fkie_cve-2024-49856</title>
    <updated>2026-10-03T14:44:03.260702+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>x86/sgx: Fix deadlock in SGX NUMA node search</p>
<p>When the current node doesn't have an EPC section configured by firmware
and all other EPC sections are used up, CPU can get stuck inside the
while loop that looks for an available EPC page from remote nodes
indefinitely, leading to a soft lockup. Note how nid_of_current will
never be equal to nid in that while loop because nid_of_current is not
set in sgx_numa_mask.</p>
<p>Also worth mentioning is that it's perfectly fine for the firmware not
to setup an EPC section on a node. While setting up an EPC section on
each node can enhance performance, it is not a requirement for
functionality.</p>
<p>Rework the loop to start and end on *a* node that has SGX memory. This
avoids the deadlock looking for the current SGX-lacking node to show up
in the loop when it never will.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2024-49856"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-333m-q4jm-qjq4</id>
    <title>GHSA-333m-q4jm-qjq4</title>
    <updated>2026-10-03T14:44:03.260737+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>x86/sgx: Fix deadlock in SGX NUMA node search</p>
<p>When the current node doesn't have an EPC section configured by firmware
and all other EPC sections are used up, CPU can get stuck inside the
while loop that looks for an available EPC page from remote nodes
indefinitely, leading to a soft lockup. Note how nid_of_current will
never be equal to nid in that while loop because nid_of_current is not
set in sgx_numa_mask.</p>
<p>Also worth mentioning is that it's perfectly fine for the firmware not
to setup an EPC section on a node. While setting up an EPC section on
each node can enhance performance, it is not a requirement for
functionality.</p>
<p>Rework the loop to start and end on *a* node that has SGX memory. This
avoids the deadlock looking for the current SGX-lacking node to show up
in the loop when it never will.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-333m-q4jm-qjq4"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/msrc_cve-2024-49856</id>
    <title>msrc_CVE-2024-49856 — x86/sgx: Fix deadlock in SGX NUMA node search</title>
    <updated>2026-10-03T14:44:03.260761+00:00</updated>
    <content>msrc_CVE-2024-49856</content>
    <link href="https://cve.radiocsirt.org/vuln/msrc_cve-2024-49856"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/oesa-2024-2492</id>
    <title>OESA-2024-2492 — kernel security update</title>
    <updated>2026-10-03T14:44:03.260778+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: support non-r10 register spill/fill to/from stack in precision tracking  Use instruction (jump) history to record instructions that performed register spill/fill to/from stack, regardless if this was done through read-only r10 register, or any other register after copying r10 into it *and* potentially adjusting offset.  To make this work reliably, we push extra per-instruction flags into instruction history, encoding stack slot index (spi) and stack frame number in extra 10 bit flags we take away from prev_idx in instruction history. We don&amp;apos;t touch idx field for maximum performance, as it&amp;apos;s checked most frequently during backtracking.  This change removes basically the last remaining practical limitation of precision backtracking logic in BPF verifier. It fixes known deficiencies, but also opens up new opportunities to reduce number of verified states, explored in the subsequent patches.  There are only three differences in selftests&amp;apos; BPF object files according to veristat, all in the positive direction (less states).  File                                    Program        Insns (A)  Insns (B)  Insns  (DIFF)  States (A)  States (B)  States (DIFF) --------------------------------------  -------------  ---------  ---------  -------------  ----------  ----------  ------------- test_cls_redirect_dynptr.bpf.linked3.o…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/oesa-2024-2492"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/opensuse-su-2024:14500-1</id>
    <title>openSUSE-SU-2024:14500-1 — kernel-devel-6.11.8-1.1 on GA media</title>
    <updated>2026-10-03T14:44:03.261310+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>kernel-devel-6.11.8-1.1 on GA media</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/opensuse-su-2024:14500-1"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-49856</id>
    <title>UBUNTU-CVE-2024-49856</title>
    <updated>2026-10-03T14:44:03.261597+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 137 more</p>
<p>In the Linux kernel, the following vulnerability has been resolved: x86/sgx: Fix deadlock in SGX NUMA node search When the current node doesn't have an EPC section configured by firmware and all other EPC sections are used up, CPU can get stuck inside the while loop that looks for an available EPC page from remote nodes indefinitely, leading to a soft lockup. Note how nid_of_current will never be equal to nid in that while loop because nid_of_current is not set in sgx_numa_mask. Also worth mentioning is that it's perfectly fine for the firmware not to setup an EPC section on a node. While setting up an EPC section on each node can enhance performance, it is not a requirement for functionality. Rework the loop to start and end on *a* node that has SGX memory. This avoids the deadlock looking for the current SGX-lacking node to show up in the loop when it never will.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-49856"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-3251</id>
    <title>WID-SEC-W-2024-3251 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service</title>
    <updated>2026-10-03T14:44:03.261796+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere, nicht näher bekannte Auswirkungen zu erzielen..</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/wid-sec-w-2024-3251"/>
  </entry>
</feed>
