<?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>Fri, 02 Oct 2026 14:16:40 +0000</lastBuildDate>
    <item>
      <title>ALSA-2026:3083 — Important: kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/alsa-2026:3083</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; AlmaLinux:8: bpftool, AlmaLinux:8: kernel, AlmaLinux:8: kernel-abi-stablelists, AlmaLinux:8: kernel-core, AlmaLinux:8: kernel-cross-headers, AlmaLinux:8: kernel-debug, AlmaLinux:8: kernel-debug-core, AlmaLinux:8: kernel-debug-devel, AlmaLinux:8: kernel-debug-modules, AlmaLinux:8: kernel-debug-modules-extra and 15 more&lt;/p&gt;
&lt;p&gt;The kernel packages contain the Linux kernel, the core of any Linux operating system.&lt;/p&gt;
&lt;p&gt;Security Fix(es):&lt;/p&gt;
&lt;p&gt;* kernel: page_pool: Fix use-after-free in page_pool_recycle_in_ring (CVE-2025-38129)
  * kernel: Linux kernel:A use-after-free in bridge multicast in br_multicast_port_ctx_init (CVE-2025-38248)
  * kernel: smc: Fix use-after-free in __pnet_find_base_ndev() (CVE-2025-40064)
  * kernel: mlxsw: spectrum_mr: Fix use-after-free when updating multicast route stats (CVE-2025-68800)
  * kernel: Linux kernel: Use-after-free in teql queueing discipline can lead to privilege escalation (CVE-2026-23074)&lt;/p&gt;
&lt;p&gt;For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; AlmaLinux:8: bpftool, AlmaLinux:8: kernel, AlmaLinux:8: kernel-abi-stablelists, AlmaLinux:8: kernel-core, AlmaLinux:8: kernel-cross-headers, AlmaLinux:8: kernel-debug, AlmaLinux:8: kernel-debug-core, AlmaLinux:8: kernel-debug-devel, AlmaLinux:8: kernel-debug-modules, AlmaLinux:8: kernel-debug-modules-extra and 15 more&lt;/p&gt;
&lt;p&gt;The kernel packages contain the Linux kernel, the core of any Linux operating system.&lt;/p&gt;
&lt;p&gt;Security Fix(es):&lt;/p&gt;
&lt;p&gt;* kernel: page_pool: Fix use-after-free in page_pool_recycle_in_ring (CVE-2025-38129)
  * kernel: Linux kernel:A use-after-free in bridge multicast in br_multicast_port_ctx_init (CVE-2025-38248)
  * kernel: smc: Fix use-after-free in __pnet_find_base_ndev() (CVE-2025-40064)
  * kernel: mlxsw: spectrum_mr: Fix use-after-free when updating multicast route stats (CVE-2025-68800)
  * kernel: Linux kernel: Use-after-free in teql queueing discipline can lead to privilege escalation (CVE-2026-23074)&lt;/p&gt;
&lt;p&gt;For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/alsa-2026:3083</guid>
    </item>
    <item>
      <title>bdu:2026-06705</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-06705</link>
      <description>bdu:2026-06705</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-06705</guid>
    </item>
    <item>
      <title>BELL-CVE-2026-23074</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-23074</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2026-23074</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0166 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian. Elles permettent à un attaquant de provo…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0166</link>
      <description>certfr-2026-avi-0166</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0166</guid>
    </item>
    <item>
      <title>EUVD-2026-370204</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-370204</link>
      <description>EUVD-2026-370204</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-370204</guid>
    </item>
    <item>
      <title>fkie_cve-2026-23074</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-23074</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net/sched: Enforce that teql can only be used as root qdisc&lt;/p&gt;
