<?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 04:22:40 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-12249</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-12249</link>
      <description>bdu:2026-12249</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-12249</guid>
    </item>
    <item>
      <title>BELL-CVE-2026-31392</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-31392</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-31392</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0547 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian LTS. Certaines d'entre elles permettent à…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0547</link>
      <description>certfr-2026-avi-0547</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0547</guid>
    </item>
    <item>
      <title>EUVD-2026-347666</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-347666</link>
      <description>EUVD-2026-347666</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-347666</guid>
    </item>
    <item>
      <title>fkie_cve-2026-31392</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-31392</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;smb: client: fix krb5 mount with username option&lt;/p&gt;
&lt;p&gt;Customer reported that some of their krb5 mounts were failing against
a single server as the client was trying to mount the shares with
wrong credentials.  It turned out the client was reusing SMB session
from first mount to try mounting the other shares, even though a
different username= option had been specified to the other mounts.&lt;/p&gt;
&lt;p&gt;By using username mount option along with sec=krb5 to search for
principals from keytab is supported by cifs.upcall(8) since
cifs-utils-4.8.  So fix this by matching username mount option in
match_session() even with Kerberos.&lt;/p&gt;
&lt;p&gt;For example, the second mount below should fail with -ENOKEY as there
is no &amp;#39;foobar&amp;#39; principal in keytab (/etc/krb5.keytab).  The client
ends up reusing SMB session from first mount to perform the second
one, which is wrong.&lt;/p&gt;
&lt;p&gt;```
$ ktutil
ktutil:  add_entry -password -p testuser -k 1 -e aes256-cts
Password for testuser@ZELDA.TEST:
ktutil:  write_kt /etc/krb5.keytab
ktutil:  quit
$ klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
 ---- ----------------------------------------------------------------
   1 testuser@ZELDA.TEST (aes256-cts-hmac-sha1-96)
$ mount.cifs //w22-root2/scratch /mnt/1 -o sec=krb5,username=testuser
$ mount.cifs //w22-root2/scratch /mnt/2 -o sec=krb5,username=foobar
$ mount -t cifs | grep -Po &amp;#39;username=\K\w+&amp;#39;
testuser
testuser
```&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;smb: client: fix krb5 mount with username option&lt;/p&gt;
&lt;p&gt;Customer reported that some of their krb5 mounts were failing against
a single server as the client was trying to mount the shares with
wrong credentials.  It turned out the client was reusing SMB session
from first mount to try mounting the other shares, even though a
different username= option had been specified to the other mounts.&lt;/p&gt;
&lt;p&gt;By using username mount option along with sec=krb5 to search for
principals from keytab is supported by cifs.upcall(8) since
cifs-utils-4.8.  So fix this by matching username mount option in
match_session() even with Kerberos.&lt;/p&gt;
&lt;p&gt;For example, the second mount below should fail with -ENOKEY as there
is no &amp;#39;foobar&amp;#39; principal in keytab (/etc/krb5.keytab).  The client
ends up reusing SMB session from first mount to perform the second
one, which is wrong.&lt;/p&gt;
&lt;p&gt;```
$ ktutil
ktutil:  add_entry -password -p testuser -k 1 -e aes256-cts
Password for testuser@ZELDA.TEST:
ktutil:  write_kt /etc/krb5.keytab
ktutil:  quit
$ klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
 ---- ----------------------------------------------------------------
   1 testuser@ZELDA.TEST (aes256-cts-hmac-sha1-96)
$ mount.cifs //w22-root2/scratch /mnt/1 -o sec=krb5,username=testuser
$ mount.cifs //w22-root2/scratch /mnt/2 -o sec=krb5,username=foobar
$ mount -t cifs | grep -Po &amp;#39;username=\K\w+&amp;#39;
testuser
testuser
```&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-31392</guid>
    </item>
    <item>
      <title>GHSA-h833-487p-56g8</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-h833-487p-56g8</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;smb: client: fix krb5 mount with username option&lt;/p&gt;
