<?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 00:56:23 +0000</lastBuildDate>
    <item>
      <title>bdu:2024-11473</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2024-11473</link>
      <description>bdu:2024-11473</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2024-11473</guid>
    </item>
    <item>
      <title>BELL-CVE-2024-36963</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2024-36963</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2024-36963</guid>
    </item>
    <item>
      <title>certfr-2024-avi-0667 — De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Certaines d'entre elles permettent à un a…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2024-avi-0667</link>
      <description>certfr-2024-avi-0667</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2024-avi-0667</guid>
    </item>
    <item>
      <title>EUVD-2026-345782</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-345782</link>
      <description>EUVD-2026-345782</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-345782</guid>
    </item>
    <item>
      <title>fkie_cve-2024-36963</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2024-36963</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;tracefs: Reset permissions on remount if permissions are options&lt;/p&gt;
&lt;p&gt;There&amp;#39;s an inconsistency with the way permissions are handled in tracefs.
Because the permissions are generated when accessed, they default to the
root inode&amp;#39;s permission if they were never set by the user. If the user
sets the permissions, then a flag is set and the permissions are saved via
the inode (for tracefs files) or an internal attribute field (for
eventfs).&lt;/p&gt;
&lt;p&gt;But if a remount happens that specify the permissions, all the files that
were not changed by the user gets updated, but the ones that were are not.
If the user were to remount the file system with a given permission, then
all files and directories within that file system should be updated.&lt;/p&gt;
&lt;p&gt;This can cause security issues if a file&amp;#39;s permission was updated but the
admin forgot about it. They could incorrectly think that remounting with
permissions set would update all files, but miss some.&lt;/p&gt;
&lt;p&gt;For example:&lt;/p&gt;
&lt;p&gt;# cd /sys/kernel/tracing
 # chgrp 1002 current_tracer
 # ls -l
[..]
 -rw-r-----  1 root root 0 May  1 21:25 buffer_size_kb
 -rw-r-----  1 root root 0 May  1 21:25 buffer_subbuf_size_kb
 -r--r-----  1 root root 0 May  1 21:25 buffer_total_size_kb
 -rw-r-----  1 root lkp  0 May  1 21:25 current_tracer
 -rw-r-----  1 root root 0 May  1 21:25 dynamic_events
 -r--r-----  1 root root 0 May  1 21:25 dyn_ftrace_total_info
 -r--r-----  1 root root 0 May  1 21:25 enabled_functions&lt;/p&gt;
&lt;p&gt;Where…&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;tracefs: Reset permissions on remount if permissions are options&lt;/p&gt;
&lt;p&gt;There&amp;#39;s an inconsistency with the way permissions are handled in tracefs.
Because the permissions are generated when accessed, they default to the
root inode&amp;#39;s permission if they were never set by the user. If the user
sets the permissions, then a flag is set and the permissions are saved via
the inode (for tracefs files) or an internal attribute field (for
eventfs).&lt;/p&gt;
&lt;p&gt;But if a remount happens that specify the permissions, all the files that
were not changed by the user gets updated, but the ones that were are not.
If the user were to remount the file system with a given permission, then
all files and directories within that file system should be updated.&lt;/p&gt;
&lt;p&gt;This can cause security issues if a file&amp;#39;s permission was updated but the
admin forgot about it. They could incorrectly think that remounting with
permissions set would update all files, but miss some.&lt;/p&gt;
&lt;p&gt;For example:&lt;/p&gt;
&lt;p&gt;# cd /sys/kernel/tracing
 # chgrp 1002 current_tracer
 # ls -l
[..]
 -rw-r-----  1 root root 0 May  1 21:25 buffer_size_kb
 -rw-r-----  1 root root 0 May  1 21:25 buffer_subbuf_size_kb
 -r--r-----  1 root root 0 May  1 21:25 buffer_total_size_kb
 -rw-r-----  1 root lkp  0 May  1 21:25 current_tracer
 -rw-r-----  1 root root 0 May  1 21:25 dynamic_events
 -r--r-----  1 root root 0 May  1 21:25 dyn_ftrace_total_info
 -r--r-----  1 root root 0 May  1 21:25 enabled_functions&lt;/p&gt;
&lt;p&gt;Where…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2024-36963</guid>
    </item>
    <item>
      <title>GHSA-2r24-5j8r-cf83</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-2r24-5j8r-cf83</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;tracefs: Reset permissions on remount if permissions are options&lt;/p&gt;
