<?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 13:40:38 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-15703</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-15703</link>
      <description>bdu:2025-15703</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-15703</guid>
    </item>
    <item>
      <title>BELL-CVE-2025-39738</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2025-39738</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-2025-39738</guid>
    </item>
    <item>
      <title>certfr-2025-avi-0825 — 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-2025-avi-0825</link>
      <description>certfr-2025-avi-0825</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2025-avi-0825</guid>
    </item>
    <item>
      <title>EUVD-2026-347194</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-347194</link>
      <description>EUVD-2026-347194</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-347194</guid>
    </item>
    <item>
      <title>fkie_cve-2025-39738</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-39738</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;btrfs: do not allow relocation of partially dropped subvolumes&lt;/p&gt;
&lt;p&gt;[BUG]
There is an internal report that balance triggered transaction abort,
with the following call trace:&lt;/p&gt;
&lt;p&gt;item 85 key (594509824 169 0) itemoff 12599 itemsize 33
          extent refs 1 gen 197740 flags 2
          ref#0: tree block backref root 7
  item 86 key (594558976 169 0) itemoff 12566 itemsize 33
          extent refs 1 gen 197522 flags 2
          ref#0: tree block backref root 7
 ...
 BTRFS error (device loop0): extent item not found for insert, bytenr 594526208 num_bytes 16384 parent 449921024 root_objectid 934 owner 1 offset 0
 BTRFS error (device loop0): failed to run delayed ref for logical 594526208 num_bytes 16384 type 182 action 1 ref_mod 1: -117
 ------------[ cut here ]------------
 BTRFS: Transaction aborted (error -117)
 WARNING: CPU: 1 PID: 6963 at ../fs/btrfs/extent-tree.c:2168 btrfs_run_delayed_refs+0xfa/0x110 [btrfs]&lt;/p&gt;
&lt;p&gt;And btrfs check doesn&amp;#39;t report anything wrong related to the extent
tree.&lt;/p&gt;
&lt;p&gt;[CAUSE]
The cause is a little complex, firstly the extent tree indeed doesn&amp;#39;t
have the backref for 594526208.&lt;/p&gt;
&lt;p&gt;The extent tree only have the following two backrefs around that bytenr
on-disk:&lt;/p&gt;
&lt;p&gt;item 65 key (594509824 METADATA_ITEM 0) itemoff 13880 itemsize 33
                refs 1 gen 197740 flags TREE_BLOCK
                tree block skinny level 0
                (176 0x7) tree block backref root CSUM_TREE
        item…&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;btrfs: do not allow relocation of partially dropped subvolumes&lt;/p&gt;
&lt;p&gt;[BUG]
There is an internal report that balance triggered transaction abort,
with the following call trace:&lt;/p&gt;
&lt;p&gt;item 85 key (594509824 169 0) itemoff 12599 itemsize 33
          extent refs 1 gen 197740 flags 2
          ref#0: tree block backref root 7
  item 86 key (594558976 169 0) itemoff 12566 itemsize 33
          extent refs 1 gen 197522 flags 2
          ref#0: tree block backref root 7
 ...
 BTRFS error (device loop0): extent item not found for insert, bytenr 594526208 num_bytes 16384 parent 449921024 root_objectid 934 owner 1 offset 0
 BTRFS error (device loop0): failed to run delayed ref for logical 594526208 num_bytes 16384 type 182 action 1 ref_mod 1: -117
 ------------[ cut here ]------------
 BTRFS: Transaction aborted (error -117)
 WARNING: CPU: 1 PID: 6963 at ../fs/btrfs/extent-tree.c:2168 btrfs_run_delayed_refs+0xfa/0x110 [btrfs]&lt;/p&gt;
&lt;p&gt;And btrfs check doesn&amp;#39;t report anything wrong related to the extent
tree.&lt;/p&gt;
&lt;p&gt;[CAUSE]
The cause is a little complex, firstly the extent tree indeed doesn&amp;#39;t
have the backref for 594526208.&lt;/p&gt;
&lt;p&gt;The extent tree only have the following two backrefs around that bytenr
on-disk:&lt;/p&gt;
&lt;p&gt;item 65 key (594509824 METADATA_ITEM 0) itemoff 13880 itemsize 33
                refs 1 gen 197740 flags TREE_BLOCK
                tree block skinny level 0
                (176 0x7) tree block backref root CSUM_TREE
        item…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-39738</guid>
    </item>
    <item>
      <title>GHSA-8x83-vv5w-vmh3</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-8x83-vv5w-vmh3</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;btrfs: do not allow relocation of partially dropped subvolumes&lt;/p&gt;