&lt;p&gt;Customer reported that some of their krb5 mounts were failing against
a single server as the client was trying to mount the shares with
wrong credentials.  It turned out the client was reusing SMB session
from first mount to try mounting the other shares, even though a
different username= option had been specified to the other mounts.&lt;/p&gt;
&lt;p&gt;By using username mount option along with sec=krb5 to search for
principals from keytab is supported by cifs.upcall(8) since
cifs-utils-4.8.  So fix this by matching username mount option in
match_session() even with Kerberos.&lt;/p&gt;
&lt;p&gt;For example, the second mount below should fail with -ENOKEY as there
is no &amp;#39;foobar&amp;#39; principal in keytab (/etc/krb5.keytab).  The client
ends up reusing SMB session from first mount to perform the second
one, which is wrong.&lt;/p&gt;
&lt;p&gt;```
$ ktutil
ktutil:  add_entry -password -p testuser -k 1 -e aes256-cts
Password for testuser@ZELDA.TEST:
ktutil:  write_kt /etc/krb5.keytab
ktutil:  quit
$ klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
 ---- ----------------------------------------------------------------
   1 testuser@ZELDA.TEST (aes256-cts-hmac-sha1-96)
$ mount.cifs //w22-root2/scratch /mnt/1 -o sec=krb5,username=testuser
$ mount.cifs //w22-root2/scratch /mnt/2 -o sec=krb5,username=foobar
$ mount -t cifs | grep -Po &amp;#39;username=\K\w+&amp;#39;
testuser
testuser
```&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;smb: client: fix krb5 mount with username option&lt;/p&gt;
&lt;p&gt;Customer reported that some of their krb5 mounts were failing against
a single server as the client was trying to mount the shares with
wrong credentials.  It turned out the client was reusing SMB session
from first mount to try mounting the other shares, even though a
different username= option had been specified to the other mounts.&lt;/p&gt;
&lt;p&gt;By using username mount option along with sec=krb5 to search for
principals from keytab is supported by cifs.upcall(8) since
cifs-utils-4.8.  So fix this by matching username mount option in
match_session() even with Kerberos.&lt;/p&gt;
&lt;p&gt;For example, the second mount below should fail with -ENOKEY as there
is no &amp;#39;foobar&amp;#39; principal in keytab (/etc/krb5.keytab).  The client
ends up reusing SMB session from first mount to perform the second
one, which is wrong.&lt;/p&gt;
&lt;p&gt;```
$ ktutil
ktutil:  add_entry -password -p testuser -k 1 -e aes256-cts
Password for testuser@ZELDA.TEST:
ktutil:  write_kt /etc/krb5.keytab
ktutil:  quit
$ klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
 ---- ----------------------------------------------------------------
   1 testuser@ZELDA.TEST (aes256-cts-hmac-sha1-96)
$ mount.cifs //w22-root2/scratch /mnt/1 -o sec=krb5,username=testuser
$ mount.cifs //w22-root2/scratch /mnt/2 -o sec=krb5,username=foobar
$ mount -t cifs | grep -Po &amp;#39;username=\K\w+&amp;#39;
testuser
testuser
```&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-h833-487p-56g8</guid>
    </item>
    <item>
      <title>OESA-2026-2076 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2026-2076</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;tcp: Clear tcp_sk(sk)-&amp;amp;gt;fastopen_rsk in tcp_disconnect().&lt;/p&gt;
&lt;p&gt;syzbot reported the splat below where a socket had tcp_sk(sk)-&amp;amp;gt;fastopen_rsk
in the TCP_ESTABLISHED state. [0]&lt;/p&gt;
&lt;p&gt;syzbot reused the server-side TCP Fast Open socket as a new client before
the TFO socket completes 3WHS:&lt;/p&gt;
&lt;p&gt;1. accept()
  2. connect(AF_UNSPEC)
  3. connect() to another destination&lt;/p&gt;
&lt;p&gt;As of accept(), sk-&amp;amp;gt;sk_state is TCP_SYN_RECV, and tcp_disconnect() changes
it to TCP_CLOSE and makes connect() possible, which restarts timers.&lt;/p&gt;
&lt;p&gt;Since tcp_disconnect() forgot to clear tcp_sk(sk)-&amp;amp;gt;fastopen_rsk, the
retransmit timer triggered the warning and the intended packet was not
retransmitted.&lt;/p&gt;
&lt;p&gt;Let&amp;amp;apos;s call reqsk_fastopen_remove() in tcp_disconnect().&lt;/p&gt;
&lt;p&gt;[0]:
WARNING: CPU: 2 PID: 0 at net/ipv4/tcp_timer.c:542 tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))
Modules linked in:
CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))
Code: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 &amp;amp;lt;0f&amp;amp;gt; 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3e
RSP: 0018:ffffc…&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;tcp: Clear tcp_sk(sk)-&amp;amp;gt;fastopen_rsk in tcp_disconnect().&lt;/p&gt;
&lt;p&gt;syzbot reported the splat below where a socket had tcp_sk(sk)-&amp;amp;gt;fastopen_rsk
in the TCP_ESTABLISHED state. [0]&lt;/p&gt;
&lt;p&gt;syzbot reused the server-side TCP Fast Open socket as a new client before
the TFO socket completes 3WHS:&lt;/p&gt;
&lt;p&gt;1. accept()
  2. connect(AF_UNSPEC)
  3. connect() to another destination&lt;/p&gt;
