<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-02T22:12:16.739988+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/bdu:2026-09418</id>
    <title>bdu:2026-09418</title>
    <updated>2026-10-02T22:12:17.160276+00:00</updated>
    <content>bdu:2026-09418</content>
    <link href="https://cve.radiocsirt.org/vuln/bdu:2026-09418"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/bell-cve-2025-68340</id>
    <title>BELL-CVE-2025-68340</title>
    <updated>2026-10-02T22:12:17.160355+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/bell-cve-2025-68340"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0108</id>
    <title>certfr-2026-avi-0108 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Certaines d'entre elles permettent à un at…</title>
    <updated>2026-10-02T22:12:17.160409+00:00</updated>
    <content>certfr-2026-avi-0108</content>
    <link href="https://cve.radiocsirt.org/vuln/certfr-2026-avi-0108"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-347491</id>
    <title>EUVD-2026-347491</title>
    <updated>2026-10-02T22:12:17.160438+00:00</updated>
    <content>EUVD-2026-347491</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-347491"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2025-68340</id>
    <title>fkie_cve-2025-68340</title>
    <updated>2026-10-02T22:12:17.160458+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>team: Move team device type change at the end of team_port_add</p>
<p>Attempting to add a port device that is already up will expectedly fail,
but not before modifying the team device header_ops.</p>
<p>In the case of the syzbot reproducer the gre0 device is
already in state UP when it attempts to add it as a
port device of team0, this fails but before that
header_ops-&gt;create of team0 is changed from eth_header to ipgre_header
in the call to team_dev_type_check_change.</p>
<p>Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense
as the private data of the device still holds a struct team.</p>
<p>Example sequence of iproute2 commands to reproduce the hang/BUG():
ip link add dev team0 type team
ip link add dev gre0 type gre
ip link set dev gre0 up
ip link set dev gre0 master team0
ip link set dev team0 up
ping -I team0 1.1.1.1</p>
<p>Move team_dev_type_check_change down where all other checks have passed
as it changes the dev type with no way to restore it in case
one of the checks that follow it fail.</p>
<p>Also make sure to preserve the origial mtu assignment:
  - If port_dev is not the same type as dev, dev takes mtu from port_dev
  - If port_dev is the same type as dev, port_dev takes mtu from dev</p>
<p>This is done by adding a conditional before the call to dev_set_mtu
to prevent it from assigning port_dev-&gt;mtu = dev-&gt;mtu and instead
letting team_dev_type_check_change assign dev-&gt;mtu = port_dev-&gt;mtu.
The conditional is ne…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2025-68340"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-jmpj-vqww-cqc8</id>
    <title>GHSA-jmpj-vqww-cqc8</title>
    <updated>2026-10-02T22:12:17.160538+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>team: Move team device type change at the end of team_port_add</p>
<p>Attempting to add a port device that is already up will expectedly fail,
but not before modifying the team device header_ops.</p>
<p>In the case of the syzbot reproducer the gre0 device is
already in state UP when it attempts to add it as a
port device of team0, this fails but before that
header_ops-&gt;create of team0 is changed from eth_header to ipgre_header
in the call to team_dev_type_check_change.</p>
<p>Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense
as the private data of the device still holds a struct team.</p>
<p>Example sequence of iproute2 commands to reproduce the hang/BUG():
ip link add dev team0 type team
ip link add dev gre0 type gre
ip link set dev gre0 up
ip link set dev gre0 master team0
ip link set dev team0 up
ping -I team0 1.1.1.1</p>
<p>Move team_dev_type_check_change down where all other checks have passed
as it changes the dev type with no way to restore it in case
one of the checks that follow it fail.</p>
<p>Also make sure to preserve the origial mtu assignment:
  - If port_dev is not the same type as dev, dev takes mtu from port_dev
  - If port_dev is the same type as dev, port_dev takes mtu from dev</p>
<p>This is done by adding a conditional before the call to dev_set_mtu
to prevent it from assigning port_dev-&gt;mtu = dev-&gt;mtu and instead
letting team_dev_type_check_change assign dev-&gt;mtu = port_dev-&gt;mtu.
The conditional is ne…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-jmpj-vqww-cqc8"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/msrc_cve-2025-68340</id>
    <title>msrc_CVE-2025-68340 — team: Move team device type change at the end of team_port_add</title>
    <updated>2026-10-02T22:12:17.160593+00:00</updated>
    <content>msrc_CVE-2025-68340</content>
    <link href="https://cve.radiocsirt.org/vuln/msrc_cve-2025-68340"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/oesa-2026-2579</id>
    <title>OESA-2026-2579 — kernel security update</title>
    <updated>2026-10-02T22:12:17.160622+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> openEuler:20.03-LTS-SP4: kernel</p>
<p>The Linux Kernel, the operating system core itself.

Security Fix(es):</p>
<p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>bcache: fix NULL pointer in cache_set_flush()</p>
<p>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.</p>
<p>1794 struct cache_set *bch_cache_set_alloc(struct cache_sb *sb)
 1795 {
 ...
 1860         if (!(c-&amp;gt;devices = kcalloc(c-&amp;gt;nr_uuids, sizeof(void *), GFP_KERNEL)) ||
 1861             mempool_init_slab_pool(&amp;amp;c-&amp;gt;search, 32, bch_search_cache) ||
 1862             mempool_init_kmalloc_pool(&amp;amp;c-&amp;gt;bio_meta, 2,
 1863                                 sizeof(struct bbio) + sizeof(struct bio_vec) *
 1864                                 bucket_pages(c)) ||
 1865             mempool_init_kmalloc_pool(&amp;amp;c-&amp;gt;fill_iter, 1, iter_size) ||
 1866             bioset_init(&amp;amp;c-&amp;gt;bio_split, 4, offsetof(struct bbio, bio),
 1867                         BIOSET_NEED_BVECS|BIOSET_NEED_RESCUER) ||
 1868             !(c-&amp;gt;uuids = alloc_bucket_pages(GFP_KERNEL, c)) ||
 1869             !(c-&amp;gt;moving_gc_wq = alloc_workqueue(&amp;quot;bcache_gc&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…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/oesa-2026-2579"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/opensuse-su-2026:20145-1</id>
    <title>openSUSE-SU-2026:20145-1 — Security update for the Linux Kernel</title>
    <updated>2026-10-02T22:12:17.161112+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Security update for the Linux Kernel</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/opensuse-su-2026:20145-1"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/suse-su-2026:0278-1</id>
    <title>SUSE-SU-2026:0278-1 — Security update for the Linux Kernel</title>
    <updated>2026-10-02T22:12:17.161309+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Security update for the Linux Kernel</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/suse-su-2026:0278-1"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-68340</id>
    <title>UBUNTU-CVE-2025-68340</title>
    <updated>2026-10-02T22:12:17.161636+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> 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 231 more</p>
<p>In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops-&gt;create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment:   - If port_dev is not the same type as dev, dev takes mtu from port_dev   - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev-&gt;mtu = dev-&gt;mtu and instead letting team_dev_type_check_change assign dev-&gt;mtu = port_dev-&gt;mtu. The conditional is needed bec…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-68340"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2915</id>
    <title>WID-SEC-W-2025-2915 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service</title>
    <updated>2026-10-02T22:12:17.162079+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere nicht spezifizierte Angriffe durchzuführen.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2915"/>
  </entry>
</feed>