&lt;p&gt;[BUG]
There is an internal report that balance triggered transaction abort,
with the following call trace:&lt;/p&gt;
&lt;p&gt;item 85 key (594509824 169 0) itemoff 12599 itemsize 33
          extent refs 1 gen 197740 flags 2
          ref#0: tree block backref root 7
  item 86 key (594558976 169 0) itemoff 12566 itemsize 33
          extent refs 1 gen 197522 flags 2
          ref#0: tree block backref root 7
 ...
 BTRFS error (device loop0): extent item not found for insert, bytenr 594526208 num_bytes 16384 parent 449921024 root_objectid 934 owner 1 offset 0
 BTRFS error (device loop0): failed to run delayed ref for logical 594526208 num_bytes 16384 type 182 action 1 ref_mod 1: -117
 ------------[ cut here ]------------
 BTRFS: Transaction aborted (error -117)
 WARNING: CPU: 1 PID: 6963 at ../fs/btrfs/extent-tree.c:2168 btrfs_run_delayed_refs+0xfa/0x110 [btrfs]&lt;/p&gt;
&lt;p&gt;And btrfs check doesn&amp;#39;t report anything wrong related to the extent
tree.&lt;/p&gt;
&lt;p&gt;[CAUSE]
The cause is a little complex, firstly the extent tree indeed doesn&amp;#39;t
have the backref for 594526208.&lt;/p&gt;
&lt;p&gt;The extent tree only have the following two backrefs around that bytenr
on-disk:&lt;/p&gt;
&lt;p&gt;item 65 key (594509824 METADATA_ITEM 0) itemoff 13880 itemsize 33
                refs 1 gen 197740 flags TREE_BLOCK
                tree block skinny level 0
                (176 0x7) tree block backref root CSUM_TREE
        item…&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;btrfs: do not allow relocation of partially dropped subvolumes&lt;/p&gt;
&lt;p&gt;[BUG]
There is an internal report that balance triggered transaction abort,
with the following call trace:&lt;/p&gt;
&lt;p&gt;item 85 key (594509824 169 0) itemoff 12599 itemsize 33
          extent refs 1 gen 197740 flags 2
          ref#0: tree block backref root 7
  item 86 key (594558976 169 0) itemoff 12566 itemsize 33
          extent refs 1 gen 197522 flags 2
          ref#0: tree block backref root 7
 ...
 BTRFS error (device loop0): extent item not found for insert, bytenr 594526208 num_bytes 16384 parent 449921024 root_objectid 934 owner 1 offset 0
 BTRFS error (device loop0): failed to run delayed ref for logical 594526208 num_bytes 16384 type 182 action 1 ref_mod 1: -117
 ------------[ cut here ]------------
 BTRFS: Transaction aborted (error -117)
 WARNING: CPU: 1 PID: 6963 at ../fs/btrfs/extent-tree.c:2168 btrfs_run_delayed_refs+0xfa/0x110 [btrfs]&lt;/p&gt;
&lt;p&gt;And btrfs check doesn&amp;#39;t report anything wrong related to the extent
tree.&lt;/p&gt;
&lt;p&gt;[CAUSE]
The cause is a little complex, firstly the extent tree indeed doesn&amp;#39;t
have the backref for 594526208.&lt;/p&gt;
&lt;p&gt;The extent tree only have the following two backrefs around that bytenr
on-disk:&lt;/p&gt;
&lt;p&gt;item 65 key (594509824 METADATA_ITEM 0) itemoff 13880 itemsize 33
                refs 1 gen 197740 flags TREE_BLOCK
                tree block skinny level 0
                (176 0x7) tree block backref root CSUM_TREE
        item…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-8x83-vv5w-vmh3</guid>
    </item>
    <item>
      <title>ICSA-26-134-10 — Siemens SIMATIC</title>
      <link>https://cve.radiocsirt.org/vuln/icsa-26-134-10</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