&lt;p&gt;As of accept(), sk-&amp;amp;gt;sk_state is TCP_SYN_RECV, and tcp_disconnect() changes
it to TCP_CLOSE and makes connect() possible, which restarts timers.&lt;/p&gt;
&lt;p&gt;Since tcp_disconnect() forgot to clear tcp_sk(sk)-&amp;amp;gt;fastopen_rsk, the
retransmit timer triggered the warning and the intended packet was not
retransmitted.&lt;/p&gt;
&lt;p&gt;Let&amp;amp;apos;s call reqsk_fastopen_remove() in tcp_disconnect().&lt;/p&gt;
&lt;p&gt;[0]:
WARNING: CPU: 2 PID: 0 at net/ipv4/tcp_timer.c:542 tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))
Modules linked in:
CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))
Code: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 &amp;amp;lt;0f&amp;amp;gt; 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3e
RSP: 0018:ffffc…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2026-2076</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:20826-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:20826-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:20826-1</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:21834-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2026:21834-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:21834-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-31392</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-31392</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 232 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: smb: client: fix krb5 mount with username option Customer reported that some of their krb5 mounts were failing against a single server as the client was trying to mount the shares with wrong credentials.  It turned out the client was reusing SMB session from first mount to try mounting the other shares, even though a different username= option had been specified to the other mounts. By using username mount option along with sec=krb5 to search for principals from keytab is supported by cifs.upcall(8) since cifs-utils-4.8.  So fix this by matching username mount option in match_session() even with Kerberos. For example, the second mount below should fail with -ENOKEY as there is no &amp;#39;foobar&amp;#39; principal in keytab (/etc/krb5.keytab).  The client ends up reusing SMB session from first mount to perform the second one, which is wrong. ``` $ ktutil ktutil:  add_entry -password -p testuser -k 1 -e aes256-cts Password for testuser@ZELDA.TEST: ktutil:  write_kt /etc/krb5.keytab ktutil:  quit $ klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal  ---- ----------------------------------------------------------------    1 testuser@ZELDA.TEST (aes256-cts-hmac-sha1-96) $ mount.cifs //w22-root2/scratch /mnt/1 -o sec=krb5,username=testuser $ mount.cifs //w22-root2/scratch /mnt/2 -o sec=krb5,username=foobar $ mount -t cifs | grep -Po &amp;#39;username=\K\w+&amp;#39; testuser testuser ```&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 232 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: smb: client: fix krb5 mount with username option Customer reported that some of their krb5 mounts were failing against a single server as the client was trying to mount the shares with wrong credentials.  It turned out the client was reusing SMB session from first mount to try mounting the other shares, even though a different username= option had been specified to the other mounts. By using username mount option along with sec=krb5 to search for principals from keytab is supported by cifs.upcall(8) since cifs-utils-4.8.  So fix this by matching username mount option in match_session() even with Kerberos. For example, the second mount below should fail with -ENOKEY as there is no &amp;#39;foobar&amp;#39; principal in keytab (/etc/krb5.keytab).  The client ends up reusing SMB session from first mount to perform the second one, which is wrong. ``` $ ktutil ktutil:  add_entry -password -p testuser -k 1 -e aes256-cts Password for testuser@ZELDA.TEST: ktutil:  write_kt /etc/krb5.keytab ktutil:  quit $ klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal  ---- ----------------------------------------------------------------    1 testuser@ZELDA.TEST (aes256-cts-hmac-sha1-96) $ mount.cifs //w22-root2/scratch /mnt/1 -o sec=krb5,username=testuser $ mount.cifs //w22-root2/scratch /mnt/2 -o sec=krb5,username=foobar $ mount -t cifs | grep -Po &amp;#39;username=\K\w+&amp;#39; testuser testuser ```&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-31392</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-0985 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0985</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um unter anderem einen Denial of Service-Angriff auszuführen oder um Sicherheitsmechanismen zu umgehen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um unter anderem einen Denial of Service-Angriff auszuführen oder um Sicherheitsmechanismen zu umgehen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0985</guid>
    </item>
  </channel>
</rss>