&lt;p&gt;There&amp;#39;s an inconsistency with the way permissions are handled in tracefs.
Because the permissions are generated when accessed, they default to the
root inode&amp;#39;s permission if they were never set by the user. If the user
sets the permissions, then a flag is set and the permissions are saved via
the inode (for tracefs files) or an internal attribute field (for
eventfs).&lt;/p&gt;
&lt;p&gt;But if a remount happens that specify the permissions, all the files that
were not changed by the user gets updated, but the ones that were are not.
If the user were to remount the file system with a given permission, then
all files and directories within that file system should be updated.&lt;/p&gt;
&lt;p&gt;This can cause security issues if a file&amp;#39;s permission was updated but the
admin forgot about it. They could incorrectly think that remounting with
permissions set would update all files, but miss some.&lt;/p&gt;
&lt;p&gt;For example:&lt;/p&gt;
&lt;p&gt;# cd /sys/kernel/tracing
 # chgrp 1002 current_tracer
 # ls -l
[..]
 -rw-r-----  1 root root 0 May  1 21:25 buffer_size_kb
 -rw-r-----  1 root root 0 May  1 21:25 buffer_subbuf_size_kb
 -r--r-----  1 root root 0 May  1 21:25 buffer_total_size_kb
 -rw-r-----  1 root lkp  0 May  1 21:25 current_tracer
 -rw-r-----  1 root root 0 May  1 21:25 dynamic_events
 -r--r-----  1 root root 0 May  1 21:25 dyn_ftrace_total_info
 -r--r-----  1 root root 0 May  1 21:25 enabled_functions&lt;/p&gt;
&lt;p&gt;Where…&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;tracefs: Reset permissions on remount if permissions are options&lt;/p&gt;
&lt;p&gt;There&amp;#39;s an inconsistency with the way permissions are handled in tracefs.
Because the permissions are generated when accessed, they default to the
root inode&amp;#39;s permission if they were never set by the user. If the user
sets the permissions, then a flag is set and the permissions are saved via
the inode (for tracefs files) or an internal attribute field (for
eventfs).&lt;/p&gt;
&lt;p&gt;But if a remount happens that specify the permissions, all the files that
were not changed by the user gets updated, but the ones that were are not.
If the user were to remount the file system with a given permission, then
all files and directories within that file system should be updated.&lt;/p&gt;
&lt;p&gt;This can cause security issues if a file&amp;#39;s permission was updated but the
admin forgot about it. They could incorrectly think that remounting with
permissions set would update all files, but miss some.&lt;/p&gt;
&lt;p&gt;For example:&lt;/p&gt;
&lt;p&gt;# cd /sys/kernel/tracing
 # chgrp 1002 current_tracer
 # ls -l
[..]
 -rw-r-----  1 root root 0 May  1 21:25 buffer_size_kb
 -rw-r-----  1 root root 0 May  1 21:25 buffer_subbuf_size_kb
 -r--r-----  1 root root 0 May  1 21:25 buffer_total_size_kb
 -rw-r-----  1 root lkp  0 May  1 21:25 current_tracer
 -rw-r-----  1 root root 0 May  1 21:25 dynamic_events
 -r--r-----  1 root root 0 May  1 21:25 dyn_ftrace_total_info
 -r--r-----  1 root root 0 May  1 21:25 enabled_functions&lt;/p&gt;
&lt;p&gt;Where…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-2r24-5j8r-cf83</guid>
    </item>
    <item>
      <title>OESA-2024-2296 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2024-2296</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS: 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;