drm/amd/display: Check link_res-&amp;gt;hpo_dp_link_enc before using it&#13;
&#13;
[WHAT &amp;amp; HOW]&#13;
Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res&#13;
without initializing hpo_dp_link_enc and it is necessary to check for&#13;
null before dereferencing.&#13;
&#13;
This fixes 2 FORWARD_NULL issues reported by Coverity. In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;fs: relax assertions on failure to encode file handles&lt;/p&gt;
&lt;p&gt;Encoding file handles is usually performed by a filesystem &amp;gt;encode_fh()
method that may fail for various reasons.&lt;/p&gt;
&lt;p&gt;The legacy users of exportfs_encode_fh(), namely, nfsd and
name_to_handle_at(2) syscall are ready to cope with the possibility
of failure to encode a file handle.&lt;/p&gt;
&lt;p&gt;There are a few other users of exportfs_encode_{fh,fid}() that
currently have a WARN_ON() assertion when -&amp;gt;encode_fh() fails.
Relax those assertions because they are wrong.&lt;/p&gt;
&lt;p&gt;The second linked bug report states commit 16aac5ad1fa9 (&amp;#34;ovl: support
encoding non-decodable file handles&amp;#34;) in v6.6 as the regressing commit,
but this is not accurate.&lt;/p&gt;
&lt;p&gt;The aforementioned commit only increases the chances of the assertion
and allows triggering the assertion with the reproducer using overlayfs,
inotify and drop_caches.&lt;/p&gt;
&lt;p&gt;Triggering this assertion was always possible with other filesystems and
other reasons of -&amp;gt;encode_fh() failures and more particularly, it was
also possible with the exact same reproducer using overlay…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
drm/amd/display: Check link_res-&amp;gt;hpo_dp_link_enc before using it&#13;
&#13;
[WHAT &amp;amp; HOW]&#13;
Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res&#13;
without initializing hpo_dp_link_enc and it is necessary to check for&#13;
null before dereferencing.&#13;
&#13;
This fixes 2 FORWARD_NULL issues reported by Coverity. In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;fs: relax assertions on failure to encode file handles&lt;/p&gt;
&lt;p&gt;Encoding file handles is usually performed by a filesystem &amp;gt;encode_fh()
method that may fail for various reasons.&lt;/p&gt;
&lt;p&gt;The legacy users of exportfs_encode_fh(), namely, nfsd and
name_to_handle_at(2) syscall are ready to cope with the possibility
of failure to encode a file handle.&lt;/p&gt;
&lt;p&gt;There are a few other users of exportfs_encode_{fh,fid}() that
currently have a WARN_ON() assertion when -&amp;gt;encode_fh() fails.
Relax those assertions because they are wrong.&lt;/p&gt;
&lt;p&gt;The second linked bug report states commit 16aac5ad1fa9 (&amp;#34;ovl: support
encoding non-decodable file handles&amp;#34;) in v6.6 as the regressing commit,
but this is not accurate.&lt;/p&gt;
&lt;p&gt;The aforementioned commit only increases the chances of the assertion
and allows triggering the assertion with the reproducer using overlayfs,
inotify and drop_caches.&lt;/p&gt;
&lt;p&gt;Triggering this assertion was always possible with other filesystems and
other reasons of -&amp;gt;encode_fh() failures and more particularly, it was
also possible with the exact same reproducer using overlay…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/icsa-26-134-10</guid>
    </item>
    <item>
      <title>msrc_CVE-2025-39738 — btrfs: do not allow relocation of partially dropped subvolumes</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2025-39738</link>
      <description>msrc_CVE-2025-39738</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2025-39738</guid>
    </item>
    <item>
      <title>NCSC-2026-0147 — Kwetsbaarheden verholpen in Siemens-producten</title>
      <link>https://cve.radiocsirt.org/vuln/ncsc-2026-0147</link>
      <description>NCSC-2026-0147</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ncsc-2026-0147</guid>
    </item>
    <item>
      <title>OESA-2026-2579 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2026-2579</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:20.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;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) ||
 1868             !(c-&amp;amp;gt;uuids = alloc_bucket_pages(GFP_KERNEL, c)) ||
 1869             !(c-&amp;amp;gt;moving_gc_wq = alloc_workqueue(&amp;amp;quot;bcache_gc&amp;amp;quot;,
 1870                                                 WQ_MEM_RECLAIM, 0)) ||
 1871             bch_journal_alloc(c) ||
 1872             bch_btree_cache_alloc(c) ||
 1873             bch_open_buckets_alloc(c) ||
 1874…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:20.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;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) ||
 1868             !(c-&amp;amp;gt;uuids = alloc_bucket_pages(GFP_KERNEL, c)) ||
 1869             !(c-&amp;amp;gt;moving_gc_wq = alloc_workqueue(&amp;amp;quot;bcache_gc&amp;amp;quot;,
 1870                                                 WQ_MEM_RECLAIM, 0)) ||
 1871             bch_journal_alloc(c) ||
 1872             bch_btree_cache_alloc(c) ||
 1873             bch_open_buckets_alloc(c) ||
 1874…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2026-2579</guid>
    </item>
    <item>
      <title>openSUSE-SU-2025:20081-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2025:20081-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-2025:20081-1</guid>
    </item>
    <item>
      <title>SSA-032379 — SSA-032379: Multiple Vulnerabilities in SIMATIC CN 4100 Before V5.0</title>
      <link>https://cve.radiocsirt.org/vuln/ssa-032379</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
