<?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>Sat, 03 Oct 2026 23:53:09 +0000</lastBuildDate>
    <item>
      <title>bdu:2024-03705</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2024-03705</link>
      <description>bdu:2024-03705</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2024-03705</guid>
    </item>
    <item>
      <title>BELL-CVE-2023-52438</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2023-52438</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-2023-52438</guid>
    </item>
    <item>
      <title>certfr-2024-avi-0226 — De multiples vulnérabilités ont été découvertes dans &lt;span
class="textit"&gt;le noyau Linux d'Ubuntu&lt;/span&gt;. Certaines d'e…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2024-avi-0226</link>
      <description>certfr-2024-avi-0226</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2024-avi-0226</guid>
    </item>
    <item>
      <title>EUVD-2026-344988</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-344988</link>
      <description>EUVD-2026-344988</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-344988</guid>
    </item>
    <item>
      <title>fkie_cve-2023-52438</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2023-52438</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;binder: fix use-after-free in shinker&amp;#39;s callback&lt;/p&gt;
&lt;p&gt;The mmap read lock is used during the shrinker&amp;#39;s callback, which means
that using alloc-&amp;gt;vma pointer isn&amp;#39;t safe as it can race with munmap().
As of commit dd2283f2605e (&amp;#34;mm: mmap: zap pages with read mmap_sem in
munmap&amp;#34;) the mmap lock is downgraded after the vma has been isolated.&lt;/p&gt;
&lt;p&gt;I was able to reproduce this issue by manually adding some delays and
triggering page reclaiming through the shrinker&amp;#39;s debug sysfs. The
following KASAN report confirms the UAF:&lt;/p&gt;
&lt;p&gt;==================================================================
  BUG: KASAN: slab-use-after-free in zap_page_range_single+0x470/0x4b8
  Read of size 8 at addr ffff356ed50e50f0 by task bash/478&lt;/p&gt;
&lt;p&gt;CPU: 1 PID: 478 Comm: bash Not tainted 6.6.0-rc5-00055-g1c8b86a3799f-dirty #70
  Hardware name: linux,dummy-virt (DT)
  Call trace:
   zap_page_range_single+0x470/0x4b8
   binder_alloc_free_page+0x608/0xadc
   __list_lru_walk_one+0x130/0x3b0
   list_lru_walk_node+0xc4/0x22c
   binder_shrink_scan+0x108/0x1dc
   shrinker_debugfs_scan_write+0x2b4/0x500
   full_proxy_write+0xd4/0x140
   vfs_write+0x1ac/0x758
   ksys_write+0xf0/0x1dc
   __arm64_sys_write+0x6c/0x9c&lt;/p&gt;
&lt;p&gt;Allocated by task 492:
   kmem_cache_alloc+0x130/0x368
   vm_area_alloc+0x2c/0x190
   mmap_region+0x258/0x18bc
   do_mmap+0x694/0xa60
   vm_mmap_pgoff+0x170/0x29c
   ksys_mmap_pgoff+0x290/0x3a0
   __arm64_sys_mmap+0xcc/0x144&lt;/p&gt;
&lt;p&gt;Freed by task 491:…&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;binder: fix use-after-free in shinker&amp;#39;s callback&lt;/p&gt;
&lt;p&gt;The mmap read lock is used during the shrinker&amp;#39;s callback, which means
that using alloc-&amp;gt;vma pointer isn&amp;#39;t safe as it can race with munmap().
As of commit dd2283f2605e (&amp;#34;mm: mmap: zap pages with read mmap_sem in
munmap&amp;#34;) the mmap lock is downgraded after the vma has been isolated.&lt;/p&gt;
&lt;p&gt;I was able to reproduce this issue by manually adding some delays and
triggering page reclaiming through the shrinker&amp;#39;s debug sysfs. The
following KASAN report confirms the UAF:&lt;/p&gt;
&lt;p&gt;==================================================================
  BUG: KASAN: slab-use-after-free in zap_page_range_single+0x470/0x4b8
  Read of size 8 at addr ffff356ed50e50f0 by task bash/478&lt;/p&gt;
&lt;p&gt;CPU: 1 PID: 478 Comm: bash Not tainted 6.6.0-rc5-00055-g1c8b86a3799f-dirty #70
  Hardware name: linux,dummy-virt (DT)
  Call trace:
   zap_page_range_single+0x470/0x4b8
   binder_alloc_free_page+0x608/0xadc
   __list_lru_walk_one+0x130/0x3b0
   list_lru_walk_node+0xc4/0x22c
   binder_shrink_scan+0x108/0x1dc
   shrinker_debugfs_scan_write+0x2b4/0x500
   full_proxy_write+0xd4/0x140
   vfs_write+0x1ac/0x758
   ksys_write+0xf0/0x1dc
   __arm64_sys_write+0x6c/0x9c&lt;/p&gt;
&lt;p&gt;Allocated by task 492:
   kmem_cache_alloc+0x130/0x368
   vm_area_alloc+0x2c/0x190
   mmap_region+0x258/0x18bc
   do_mmap+0x694/0xa60
   vm_mmap_pgoff+0x170/0x29c
   ksys_mmap_pgoff+0x290/0x3a0
   __arm64_sys_mmap+0xcc/0x144&lt;/p&gt;
&lt;p&gt;Freed by task 491:…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2023-52438</guid>
    </item>
    <item>
      <title>GHSA-25g3-q597-79m8</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-25g3-q597-79m8</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;binder: fix use-after-free in shinker&amp;#39;s callback&lt;/p&gt;
&lt;p&gt;The mmap read lock is used during the shrinker&amp;#39;s callback, which means
that using alloc-&amp;gt;vma pointer isn&amp;#39;t safe as it can race with munmap().
As of commit dd2283f2605e (&amp;#34;mm: mmap: zap pages with read mmap_sem in
munmap&amp;#34;) the mmap lock is downgraded after the vma has been isolated.&lt;/p&gt;
&lt;p&gt;I was able to reproduce this issue by manually adding some delays and
triggering page reclaiming through the shrinker&amp;#39;s debug sysfs. The
following KASAN report confirms the UAF:&lt;/p&gt;
&lt;p&gt;==================================================================
  BUG: KASAN: slab-use-after-free in zap_page_range_single+0x470/0x4b8
  Read of size 8 at addr ffff356ed50e50f0 by task bash/478&lt;/p&gt;
&lt;p&gt;CPU: 1 PID: 478 Comm: bash Not tainted 6.6.0-rc5-00055-g1c8b86a3799f-dirty #70
  Hardware name: linux,dummy-virt (DT)
  Call trace:
   zap_page_range_single+0x470/0x4b8
   binder_alloc_free_page+0x608/0xadc
   __list_lru_walk_one+0x130/0x3b0
   list_lru_walk_node+0xc4/0x22c
   binder_shrink_scan+0x108/0x1dc
   shrinker_debugfs_scan_write+0x2b4/0x500
   full_proxy_write+0xd4/0x140
   vfs_write+0x1ac/0x758
   ksys_write+0xf0/0x1dc
   __arm64_sys_write+0x6c/0x9c&lt;/p&gt;
&lt;p&gt;Allocated by task 492:
   kmem_cache_alloc+0x130/0x368
   vm_area_alloc+0x2c/0x190
   mmap_region+0x258/0x18bc
   do_mmap+0x694/0xa60
   vm_mmap_pgoff+0x170/0x29c
   ksys_mmap_pgoff+0x290/0x3a0
   __arm64_sys_mmap+0xcc/0x144&lt;/p&gt;
&lt;p&gt;Freed by task 491:…&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;binder: fix use-after-free in shinker&amp;#39;s callback&lt;/p&gt;
&lt;p&gt;The mmap read lock is used during the shrinker&amp;#39;s callback, which means
that using alloc-&amp;gt;vma pointer isn&amp;#39;t safe as it can race with munmap().
As of commit dd2283f2605e (&amp;#34;mm: mmap: zap pages with read mmap_sem in
munmap&amp;#34;) the mmap lock is downgraded after the vma has been isolated.&lt;/p&gt;
&lt;p&gt;I was able to reproduce this issue by manually adding some delays and
triggering page reclaiming through the shrinker&amp;#39;s debug sysfs. The
following KASAN report confirms the UAF:&lt;/p&gt;
&lt;p&gt;==================================================================
  BUG: KASAN: slab-use-after-free in zap_page_range_single+0x470/0x4b8
  Read of size 8 at addr ffff356ed50e50f0 by task bash/478&lt;/p&gt;
&lt;p&gt;CPU: 1 PID: 478 Comm: bash Not tainted 6.6.0-rc5-00055-g1c8b86a3799f-dirty #70
  Hardware name: linux,dummy-virt (DT)
  Call trace:
   zap_page_range_single+0x470/0x4b8
   binder_alloc_free_page+0x608/0xadc
   __list_lru_walk_one+0x130/0x3b0
   list_lru_walk_node+0xc4/0x22c
   binder_shrink_scan+0x108/0x1dc
   shrinker_debugfs_scan_write+0x2b4/0x500
   full_proxy_write+0xd4/0x140
   vfs_write+0x1ac/0x758
   ksys_write+0xf0/0x1dc
   __arm64_sys_write+0x6c/0x9c&lt;/p&gt;
&lt;p&gt;Allocated by task 492:
   kmem_cache_alloc+0x130/0x368
   vm_area_alloc+0x2c/0x190
   mmap_region+0x258/0x18bc
   do_mmap+0x694/0xa60
   vm_mmap_pgoff+0x170/0x29c
   ksys_mmap_pgoff+0x290/0x3a0
   __arm64_sys_mmap+0xcc/0x144&lt;/p&gt;
&lt;p&gt;Freed by task 491:…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-25g3-q597-79m8</guid>
    </item>
    <item>
      <title>gsd-2023-52438</title>
      <link>https://cve.radiocsirt.org/vuln/gsd-2023-52438</link>
      <description>gsd-2023-52438</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/gsd-2023-52438</guid>
    </item>
    <item>
      <title>OESA-2024-1244 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2024-1244</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP3: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
net: prevent mss overflow in skb_segment()&#13;
&#13;
Once again syzbot is able to crash the kernel in skb_segment() [1]&#13;
&#13;
GSO_BY_FRAGS is a forbidden value, but unfortunately the following
computation in skb_segment() can reach it quite easily :&#13;
&#13;
	mss = mss * partial_segs;&#13;
&#13;
65535 = 3 * 5 * 17 * 257, so many initial values of mss can lead to
a bad final result.&#13;
&#13;
Make sure to limit segmentation so that the new mss value is smaller
than GSO_BY_FRAGS.&#13;
&#13;
[1]&#13;
&#13;
general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]
CPU: 1 PID: 5079 Comm: syz-executor993 Not tainted 6.7.0-rc4-syzkaller-00141-g1ae4cd3cbdd0 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023
RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551
Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 &amp;amp;lt;0f&amp;amp;gt; b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00
RSP: 0018:ffffc900043473d0 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597
RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070
RBP: ffffc90004347578 R08: 0000000000000005 R09: 000000000000ffff
R10: 000000000000ff…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP3: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
net: prevent mss overflow in skb_segment()&#13;
&#13;
Once again syzbot is able to crash the kernel in skb_segment() [1]&#13;
&#13;
GSO_BY_FRAGS is a forbidden value, but unfortunately the following
computation in skb_segment() can reach it quite easily :&#13;
&#13;
	mss = mss * partial_segs;&#13;
&#13;
65535 = 3 * 5 * 17 * 257, so many initial values of mss can lead to
a bad final result.&#13;
&#13;
Make sure to limit segmentation so that the new mss value is smaller
than GSO_BY_FRAGS.&#13;
&#13;
[1]&#13;
&#13;
general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]
CPU: 1 PID: 5079 Comm: syz-executor993 Not tainted 6.7.0-rc4-syzkaller-00141-g1ae4cd3cbdd0 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023
RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551
Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 &amp;amp;lt;0f&amp;amp;gt; b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00
RSP: 0018:ffffc900043473d0 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597
RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070
RBP: ffffc90004347578 R08: 0000000000000005 R09: 000000000000ffff
R10: 000000000000ff…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2024-1244</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2023-52438</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-52438</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:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 132 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: binder: fix use-after-free in shinker&amp;#39;s callback The mmap read lock is used during the shrinker&amp;#39;s callback, which means that using alloc-&amp;gt;vma pointer isn&amp;#39;t safe as it can race with munmap(). As of commit dd2283f2605e (&amp;#34;mm: mmap: zap pages with read mmap_sem in munmap&amp;#34;) the mmap lock is downgraded after the vma has been isolated. I was able to reproduce this issue by manually adding some delays and triggering page reclaiming through the shrinker&amp;#39;s debug sysfs. The following KASAN report confirms the UAF:   ==================================================================   BUG: KASAN: slab-use-after-free in zap_page_range_single+0x470/0x4b8   Read of size 8 at addr ffff356ed50e50f0 by task bash/478   CPU: 1 PID: 478 Comm: bash Not tainted 6.6.0-rc5-00055-g1c8b86a3799f-dirty #70   Hardware name: linux,dummy-virt (DT)   Call trace:    zap_page_range_single+0x470/0x4b8    binder_alloc_free_page+0x608/0xadc    __list_lru_walk_one+0x130/0x3b0    list_lru_walk_node+0xc4/0x22c    binder_shrink_scan+0x108/0x1dc    shrinker_debugfs_scan_write+0x2b4/0x500    full_proxy_write+0xd4/0x140    vfs_write+0x1ac/0x758    ksys_write+0xf0/0x1dc    __arm64_sys_write+0x6c/0x9c   Allocated by task 492:    kmem_cache_alloc+0x130/0x368    vm_area_alloc+0x2c/0x190    mmap_region+0x258/0x18bc    do_mmap+0x694/0xa60    vm_mmap_pgoff+0x170/0x29c    ksys_mmap_pgoff+0x290/0x3a0    __arm64_sys_mmap+0xcc/0x144   Freed by task 491:    kmem_c…&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:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 132 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: binder: fix use-after-free in shinker&amp;#39;s callback The mmap read lock is used during the shrinker&amp;#39;s callback, which means that using alloc-&amp;gt;vma pointer isn&amp;#39;t safe as it can race with munmap(). As of commit dd2283f2605e (&amp;#34;mm: mmap: zap pages with read mmap_sem in munmap&amp;#34;) the mmap lock is downgraded after the vma has been isolated. I was able to reproduce this issue by manually adding some delays and triggering page reclaiming through the shrinker&amp;#39;s debug sysfs. The following KASAN report confirms the UAF:   ==================================================================   BUG: KASAN: slab-use-after-free in zap_page_range_single+0x470/0x4b8   Read of size 8 at addr ffff356ed50e50f0 by task bash/478   CPU: 1 PID: 478 Comm: bash Not tainted 6.6.0-rc5-00055-g1c8b86a3799f-dirty #70   Hardware name: linux,dummy-virt (DT)   Call trace:    zap_page_range_single+0x470/0x4b8    binder_alloc_free_page+0x608/0xadc    __list_lru_walk_one+0x130/0x3b0    list_lru_walk_node+0xc4/0x22c    binder_shrink_scan+0x108/0x1dc    shrinker_debugfs_scan_write+0x2b4/0x500    full_proxy_write+0xd4/0x140    vfs_write+0x1ac/0x758    ksys_write+0xf0/0x1dc    __arm64_sys_write+0x6c/0x9c   Allocated by task 492:    kmem_cache_alloc+0x130/0x368    vm_area_alloc+0x2c/0x190    mmap_region+0x258/0x18bc    do_mmap+0x694/0xa60    vm_mmap_pgoff+0x170/0x29c    ksys_mmap_pgoff+0x290/0x3a0    __arm64_sys_mmap+0xcc/0x144   Freed by task 491:    kmem_c…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-52438</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-0444 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-0444</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service zu verursachen oder seine Rechte zu erweitern.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service zu verursachen oder seine Rechte zu erweitern.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-0444</guid>
    </item>
  </channel>
</rss>