apparmor: Fix null pointer deref when receiving skb during sock creation&#13;
&#13;
The panic below is observed when receiving ICMP packets with secmark set
while an ICMP raw socket is being created. SK_CTX(sk)-&amp;amp;gt;label is updated
in apparmor_socket_post_create(), but the packet is delivered to the
socket before that, causing the null pointer dereference.
Drop the packet if label context is not set.&#13;
&#13;
    BUG: kernel NULL pointer dereference, address: 000000000000004c
    #PF: supervisor read access in kernel mode
    #PF: error_code(0x0000) - not-present page
    PGD 0 P4D 0
    Oops: 0000 [#1] PREEMPT SMP NOPTI
    CPU: 0 PID: 407 Comm: a.out Not tainted 6.4.12-arch1-1 #1 3e6fa2753a2d75925c34ecb78e22e85a65d083df
    Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/28/2020
    RIP: 0010:aa_label_next_confined+0xb/0x40
    Code: 00 00 48 89 ef e8 d5 25 0c 00 e9 66 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 89 f0 &amp;amp;lt;8b&amp;amp;gt; 77 4c 39 c6 7e 1f 48 63 d0 48 8d 14 d7 eb 0b 83 c0 01 48 83 c2
    RSP: 0018:ffffa92940003b08 EFLAGS: 00010246
    RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000000e
    RDX: ffffa92940003be8 RSI: 0000000000000000 RDI: 0000000000000000
    RBP: ffff8b57471e7800 R08: ffff8b574c642400 R09: 0000000000000002
    R10:…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS: 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;
apparmor: Fix null pointer deref when receiving skb during sock creation&#13;
&#13;
The panic below is observed when receiving ICMP packets with secmark set
while an ICMP raw socket is being created. SK_CTX(sk)-&amp;amp;gt;label is updated
in apparmor_socket_post_create(), but the packet is delivered to the
socket before that, causing the null pointer dereference.
Drop the packet if label context is not set.&#13;
&#13;
    BUG: kernel NULL pointer dereference, address: 000000000000004c
    #PF: supervisor read access in kernel mode
    #PF: error_code(0x0000) - not-present page
    PGD 0 P4D 0
    Oops: 0000 [#1] PREEMPT SMP NOPTI
    CPU: 0 PID: 407 Comm: a.out Not tainted 6.4.12-arch1-1 #1 3e6fa2753a2d75925c34ecb78e22e85a65d083df
    Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/28/2020
    RIP: 0010:aa_label_next_confined+0xb/0x40
    Code: 00 00 48 89 ef e8 d5 25 0c 00 e9 66 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 89 f0 &amp;amp;lt;8b&amp;amp;gt; 77 4c 39 c6 7e 1f 48 63 d0 48 8d 14 d7 eb 0b 83 c0 01 48 83 c2
    RSP: 0018:ffffa92940003b08 EFLAGS: 00010246
    RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000000e
    RDX: ffffa92940003be8 RSI: 0000000000000000 RDI: 0000000000000000
    RBP: ffff8b57471e7800 R08: ffff8b574c642400 R09: 0000000000000002
    R10:…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2024-2296</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2024-36963</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-36963</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 78 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: tracefs: Reset permissions on remount if permissions are options There&amp;#39;s an inconsistency with the way permissions are handled in tracefs. Because the permissions are generated when accessed, they default to the root inode&amp;#39;s permission if they were never set by the user. If the user sets the permissions, then a flag is set and the permissions are saved via the inode (for tracefs files) or an internal attribute field (for eventfs). But if a remount happens that specify the permissions, all the files that were not changed by the user gets updated, but the ones that were are not. If the user were to remount the file system with a given permission, then all files and directories within that file system should be updated. This can cause security issues if a file&amp;#39;s permission was updated but the admin forgot about it. They could incorrectly think that remounting with permissions set would update all files, but miss some. For example:  # cd /sys/kernel/tracing  # chgrp 1002 current_tracer  # ls -l [..]  -rw-r-----  1 root root 0 May  1 21:25 buffer_size_kb  -rw-r-----  1 root root 0 May  1 21:25 buffer_subbuf_size_kb  -r--r-----  1 root root 0 May  1 21:25 buffer_total_size_kb  -rw-r-----  1 root lkp  0 May  1 21:25 current_tracer  -rw-r-----  1 root root 0 May  1 21:25 dynamic_events  -r--r-----  1 root root 0 May  1 21:25 dyn_ftrace_total_info  -r--r-----  1 root root 0 May  1 21:25 enabled_functions Where curren…&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 78 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: tracefs: Reset permissions on remount if permissions are options There&amp;#39;s an inconsistency with the way permissions are handled in tracefs. Because the permissions are generated when accessed, they default to the root inode&amp;#39;s permission if they were never set by the user. If the user sets the permissions, then a flag is set and the permissions are saved via the inode (for tracefs files) or an internal attribute field (for eventfs). But if a remount happens that specify the permissions, all the files that were not changed by the user gets updated, but the ones that were are not. If the user were to remount the file system with a given permission, then all files and directories within that file system should be updated. This can cause security issues if a file&amp;#39;s permission was updated but the admin forgot about it. They could incorrectly think that remounting with permissions set would update all files, but miss some. For example:  # cd /sys/kernel/tracing  # chgrp 1002 current_tracer  # ls -l [..]  -rw-r-----  1 root root 0 May  1 21:25 buffer_size_kb  -rw-r-----  1 root root 0 May  1 21:25 buffer_subbuf_size_kb  -r--r-----  1 root root 0 May  1 21:25 buffer_total_size_kb  -rw-r-----  1 root lkp  0 May  1 21:25 current_tracer  -rw-r-----  1 root root 0 May  1 21:25 dynamic_events  -r--r-----  1 root root 0 May  1 21:25 dyn_ftrace_total_info  -r--r-----  1 root root 0 May  1 21:25 enabled_functions Where curren…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-36963</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-1268 — Linux Kernel: Mehrere Schwachstellen ermöglichen nicht spezifizierten Angriff</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1268</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher 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 nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1268</guid>
    </item>
  </channel>
</rss>