drm/amd/display: Check link_res-&amp;gt;hpo_dp_link_enc before using it&#13;
&#13;
[WHAT &amp;amp; HOW]&#13;
Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res&#13;
without initializing hpo_dp_link_enc and it is necessary to check for&#13;
null before dereferencing.&#13;
&#13;
This fixes 2 FORWARD_NULL issues reported by Coverity. In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;fs: relax assertions on failure to encode file handles&lt;/p&gt;
&lt;p&gt;Encoding file handles is usually performed by a filesystem &amp;gt;encode_fh()
method that may fail for various reasons.&lt;/p&gt;
&lt;p&gt;The legacy users of exportfs_encode_fh(), namely, nfsd and
name_to_handle_at(2) syscall are ready to cope with the possibility
of failure to encode a file handle.&lt;/p&gt;
&lt;p&gt;There are a few other users of exportfs_encode_{fh,fid}() that
currently have a WARN_ON() assertion when -&amp;gt;encode_fh() fails.
Relax those assertions because they are wrong.&lt;/p&gt;
&lt;p&gt;The second linked bug report states commit 16aac5ad1fa9 (&amp;#34;ovl: support
encoding non-decodable file handles&amp;#34;) in v6.6 as the regressing commit,
but this is not accurate.&lt;/p&gt;
&lt;p&gt;The aforementioned commit only increases the chances of the assertion
and allows triggering the assertion with the reproducer using overlayfs,
inotify and drop_caches.&lt;/p&gt;
&lt;p&gt;Triggering this assertion was always possible with other filesystems and
other reasons of -&amp;gt;encode_fh() failures and more particularly, it was
also possible with the exact same reproducer using overlay…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
drm/amd/display: Check link_res-&amp;gt;hpo_dp_link_enc before using it&#13;
&#13;
[WHAT &amp;amp; HOW]&#13;
Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res&#13;
without initializing hpo_dp_link_enc and it is necessary to check for&#13;
null before dereferencing.&#13;
&#13;
This fixes 2 FORWARD_NULL issues reported by Coverity. In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;fs: relax assertions on failure to encode file handles&lt;/p&gt;
&lt;p&gt;Encoding file handles is usually performed by a filesystem &amp;gt;encode_fh()
method that may fail for various reasons.&lt;/p&gt;
&lt;p&gt;The legacy users of exportfs_encode_fh(), namely, nfsd and
name_to_handle_at(2) syscall are ready to cope with the possibility
of failure to encode a file handle.&lt;/p&gt;
&lt;p&gt;There are a few other users of exportfs_encode_{fh,fid}() that
currently have a WARN_ON() assertion when -&amp;gt;encode_fh() fails.
Relax those assertions because they are wrong.&lt;/p&gt;
&lt;p&gt;The second linked bug report states commit 16aac5ad1fa9 (&amp;#34;ovl: support
encoding non-decodable file handles&amp;#34;) in v6.6 as the regressing commit,
but this is not accurate.&lt;/p&gt;
&lt;p&gt;The aforementioned commit only increases the chances of the assertion
and allows triggering the assertion with the reproducer using overlayfs,
inotify and drop_caches.&lt;/p&gt;
&lt;p&gt;Triggering this assertion was always possible with other filesystems and
other reasons of -&amp;gt;encode_fh() failures and more particularly, it was
also possible with the exact same reproducer using overlay…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ssa-032379</guid>
    </item>
    <item>
      <title>SUSE-SU-2025:03600-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2025:03600-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-2025:03600-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2025-39738</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-39738</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 162 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: btrfs: do not allow relocation of partially dropped subvolumes [BUG] There is an internal report that balance triggered transaction abort, with the following call trace:   item 85 key (594509824 169 0) itemoff 12599 itemsize 33           extent refs 1 gen 197740 flags 2           ref#0: tree block backref root 7   item 86 key (594558976 169 0) itemoff 12566 itemsize 33           extent refs 1 gen 197522 flags 2           ref#0: tree block backref root 7  ...  BTRFS error (device loop0): extent item not found for insert, bytenr 594526208 num_bytes 16384 parent 449921024 root_objectid 934 owner 1 offset 0  BTRFS error (device loop0): failed to run delayed ref for logical 594526208 num_bytes 16384 type 182 action 1 ref_mod 1: -117  ------------[ cut here ]------------  BTRFS: Transaction aborted (error -117)  WARNING: CPU: 1 PID: 6963 at ../fs/btrfs/extent-tree.c:2168 btrfs_run_delayed_refs+0xfa/0x110 [btrfs] And btrfs check doesn&amp;#39;t report anything wrong related to the extent tree. [CAUSE] The cause is a little complex, firstly the extent tree indeed doesn&amp;#39;t have the backref for 594526208. The extent tree only have the following two backrefs around that bytenr on-disk:         item 65 key (594509824 METADATA_ITEM 0) itemoff 13880 itemsize 33                 refs 1 gen 197740 flags TREE_BLOCK                 tree block skinny level 0                 (176 0x7) tree block backref root CSUM_TREE         item 66 key…&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 162 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: btrfs: do not allow relocation of partially dropped subvolumes [BUG] There is an internal report that balance triggered transaction abort, with the following call trace:   item 85 key (594509824 169 0) itemoff 12599 itemsize 33           extent refs 1 gen 197740 flags 2           ref#0: tree block backref root 7   item 86 key (594558976 169 0) itemoff 12566 itemsize 33           extent refs 1 gen 197522 flags 2           ref#0: tree block backref root 7  ...  BTRFS error (device loop0): extent item not found for insert, bytenr 594526208 num_bytes 16384 parent 449921024 root_objectid 934 owner 1 offset 0  BTRFS error (device loop0): failed to run delayed ref for logical 594526208 num_bytes 16384 type 182 action 1 ref_mod 1: -117  ------------[ cut here ]------------  BTRFS: Transaction aborted (error -117)  WARNING: CPU: 1 PID: 6963 at ../fs/btrfs/extent-tree.c:2168 btrfs_run_delayed_refs+0xfa/0x110 [btrfs] And btrfs check doesn&amp;#39;t report anything wrong related to the extent tree. [CAUSE] The cause is a little complex, firstly the extent tree indeed doesn&amp;#39;t have the backref for 594526208. The extent tree only have the following two backrefs around that bytenr on-disk:         item 65 key (594509824 METADATA_ITEM 0) itemoff 13880 itemsize 33                 refs 1 gen 197740 flags TREE_BLOCK                 tree block skinny level 0                 (176 0x7) tree block backref root CSUM_TREE         item 66 key…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-39738</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-2040 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2040</link>
      <description>&lt;p&gt;Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um Sicherheitsmechanismen zu umgehen, sowie einen Denial of Service Angriff oder andere nicht spezifizierte Angriffe durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um Sicherheitsmechanismen zu umgehen, sowie einen Denial of Service Angriff oder andere nicht spezifizierte Angriffe durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2040</guid>
    </item>
  </channel>
</rss>