&lt;p&gt;Design intent of teql is that it is only supposed to be used as root qdisc.
We need to check for that constraint.&lt;/p&gt;
&lt;p&gt;Although not important, I will describe the scenario that unearthed this
issue for the curious.&lt;/p&gt;
&lt;p&gt;GangMin Kim &amp;lt;km.kim1503@gmail.com&amp;gt; managed to concot a scenario as follows:&lt;/p&gt;
&lt;p&gt;ROOT qdisc 1:0 (QFQ)
  ├── class 1:1 (weight=15, lmax=16384) netem with delay 6.4s
  └── class 1:2 (weight=1, lmax=1514) teql&lt;/p&gt;
&lt;p&gt;GangMin sends a packet which is enqueued to 1:1 (netem).
Any invocation of dequeue by QFQ from this class will not return a packet
until after 6.4s. In the meantime, a second packet is sent and it lands on
1:2. teql&amp;#39;s enqueue will return success and this will activate class 1:2.
Main issue is that teql only updates the parent visible qlen (sch-&amp;gt;q.qlen)
at dequeue. Since QFQ will only call dequeue if peek succeeds (and teql&amp;#39;s
peek always returns NULL), dequeue will never be called and thus the qlen
will remain as 0. With that in mind, when GangMin updates 1:2&amp;#39;s lmax value,
the qfq_change_class calls qfq_deact_rm_from_agg. Since the child qdisc&amp;#39;s
qlen was not incremented, qfq fails to deactivate the class, but still
frees its pointers from the aggregate. So when the first packet is
rescheduled after 6.4 seconds (netem&amp;#39;s delay), a dangling pointer is
accessed causing GangMin&amp;#39;s causing a UAF.&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;net/sched: Enforce that teql can only be used as root qdisc&lt;/p&gt;
&lt;p&gt;Design intent of teql is that it is only supposed to be used as root qdisc.
We need to check for that constraint.&lt;/p&gt;
&lt;p&gt;Although not important, I will describe the scenario that unearthed this
issue for the curious.&lt;/p&gt;
&lt;p&gt;GangMin Kim &amp;lt;km.kim1503@gmail.com&amp;gt; managed to concot a scenario as follows:&lt;/p&gt;
&lt;p&gt;ROOT qdisc 1:0 (QFQ)
  ├── class 1:1 (weight=15, lmax=16384) netem with delay 6.4s
  └── class 1:2 (weight=1, lmax=1514) teql&lt;/p&gt;
&lt;p&gt;GangMin sends a packet which is enqueued to 1:1 (netem).
Any invocation of dequeue by QFQ from this class will not return a packet
until after 6.4s. In the meantime, a second packet is sent and it lands on
1:2. teql&amp;#39;s enqueue will return success and this will activate class 1:2.
Main issue is that teql only updates the parent visible qlen (sch-&amp;gt;q.qlen)
at dequeue. Since QFQ will only call dequeue if peek succeeds (and teql&amp;#39;s
peek always returns NULL), dequeue will never be called and thus the qlen
will remain as 0. With that in mind, when GangMin updates 1:2&amp;#39;s lmax value,
the qfq_change_class calls qfq_deact_rm_from_agg. Since the child qdisc&amp;#39;s
qlen was not incremented, qfq fails to deactivate the class, but still
frees its pointers from the aggregate. So when the first packet is
rescheduled after 6.4 seconds (netem&amp;#39;s delay), a dangling pointer is
accessed causing GangMin&amp;#39;s causing a UAF.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-23074</guid>
    </item>
    <item>
      <title>GHSA-7cwq-2xv8-7cqw</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-7cwq-2xv8-7cqw</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net/sched: Enforce that teql can only be used as root qdisc&lt;/p&gt;
&lt;p&gt;Design intent of teql is that it is only supposed to be used as root qdisc.
We need to check for that constraint.&lt;/p&gt;
&lt;p&gt;Although not important, I will describe the scenario that unearthed this
issue for the curious.&lt;/p&gt;
&lt;p&gt;GangMin Kim &amp;lt;km.kim1503@gmail.com&amp;gt; managed to concot a scenario as follows:&lt;/p&gt;
&lt;p&gt;ROOT qdisc 1:0 (QFQ)
  ├── class 1:1 (weight=15, lmax=16384) netem with delay 6.4s
  └── class 1:2 (weight=1, lmax=1514) teql&lt;/p&gt;
&lt;p&gt;GangMin sends a packet which is enqueued to 1:1 (netem).
Any invocation of dequeue by QFQ from this class will not return a packet
until after 6.4s. In the meantime, a second packet is sent and it lands on
1:2. teql&amp;#39;s enqueue will return success and this will activate class 1:2.
Main issue is that teql only updates the parent visible qlen (sch-&amp;gt;q.qlen)
at dequeue. Since QFQ will only call dequeue if peek succeeds (and teql&amp;#39;s
peek always returns NULL), dequeue will never be called and thus the qlen
will remain as 0. With that in mind, when GangMin updates 1:2&amp;#39;s lmax value,
the qfq_change_class calls qfq_deact_rm_from_agg. Since the child qdisc&amp;#39;s
qlen was not incremented, qfq fails to deactivate the class, but still
frees its pointers from the aggregate. So when the first packet is
rescheduled after 6.4 seconds (netem&amp;#39;s delay), a dangling pointer is
accessed causing GangMin&amp;#39;s causing a UAF.&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;net/sched: Enforce that teql can only be used as root qdisc&lt;/p&gt;
&lt;p&gt;Design intent of teql is that it is only supposed to be used as root qdisc.
We need to check for that constraint.&lt;/p&gt;
&lt;p&gt;Although not important, I will describe the scenario that unearthed this
issue for the curious.&lt;/p&gt;
&lt;p&gt;GangMin Kim &amp;lt;km.kim1503@gmail.com&amp;gt; managed to concot a scenario as follows:&lt;/p&gt;
&lt;p&gt;ROOT qdisc 1:0 (QFQ)
  ├── class 1:1 (weight=15, lmax=16384) netem with delay 6.4s
  └── class 1:2 (weight=1, lmax=1514) teql&lt;/p&gt;
&lt;p&gt;GangMin sends a packet which is enqueued to 1:1 (netem).
Any invocation of dequeue by QFQ from this class will not return a packet
until after 6.4s. In the meantime, a second packet is sent and it lands on
1:2. teql&amp;#39;s enqueue will return success and this will activate class 1:2.
Main issue is that teql only updates the parent visible qlen (sch-&amp;gt;q.qlen)
at dequeue. Since QFQ will only call dequeue if peek succeeds (and teql&amp;#39;s
peek always returns NULL), dequeue will never be called and thus the qlen
will remain as 0. With that in mind, when GangMin updates 1:2&amp;#39;s lmax value,
the qfq_change_class calls qfq_deact_rm_from_agg. Since the child qdisc&amp;#39;s
qlen was not incremented, qfq fails to deactivate the class, but still
frees its pointers from the aggregate. So when the first packet is
rescheduled after 6.4 seconds (netem&amp;#39;s delay), a dangling pointer is
accessed causing GangMin&amp;#39;s causing a UAF.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-7cwq-2xv8-7cqw</guid>
    </item>
    <item>
      <title>OESA-2026-2580 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2026-2580</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP4: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;iomap: Fix possible overflow condition in iomap_write_delalloc_scan&lt;/p&gt;
&lt;p&gt;folio_next_index() returns an unsigned long value which left shifted
by PAGE_SHIFT could possibly cause an overflow on 32-bit system. Instead
use folio_pos(folio) + folio_size(folio), which does this correctly.(CVE-2023-54285)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;bcache: fix NULL pointer in cache_set_flush()&lt;/p&gt;
&lt;p&gt;1. LINE#1794 - LINE#1887 is some codes about function of
   bch_cache_set_alloc().
2. LINE#2078 - LINE#2142 is some codes about function of
   register_cache_set().
3. register_cache_set() will call bch_cache_set_alloc() in LINE#2098.&lt;/p&gt;
&lt;p&gt;1794 struct cache_set *bch_cache_set_alloc(struct cache_sb *sb)
 1795 {
 ...
 1860         if (!(c-&amp;amp;gt;devices = kcalloc(c-&amp;amp;gt;nr_uuids, sizeof(void *), GFP_KERNEL)) ||
 1861             mempool_init_slab_pool(&amp;amp;amp;c-&amp;amp;gt;search, 32, bch_search_cache) ||
 1862             mempool_init_kmalloc_pool(&amp;amp;amp;c-&amp;amp;gt;bio_meta, 2,
 1863                                 sizeof(struct bbio) + sizeof(struct bio_vec) *
 1864                                 bucket_pages(c)) ||
 1865             mempool_init_kmalloc_pool(&amp;amp;amp;c-&amp;amp;gt;fill_iter, 1, iter_size) ||
 1866             bioset_init(&amp;amp;amp;c-&amp;amp;gt;bio_split, 4, offsetof(struct bbio, bio),
 1867                         BIOSET_NEED_BVECS|BIOSET_NEED_RESCUER) ||
 18…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP4: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;iomap: Fix possible overflow condition in iomap_write_delalloc_scan&lt;/p&gt;
&lt;p&gt;folio_next_index() returns an unsigned long value which left shifted
by PAGE_SHIFT could possibly cause an overflow on 32-bit system. Instead
use folio_pos(folio) + folio_size(folio), which does this correctly.(CVE-2023-54285)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;bcache: fix NULL pointer in cache_set_flush()&lt;/p&gt;
&lt;p&gt;1. LINE#1794 - LINE#1887 is some codes about function of
   bch_cache_set_alloc().
2. LINE#2078 - LINE#2142 is some codes about function of
   register_cache_set().
3. register_cache_set() will call bch_cache_set_alloc() in LINE#2098.&lt;/p&gt;
&lt;p&gt;1794 struct cache_set *bch_cache_set_alloc(struct cache_sb *sb)
 1795 {
 ...
 1860         if (!(c-&amp;amp;gt;devices = kcalloc(c-&amp;amp;gt;nr_uuids, sizeof(void *), GFP_KERNEL)) ||
 1861             mempool_init_slab_pool(&amp;amp;amp;c-&amp;amp;gt;search, 32, bch_search_cache) ||
 1862             mempool_init_kmalloc_pool(&amp;amp;amp;c-&amp;amp;gt;bio_meta, 2,
 1863                                 sizeof(struct bbio) + sizeof(struct bio_vec) *
 1864                                 bucket_pages(c)) ||
 1865             mempool_init_kmalloc_pool(&amp;amp;amp;c-&amp;amp;gt;fill_iter, 1, iter_size) ||
 1866             bioset_init(&amp;amp;amp;c-&amp;amp;gt;bio_split, 4, offsetof(struct bbio, bio),
 1867                         BIOSET_NEED_BVECS|BIOSET_NEED_RESCUER) ||
 18…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2026-2580</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:20416-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:20416-1</link>
      <description>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2026:20416-1</guid>
    </item>
    <item>
      <title>RHSA-2026:3110 — Red Hat Security Advisory: kernel-rt security update</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2026:3110</link>
      <description>&lt;p&gt;kernel: Linux kernel: Use-after-free vulnerability in page_pool_recycle_in_ring can lead to arbitrary code execution kernel: Linux kernel:A use-after-free in bridge multicast in br_multicast_port_ctx_init kernel: smc: Fix use-after-free in __pnet_find_base_ndev() kernel: mlxsw: spectrum_mr: Fix use-after-free when updating multicast route stats kernel: Linux kernel: Use-after-free in teql queueing discipline can lead to privilege escalation&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel: Linux kernel: Use-after-free vulnerability in page_pool_recycle_in_ring can lead to arbitrary code execution kernel: Linux kernel:A use-after-free in bridge multicast in br_multicast_port_ctx_init kernel: smc: Fix use-after-free in __pnet_find_base_ndev() kernel: mlxsw: spectrum_mr: Fix use-after-free when updating multicast route stats kernel: Linux kernel: Use-after-free in teql queueing discipline can lead to privilege escalation&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2026:3110</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:0928-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2026:0928-1</link>
      <description>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/suse-su-2026:0928-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-23074</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-23074</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 231 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: net/sched: Enforce that teql can only be used as root qdisc Design intent of teql is that it is only supposed to be used as root qdisc. We need to check for that constraint. Although not important, I will describe the scenario that unearthed this issue for the curious. GangMin Kim &amp;lt;km.kim1503@gmail.com&amp;gt; managed to concot a scenario as follows: ROOT qdisc 1:0 (QFQ)   ├── class 1:1 (weight=15, lmax=16384) netem with delay 6.4s   └── class 1:2 (weight=1, lmax=1514) teql GangMin sends a packet which is enqueued to 1:1 (netem). Any invocation of dequeue by QFQ from this class will not return a packet until after 6.4s. In the meantime, a second packet is sent and it lands on 1:2. teql&amp;#39;s enqueue will return success and this will activate class 1:2. Main issue is that teql only updates the parent visible qlen (sch-&amp;gt;q.qlen) at dequeue. Since QFQ will only call dequeue if peek succeeds (and teql&amp;#39;s peek always returns NULL), dequeue will never be called and thus the qlen will remain as 0. With that in mind, when GangMin updates 1:2&amp;#39;s lmax value, the qfq_change_class calls qfq_deact_rm_from_agg. Since the child qdisc&amp;#39;s qlen was not incremented, qfq fails to deactivate the class, but still frees its pointers from the aggregate. So when the first packet is rescheduled after 6.4 seconds (netem&amp;#39;s delay), a dangling pointer is accessed causing GangMin&amp;#39;s causing a UAF.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 231 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: net/sched: Enforce that teql can only be used as root qdisc Design intent of teql is that it is only supposed to be used as root qdisc. We need to check for that constraint. Although not important, I will describe the scenario that unearthed this issue for the curious. GangMin Kim &amp;lt;km.kim1503@gmail.com&amp;gt; managed to concot a scenario as follows: ROOT qdisc 1:0 (QFQ)   ├── class 1:1 (weight=15, lmax=16384) netem with delay 6.4s   └── class 1:2 (weight=1, lmax=1514) teql GangMin sends a packet which is enqueued to 1:1 (netem). Any invocation of dequeue by QFQ from this class will not return a packet until after 6.4s. In the meantime, a second packet is sent and it lands on 1:2. teql&amp;#39;s enqueue will return success and this will activate class 1:2. Main issue is that teql only updates the parent visible qlen (sch-&amp;gt;q.qlen) at dequeue. Since QFQ will only call dequeue if peek succeeds (and teql&amp;#39;s peek always returns NULL), dequeue will never be called and thus the qlen will remain as 0. With that in mind, when GangMin updates 1:2&amp;#39;s lmax value, the qfq_change_class calls qfq_deact_rm_from_agg. Since the child qdisc&amp;#39;s qlen was not incremented, qfq fails to deactivate the class, but still frees its pointers from the aggregate. So when the first packet is rescheduled after 6.4 seconds (netem&amp;#39;s delay), a dangling pointer is accessed causing GangMin&amp;#39;s causing a UAF.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-23074</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-0324 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0324</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu einer Denial-of-Service- Bedingung führen oder eine Speicherbeschädigung verursachen können.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu einer Denial-of-Service- Bedingung führen oder eine Speicherbeschädigung verursachen können.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0324</guid>
    </item>
  </channel>
</rss>
