<?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 13:32:20 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-13695</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-13695</link>
      <description>bdu:2025-13695</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-13695</guid>
    </item>
    <item>
      <title>EUVD-2026-309557</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-309557</link>
      <description>EUVD-2026-309557</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-309557</guid>
    </item>
    <item>
      <title>fkie_cve-2021-47128</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2021-47128</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;bpf, lockdown, audit: Fix buggy SELinux lockdown permission checks&lt;/p&gt;
&lt;p&gt;Commit 59438b46471a (&amp;#34;security,lockdown,selinux: implement SELinux lockdown&amp;#34;)
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:&lt;/p&gt;
&lt;p&gt;1) The audit events that are triggered due to calls to security_locked_down()
     can OOM kill a machine, see below details [0].&lt;/p&gt;
&lt;p&gt;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;amp; runqslower from bcc, for
     example, which make use of this tracepoint. Rough call sequence goes like:&lt;/p&gt;
&lt;p&gt;rq_lock(rq) -&amp;gt; -------------------------+
       trace_sched_switch() -&amp;gt;               |
         bpf_prog_xyz() -&amp;gt;                   +-&amp;gt; deadlock
           selinux_lockdown() -&amp;gt;             |
             audit_log_end() -&amp;gt;              |
               wake_up_interruptible() -&amp;gt;    |
                 try_to_wake_up() -&amp;gt;         |
                   rq_lock(rq) --------------+&lt;/p&gt;
&lt;p&gt;W…&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;bpf, lockdown, audit: Fix buggy SELinux lockdown permission checks&lt;/p&gt;
&lt;p&gt;Commit 59438b46471a (&amp;#34;security,lockdown,selinux: implement SELinux lockdown&amp;#34;)
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:&lt;/p&gt;
&lt;p&gt;1) The audit events that are triggered due to calls to security_locked_down()
     can OOM kill a machine, see below details [0].&lt;/p&gt;
&lt;p&gt;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;amp; runqslower from bcc, for
     example, which make use of this tracepoint. Rough call sequence goes like:&lt;/p&gt;
&lt;p&gt;rq_lock(rq) -&amp;gt; -------------------------+
       trace_sched_switch() -&amp;gt;               |
         bpf_prog_xyz() -&amp;gt;                   +-&amp;gt; deadlock
           selinux_lockdown() -&amp;gt;             |
             audit_log_end() -&amp;gt;              |
               wake_up_interruptible() -&amp;gt;    |
                 try_to_wake_up() -&amp;gt;         |
                   rq_lock(rq) --------------+&lt;/p&gt;
&lt;p&gt;W…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2021-47128</guid>
    </item>
    <item>
      <title>GHSA-cr4c-ww97-fphq</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-cr4c-ww97-fphq</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;bpf, lockdown, audit: Fix buggy SELinux lockdown permission checks&lt;/p&gt;
&lt;p&gt;Commit 59438b46471a (&amp;#34;security,lockdown,selinux: implement SELinux lockdown&amp;#34;)
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:&lt;/p&gt;
&lt;p&gt;1) The audit events that are triggered due to calls to security_locked_down()
     can OOM kill a machine, see below details [0].&lt;/p&gt;
&lt;p&gt;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;amp; runqslower from bcc, for
     example, which make use of this tracepoint. Rough call sequence goes like:&lt;/p&gt;
&lt;p&gt;rq_lock(rq) -&amp;gt; -------------------------+
       trace_sched_switch() -&amp;gt;               |
         bpf_prog_xyz() -&amp;gt;                   +-&amp;gt; deadlock
           selinux_lockdown() -&amp;gt;             |
             audit_log_end() -&amp;gt;              |
               wake_up_interruptible() -&amp;gt;    |
                 try_to_wake_up() -&amp;gt;         |
                   rq_lock(rq) --------------+&lt;/p&gt;
&lt;p&gt;W…&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;bpf, lockdown, audit: Fix buggy SELinux lockdown permission checks&lt;/p&gt;
&lt;p&gt;Commit 59438b46471a (&amp;#34;security,lockdown,selinux: implement SELinux lockdown&amp;#34;)
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:&lt;/p&gt;
&lt;p&gt;1) The audit events that are triggered due to calls to security_locked_down()
     can OOM kill a machine, see below details [0].&lt;/p&gt;
&lt;p&gt;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;amp; runqslower from bcc, for
     example, which make use of this tracepoint. Rough call sequence goes like:&lt;/p&gt;
&lt;p&gt;rq_lock(rq) -&amp;gt; -------------------------+
       trace_sched_switch() -&amp;gt;               |
         bpf_prog_xyz() -&amp;gt;                   +-&amp;gt; deadlock
           selinux_lockdown() -&amp;gt;             |
             audit_log_end() -&amp;gt;              |
               wake_up_interruptible() -&amp;gt;    |
                 try_to_wake_up() -&amp;gt;         |
                   rq_lock(rq) --------------+&lt;/p&gt;
&lt;p&gt;W…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-cr4c-ww97-fphq</guid>
    </item>
    <item>
      <title>gsd-2021-47128</title>
      <link>https://cve.radiocsirt.org/vuln/gsd-2021-47128</link>
      <description>gsd-2021-47128</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/gsd-2021-47128</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2021-47128</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-47128</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 54 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: bpf, lockdown, audit: Fix buggy SELinux lockdown permission checks Commit 59438b46471a (&amp;#34;security,lockdown,selinux: implement SELinux lockdown&amp;#34;) 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;amp; runqslower from bcc, for      example, which make use of this tracepoint. Rough call sequence goes like:      rq_lock(rq) -&amp;gt; -------------------------+        trace_sched_switch() -&amp;gt;               |          bpf_prog_xyz() -&amp;gt;                   +-&amp;gt; deadlock            selinux_lockdown() -&amp;gt;             |              audit_log_end() -&amp;gt;              |                wake_up_interruptible() -&amp;gt;    |                  try_to_wake_up() -&amp;gt;         |                    rq_lock(rq) --------------+ What&amp;#39;s…&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 54 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: bpf, lockdown, audit: Fix buggy SELinux lockdown permission checks Commit 59438b46471a (&amp;#34;security,lockdown,selinux: implement SELinux lockdown&amp;#34;) 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;amp; runqslower from bcc, for      example, which make use of this tracepoint. Rough call sequence goes like:      rq_lock(rq) -&amp;gt; -------------------------+        trace_sched_switch() -&amp;gt;               |          bpf_prog_xyz() -&amp;gt;                   +-&amp;gt; deadlock            selinux_lockdown() -&amp;gt;             |              audit_log_end() -&amp;gt;              |                wake_up_interruptible() -&amp;gt;    |                  try_to_wake_up() -&amp;gt;         |                    rq_lock(rq) --------------+ What&amp;#39;s…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-47128</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-0652 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-0652</link>
      <description>&lt;p&gt;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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-0652</guid>
    </item>
  </channel>
</rss>
