<?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-04T15:20:19.841386+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-13695</id>
    <title>bdu:2025-13695</title>
    <updated>2026-10-04T15:20:19.941353+00:00</updated>
    <content>bdu:2025-13695</content>
    <link href="https://cve.radiocsirt.org/vuln/bdu:2025-13695"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-309557</id>
    <title>EUVD-2026-309557</title>
    <updated>2026-10-04T15:20:19.941388+00:00</updated>
    <content>EUVD-2026-309557</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-309557"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2021-47128</id>
    <title>fkie_cve-2021-47128</title>
    <updated>2026-10-04T15:20:19.941402+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>bpf, lockdown, audit: Fix buggy SELinux lockdown permission checks</p>
<p>Commit 59438b46471a ("security,lockdown,selinux: implement SELinux lockdown")
added an implementation of the locked_down LSM hook to SELinux, with the aim
to restrict which domains are allowed to perform operations that would breach
lockdown. This is indirectly also getting audit subsystem involved to report
events. The latter is problematic, as reported by Ondrej and Serhei, since it
can bring down the whole system via audit:</p>
<p>1) The audit events that are triggered due to calls to security_locked_down()
     can OOM kill a machine, see below details [0].</p>
<p>2) It also seems to be causing a deadlock via avc_has_perm()/slow_avc_audit()
     when trying to wake up kauditd, for example, when using trace_sched_switch()
     tracepoint, see details in [1]. Triggering this was not via some hypothetical
     corner case, but with existing tools like runqlat &amp; runqslower from bcc, for
     example, which make use of this tracepoint. Rough call sequence goes like:</p>
<p>rq_lock(rq) -&gt; -------------------------+
       trace_sched_switch() -&gt;               |
         bpf_prog_xyz() -&gt;                   +-&gt; deadlock
           selinux_lockdown() -&gt;             |
             audit_log_end() -&gt;              |
               wake_up_interruptible() -&gt;    |
                 try_to_wake_up() -&gt;         |
                   rq_lock(rq) --------------+</p>
<p>W…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2021-47128"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-cr4c-ww97-fphq</id>
    <title>GHSA-cr4c-ww97-fphq</title>
    <updated>2026-10-04T15:20:19.941461+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>bpf, lockdown, audit: Fix buggy SELinux lockdown permission checks</p>
<p>Commit 59438b46471a ("security,lockdown,selinux: implement SELinux lockdown")
added an implementation of the locked_down LSM hook to SELinux, with the aim
to restrict which domains are allowed to perform operations that would breach
lockdown. This is indirectly also getting audit subsystem involved to report
events. The latter is problematic, as reported by Ondrej and Serhei, since it
can bring down the whole system via audit:</p>
<p>1) The audit events that are triggered due to calls to security_locked_down()
     can OOM kill a machine, see below details [0].</p>
<p>2) It also seems to be causing a deadlock via avc_has_perm()/slow_avc_audit()
     when trying to wake up kauditd, for example, when using trace_sched_switch()
     tracepoint, see details in [1]. Triggering this was not via some hypothetical
     corner case, but with existing tools like runqlat &amp; runqslower from bcc, for
     example, which make use of this tracepoint. Rough call sequence goes like:</p>
<p>rq_lock(rq) -&gt; -------------------------+
       trace_sched_switch() -&gt;               |
         bpf_prog_xyz() -&gt;                   +-&gt; deadlock
           selinux_lockdown() -&gt;             |
             audit_log_end() -&gt;              |
               wake_up_interruptible() -&gt;    |
                 try_to_wake_up() -&gt;         |
                   rq_lock(rq) --------------+</p>
<p>W…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-cr4c-ww97-fphq"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/gsd-2021-47128</id>
    <title>gsd-2021-47128</title>
    <updated>2026-10-04T15:20:19.941503+00:00</updated>
    <content>gsd-2021-47128</content>
    <link href="https://cve.radiocsirt.org/vuln/gsd-2021-47128"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-47128</id>
    <title>UBUNTU-CVE-2021-47128</title>
    <updated>2026-10-04T15:20:19.941516+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 54 more</p>
<p>In the Linux kernel, the following vulnerability has been resolved: bpf, lockdown, audit: Fix buggy SELinux lockdown permission checks Commit 59438b46471a ("security,lockdown,selinux: implement SELinux lockdown") added an implementation of the locked_down LSM hook to SELinux, with the aim to restrict which domains are allowed to perform operations that would breach lockdown. This is indirectly also getting audit subsystem involved to report events. The latter is problematic, as reported by Ondrej and Serhei, since it can bring down the whole system via audit:   1) The audit events that are triggered due to calls to security_locked_down()      can OOM kill a machine, see below details [0].   2) It also seems to be causing a deadlock via avc_has_perm()/slow_avc_audit()      when trying to wake up kauditd, for example, when using trace_sched_switch()      tracepoint, see details in [1]. Triggering this was not via some hypothetical      corner case, but with existing tools like runqlat &amp; runqslower from bcc, for      example, which make use of this tracepoint. Rough call sequence goes like:      rq_lock(rq) -&gt; -------------------------+        trace_sched_switch() -&gt;               |          bpf_prog_xyz() -&gt;                   +-&gt; deadlock            selinux_lockdown() -&gt;             |              audit_log_end() -&gt;              |                wake_up_interruptible() -&gt;    |                  try_to_wake_up() -&gt;         |                    rq_lock(rq) --------------+ What's…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-47128"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-0652</id>
    <title>WID-SEC-W-2024-0652 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service</title>
    <updated>2026-10-04T15:20:19.941635+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 oder einen nicht spezifizierten Angriff durchzuführen.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/wid-sec-w-2024-0652"/>
  </entry>
</feed>
