<?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 20:09:50 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-74619</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-74619</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-2026-74619</guid>
    </item>
    <item>
      <title>certfr-2026-avi-1090 — 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-1090</link>
      <description>certfr-2026-avi-1090</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-1090</guid>
    </item>
    <item>
      <title>EUVD-2026-357770</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-357770</link>
      <description>EUVD-2026-357770</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-357770</guid>
    </item>
    <item>
      <title>fkie_cve-2026-74619</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-74619</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ovl: don&amp;#39;t warn when the mount is completed from another user namespace&lt;/p&gt;
&lt;p&gt;fsopen() records the caller&amp;#39;s user namespace in fc-&amp;gt;user_ns and hands
back an ordinary file descriptor. Nothing ties the task that calls
fsconfig(FSCONFIG_CMD_CREATE) to the task that created the context. The
fd is inherited across fork() and exec() and it can be passed over a
unix socket.&lt;/p&gt;
&lt;p&gt;Completing a context from another user namespace is allowed on purpose.
vfs_cmd_create() authorizes the create with mount_capable(), which for
FS_USERNS_MOUNT checks ns_capable(fc-&amp;gt;user_ns, CAP_SYS_ADMIN), and that
succeeds for a task holding CAP_SYS_ADMIN in an ancestor of fc-&amp;gt;user_ns.
So an unprivileged task can reach the WARN_ON() in ovl_fill_super():
create a user and a mount namespace in a child, call fsopen(&amp;#34;overlay&amp;#34;)
there, send the fscontext fd to the parent and let the parent issue
FSCONFIG_CMD_CREATE. Both namespaces come from a plain unshare(1) and no
capability is needed anywhere:&lt;/p&gt;
&lt;p&gt;WARNING: fs/overlayfs/super.c:1551 at ovl_fill_super+0x7b9/0x1e20 [overlay]
  CPU: 3 UID: 1000 PID: 3243376 Comm: fswarn
  Call Trace:
   get_tree_nodev+0x71/0xa0
   ovl_get_tree+0x15/0x20 [overlay]
   vfs_get_tree+0x2a/0x100
   vfs_cmd_create+0x60/0xf0
   __do_sys_fsconfig+0x4b2/0x500&lt;/p&gt;
&lt;p&gt;The child needs the mount namespace because fsopen() itself gates on
may_mount(), which asks for CAP_SYS_ADMIN in the user namespace owning
the caller&amp;#39;s mount namespace. fsco…&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;ovl: don&amp;#39;t warn when the mount is completed from another user namespace&lt;/p&gt;
&lt;p&gt;fsopen() records the caller&amp;#39;s user namespace in fc-&amp;gt;user_ns and hands
back an ordinary file descriptor. Nothing ties the task that calls
fsconfig(FSCONFIG_CMD_CREATE) to the task that created the context. The
fd is inherited across fork() and exec() and it can be passed over a
unix socket.&lt;/p&gt;
&lt;p&gt;Completing a context from another user namespace is allowed on purpose.
vfs_cmd_create() authorizes the create with mount_capable(), which for
FS_USERNS_MOUNT checks ns_capable(fc-&amp;gt;user_ns, CAP_SYS_ADMIN), and that
succeeds for a task holding CAP_SYS_ADMIN in an ancestor of fc-&amp;gt;user_ns.
So an unprivileged task can reach the WARN_ON() in ovl_fill_super():
create a user and a mount namespace in a child, call fsopen(&amp;#34;overlay&amp;#34;)
there, send the fscontext fd to the parent and let the parent issue
FSCONFIG_CMD_CREATE. Both namespaces come from a plain unshare(1) and no
capability is needed anywhere:&lt;/p&gt;
&lt;p&gt;WARNING: fs/overlayfs/super.c:1551 at ovl_fill_super+0x7b9/0x1e20 [overlay]
  CPU: 3 UID: 1000 PID: 3243376 Comm: fswarn
  Call Trace:
   get_tree_nodev+0x71/0xa0
   ovl_get_tree+0x15/0x20 [overlay]
   vfs_get_tree+0x2a/0x100
   vfs_cmd_create+0x60/0xf0
   __do_sys_fsconfig+0x4b2/0x500&lt;/p&gt;
&lt;p&gt;The child needs the mount namespace because fsopen() itself gates on
may_mount(), which asks for CAP_SYS_ADMIN in the user namespace owning
the caller&amp;#39;s mount namespace. fsco…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-74619</guid>
    </item>
    <item>
      <title>GHSA-j34r-65f7-8j2q</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-j34r-65f7-8j2q</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ovl: don&amp;#39;t warn when the mount is completed from another user namespace&lt;/p&gt;
&lt;p&gt;fsopen() records the caller&amp;#39;s user namespace in fc-&amp;gt;user_ns and hands
back an ordinary file descriptor. Nothing ties the task that calls
fsconfig(FSCONFIG_CMD_CREATE) to the task that created the context. The
fd is inherited across fork() and exec() and it can be passed over a
unix socket.&lt;/p&gt;
&lt;p&gt;Completing a context from another user namespace is allowed on purpose.
vfs_cmd_create() authorizes the create with mount_capable(), which for
FS_USERNS_MOUNT checks ns_capable(fc-&amp;gt;user_ns, CAP_SYS_ADMIN), and that
succeeds for a task holding CAP_SYS_ADMIN in an ancestor of fc-&amp;gt;user_ns.
So an unprivileged task can reach the WARN_ON() in ovl_fill_super():
create a user and a mount namespace in a child, call fsopen(&amp;#34;overlay&amp;#34;)
there, send the fscontext fd to the parent and let the parent issue
FSCONFIG_CMD_CREATE. Both namespaces come from a plain unshare(1) and no
capability is needed anywhere:&lt;/p&gt;
&lt;p&gt;WARNING: fs/overlayfs/super.c:1551 at ovl_fill_super+0x7b9/0x1e20 [overlay]
  CPU: 3 UID: 1000 PID: 3243376 Comm: fswarn
  Call Trace:
   get_tree_nodev+0x71/0xa0
   ovl_get_tree+0x15/0x20 [overlay]
   vfs_get_tree+0x2a/0x100
   vfs_cmd_create+0x60/0xf0
   __do_sys_fsconfig+0x4b2/0x500&lt;/p&gt;
&lt;p&gt;The child needs the mount namespace because fsopen() itself gates on
may_mount(), which asks for CAP_SYS_ADMIN in the user namespace owning
the caller&amp;#39;s mount namespace. fsco…&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;ovl: don&amp;#39;t warn when the mount is completed from another user namespace&lt;/p&gt;
&lt;p&gt;fsopen() records the caller&amp;#39;s user namespace in fc-&amp;gt;user_ns and hands
back an ordinary file descriptor. Nothing ties the task that calls
fsconfig(FSCONFIG_CMD_CREATE) to the task that created the context. The
fd is inherited across fork() and exec() and it can be passed over a
unix socket.&lt;/p&gt;
&lt;p&gt;Completing a context from another user namespace is allowed on purpose.
vfs_cmd_create() authorizes the create with mount_capable(), which for
FS_USERNS_MOUNT checks ns_capable(fc-&amp;gt;user_ns, CAP_SYS_ADMIN), and that
succeeds for a task holding CAP_SYS_ADMIN in an ancestor of fc-&amp;gt;user_ns.
So an unprivileged task can reach the WARN_ON() in ovl_fill_super():
create a user and a mount namespace in a child, call fsopen(&amp;#34;overlay&amp;#34;)
there, send the fscontext fd to the parent and let the parent issue
FSCONFIG_CMD_CREATE. Both namespaces come from a plain unshare(1) and no
capability is needed anywhere:&lt;/p&gt;
&lt;p&gt;WARNING: fs/overlayfs/super.c:1551 at ovl_fill_super+0x7b9/0x1e20 [overlay]
  CPU: 3 UID: 1000 PID: 3243376 Comm: fswarn
  Call Trace:
   get_tree_nodev+0x71/0xa0
   ovl_get_tree+0x15/0x20 [overlay]
   vfs_get_tree+0x2a/0x100
   vfs_cmd_create+0x60/0xf0
   __do_sys_fsconfig+0x4b2/0x500&lt;/p&gt;
&lt;p&gt;The child needs the mount namespace because fsopen() itself gates on
may_mount(), which asks for CAP_SYS_ADMIN in the user namespace owning
the caller&amp;#39;s mount namespace. fsco…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-j34r-65f7-8j2q</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-74619 — ovl: don't warn when the mount is completed from another user namespace</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2026-74619</link>
      <description>msrc_CVE-2026-74619</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2026-74619</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-74619</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-74619</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 154 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: ovl: don&amp;#39;t warn when the mount is completed from another user namespace fsopen() records the caller&amp;#39;s user namespace in fc-&amp;gt;user_ns and hands back an ordinary file descriptor. Nothing ties the task that calls fsconfig(FSCONFIG_CMD_CREATE) to the task that created the context. The fd is inherited across fork() and exec() and it can be passed over a unix socket. Completing a context from another user namespace is allowed on purpose. vfs_cmd_create() authorizes the create with mount_capable(), which for FS_USERNS_MOUNT checks ns_capable(fc-&amp;gt;user_ns, CAP_SYS_ADMIN), and that succeeds for a task holding CAP_SYS_ADMIN in an ancestor of fc-&amp;gt;user_ns. So an unprivileged task can reach the WARN_ON() in ovl_fill_super(): create a user and a mount namespace in a child, call fsopen(&amp;#34;overlay&amp;#34;) there, send the fscontext fd to the parent and let the parent issue FSCONFIG_CMD_CREATE. Both namespaces come from a plain unshare(1) and no capability is needed anywhere:   WARNING: fs/overlayfs/super.c:1551 at ovl_fill_super+0x7b9/0x1e20 [overlay]   CPU: 3 UID: 1000 PID: 3243376 Comm: fswarn   Call Trace:    get_tree_nodev+0x71/0xa0    ovl_get_tree+0x15/0x20 [overlay]    vfs_get_tree+0x2a/0x100    vfs_cmd_create+0x60/0xf0    __do_sys_fsconfig+0x4b2/0x500 The child needs the mount namespace because fsopen() itself gates on may_mount(), which asks for CAP_SYS_ADMIN in the user namespace owning the caller&amp;#39;s mount namespace. fsconfig(…&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 154 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: ovl: don&amp;#39;t warn when the mount is completed from another user namespace fsopen() records the caller&amp;#39;s user namespace in fc-&amp;gt;user_ns and hands back an ordinary file descriptor. Nothing ties the task that calls fsconfig(FSCONFIG_CMD_CREATE) to the task that created the context. The fd is inherited across fork() and exec() and it can be passed over a unix socket. Completing a context from another user namespace is allowed on purpose. vfs_cmd_create() authorizes the create with mount_capable(), which for FS_USERNS_MOUNT checks ns_capable(fc-&amp;gt;user_ns, CAP_SYS_ADMIN), and that succeeds for a task holding CAP_SYS_ADMIN in an ancestor of fc-&amp;gt;user_ns. So an unprivileged task can reach the WARN_ON() in ovl_fill_super(): create a user and a mount namespace in a child, call fsopen(&amp;#34;overlay&amp;#34;) there, send the fscontext fd to the parent and let the parent issue FSCONFIG_CMD_CREATE. Both namespaces come from a plain unshare(1) and no capability is needed anywhere:   WARNING: fs/overlayfs/super.c:1551 at ovl_fill_super+0x7b9/0x1e20 [overlay]   CPU: 3 UID: 1000 PID: 3243376 Comm: fswarn   Call Trace:    get_tree_nodev+0x71/0xa0    ovl_get_tree+0x15/0x20 [overlay]    vfs_get_tree+0x2a/0x100    vfs_cmd_create+0x60/0xf0    __do_sys_fsconfig+0x4b2/0x500 The child needs the mount namespace because fsopen() itself gates on may_mount(), which asks for CAP_SYS_ADMIN in the user namespace owning the caller&amp;#39;s mount namespace. fsconfig(…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-74619</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-2970 — Linux Kernel: Mehrere Schwachstellen ermöglichen nicht spezifizierten Angriff</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2970</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, möglicherweise Sicherheitsmaßnahmen zu umgehen, einen Denial-of-Service-Zustand herbeizuführen oder vertrauliche Informationen offenzulegen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, möglicherweise Sicherheitsmaßnahmen zu umgehen, einen Denial-of-Service-Zustand herbeizuführen oder vertrauliche Informationen offenzulegen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2970</guid>
    </item>
  </channel>
</rss>
