<?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 14:28:27 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-13569</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-13569</link>
      <description>bdu:2025-13569</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-13569</guid>
    </item>
    <item>
      <title>BELL-CVE-2025-40016</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2025-40016</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-2025-40016</guid>
    </item>
    <item>
      <title>certfr-2025-avi-0915 — De multiples vulnérabilités ont été découvertes dans les produits Microsoft. Elles permettent à un attaquant de provoqu…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2025-avi-0915</link>
      <description>certfr-2025-avi-0915</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2025-avi-0915</guid>
    </item>
    <item>
      <title>EUVD-2026-314861</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-314861</link>
      <description>EUVD-2026-314861</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-314861</guid>
    </item>
    <item>
      <title>fkie_cve-2025-40016</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-40016</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;media: uvcvideo: Mark invalid entities with id UVC_INVALID_ENTITY_ID&lt;/p&gt;
&lt;p&gt;Per UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero
unique ID.&lt;/p&gt;
&lt;p&gt;```
Each Unit and Terminal within the video function is assigned a unique
identification number, the Unit ID (UID) or Terminal ID (TID), contained in
the bUnitID or bTerminalID field of the descriptor. The value 0x00 is
reserved for undefined ID,
```&lt;/p&gt;
&lt;p&gt;If we add a new entity with id 0 or a duplicated ID, it will be marked
as UVC_INVALID_ENTITY_ID.&lt;/p&gt;
&lt;p&gt;In a previous attempt commit 3dd075fe8ebb (&amp;#34;media: uvcvideo: Require
entities to have a non-zero unique ID&amp;#34;), we ignored all the invalid units,
this broke a lot of non-compatible cameras. Hopefully we are more lucky
this time.&lt;/p&gt;
&lt;p&gt;This also prevents some syzkaller reproducers from triggering warnings due
to a chain of entities referring to themselves. In one particular case, an
Output Unit is connected to an Input Unit, both with the same ID of 1. But
when looking up for the source ID of the Output Unit, that same entity is
found instead of the input entity, which leads to such warnings.&lt;/p&gt;
&lt;p&gt;In another case, a backward chain was considered finished as the source ID
was 0. Later on, that entity was found, but its pads were not valid.&lt;/p&gt;
&lt;p&gt;Here is a sample stack trace for one of those cases.&lt;/p&gt;
&lt;p&gt;[   20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd
[   20.830206] usb 1-1: Using ep0 maxpacket: 8
[   20.83…&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;media: uvcvideo: Mark invalid entities with id UVC_INVALID_ENTITY_ID&lt;/p&gt;
&lt;p&gt;Per UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero
unique ID.&lt;/p&gt;
&lt;p&gt;```
Each Unit and Terminal within the video function is assigned a unique
identification number, the Unit ID (UID) or Terminal ID (TID), contained in
the bUnitID or bTerminalID field of the descriptor. The value 0x00 is
reserved for undefined ID,
```&lt;/p&gt;
&lt;p&gt;If we add a new entity with id 0 or a duplicated ID, it will be marked
as UVC_INVALID_ENTITY_ID.&lt;/p&gt;
&lt;p&gt;In a previous attempt commit 3dd075fe8ebb (&amp;#34;media: uvcvideo: Require
entities to have a non-zero unique ID&amp;#34;), we ignored all the invalid units,
this broke a lot of non-compatible cameras. Hopefully we are more lucky
this time.&lt;/p&gt;
&lt;p&gt;This also prevents some syzkaller reproducers from triggering warnings due
to a chain of entities referring to themselves. In one particular case, an
Output Unit is connected to an Input Unit, both with the same ID of 1. But
when looking up for the source ID of the Output Unit, that same entity is
found instead of the input entity, which leads to such warnings.&lt;/p&gt;
&lt;p&gt;In another case, a backward chain was considered finished as the source ID
was 0. Later on, that entity was found, but its pads were not valid.&lt;/p&gt;
&lt;p&gt;Here is a sample stack trace for one of those cases.&lt;/p&gt;
&lt;p&gt;[   20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd
[   20.830206] usb 1-1: Using ep0 maxpacket: 8
[   20.83…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-40016</guid>
    </item>
    <item>
      <title>GHSA-6jvm-59q4-2x6g</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-6jvm-59q4-2x6g</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;media: uvcvideo: Mark invalid entities with id UVC_INVALID_ENTITY_ID&lt;/p&gt;
&lt;p&gt;Per UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero
unique ID.&lt;/p&gt;
&lt;p&gt;```
Each Unit and Terminal within the video function is assigned a unique
identification number, the Unit ID (UID) or Terminal ID (TID), contained in
the bUnitID or bTerminalID field of the descriptor. The value 0x00 is
reserved for undefined ID,
```&lt;/p&gt;
&lt;p&gt;If we add a new entity with id 0 or a duplicated ID, it will be marked
as UVC_INVALID_ENTITY_ID.&lt;/p&gt;
&lt;p&gt;In a previous attempt commit 3dd075fe8ebb (&amp;#34;media: uvcvideo: Require
entities to have a non-zero unique ID&amp;#34;), we ignored all the invalid units,
this broke a lot of non-compatible cameras. Hopefully we are more lucky
this time.&lt;/p&gt;
&lt;p&gt;This also prevents some syzkaller reproducers from triggering warnings due
to a chain of entities referring to themselves. In one particular case, an
Output Unit is connected to an Input Unit, both with the same ID of 1. But
when looking up for the source ID of the Output Unit, that same entity is
found instead of the input entity, which leads to such warnings.&lt;/p&gt;
&lt;p&gt;In another case, a backward chain was considered finished as the source ID
was 0. Later on, that entity was found, but its pads were not valid.&lt;/p&gt;
&lt;p&gt;Here is a sample stack trace for one of those cases.&lt;/p&gt;
&lt;p&gt;[   20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd
[   20.830206] usb 1-1: Using ep0 maxpacket: 8
[   20.83…&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;media: uvcvideo: Mark invalid entities with id UVC_INVALID_ENTITY_ID&lt;/p&gt;
&lt;p&gt;Per UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero
unique ID.&lt;/p&gt;
&lt;p&gt;```
Each Unit and Terminal within the video function is assigned a unique
identification number, the Unit ID (UID) or Terminal ID (TID), contained in
the bUnitID or bTerminalID field of the descriptor. The value 0x00 is
reserved for undefined ID,
```&lt;/p&gt;
&lt;p&gt;If we add a new entity with id 0 or a duplicated ID, it will be marked
as UVC_INVALID_ENTITY_ID.&lt;/p&gt;
&lt;p&gt;In a previous attempt commit 3dd075fe8ebb (&amp;#34;media: uvcvideo: Require
entities to have a non-zero unique ID&amp;#34;), we ignored all the invalid units,
this broke a lot of non-compatible cameras. Hopefully we are more lucky
this time.&lt;/p&gt;
&lt;p&gt;This also prevents some syzkaller reproducers from triggering warnings due
to a chain of entities referring to themselves. In one particular case, an
Output Unit is connected to an Input Unit, both with the same ID of 1. But
when looking up for the source ID of the Output Unit, that same entity is
found instead of the input entity, which leads to such warnings.&lt;/p&gt;
&lt;p&gt;In another case, a backward chain was considered finished as the source ID
was 0. Later on, that entity was found, but its pads were not valid.&lt;/p&gt;
&lt;p&gt;Here is a sample stack trace for one of those cases.&lt;/p&gt;
&lt;p&gt;[   20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd
[   20.830206] usb 1-1: Using ep0 maxpacket: 8
[   20.83…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-6jvm-59q4-2x6g</guid>
    </item>
    <item>
      <title>msrc_CVE-2025-40016 — media: uvcvideo: Mark invalid entities with id UVC_INVALID_ENTITY_ID</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2025-40016</link>
      <description>msrc_CVE-2025-40016</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2025-40016</guid>
    </item>
    <item>
      <title>OESA-2025-2776 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2025-2776</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS-SP2: 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;jfs: add check read-only before txBeginAnon() call&lt;/p&gt;
&lt;p&gt;Added a read-only check before calling `txBeginAnon` in `extAlloc`
and `extRecord`. This prevents modification attempts on a read-only
mounted filesystem, avoiding potential errors or crashes.&lt;/p&gt;
&lt;p&gt;Call trace:
 txBeginAnon+0xac/0x154
 extAlloc+0xe8/0xdec fs/jfs/jfs_extent.c:78
 jfs_get_block+0x340/0xb98 fs/jfs/inode.c:248
 __block_write_begin_int+0x580/0x166c fs/buffer.c:2128
 __block_write_begin fs/buffer.c:2177 [inline]
 block_write_begin+0x98/0x11c fs/buffer.c:2236
 jfs_write_begin+0x44/0x88 fs/jfs/inode.c:299(CVE-2024-58095)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;mm: zswap: properly synchronize freeing resources during CPU hotunplug&lt;/p&gt;
&lt;p&gt;In zswap_compress() and zswap_decompress(), the per-CPU acomp_ctx of the
current CPU at the beginning of the operation is retrieved and used
throughout.  However, since neither preemption nor migration are disabled,
it is possible that the operation continues on a different CPU.&lt;/p&gt;
&lt;p&gt;If the original CPU is hotunplugged while the acomp_ctx is still in use,
we run into a UAF bug as some of the resources attached to the acomp_ctx
are freed during hotunplug in zswap_cpu_comp_dead() (i.e. 
acomp_ctx.buffer, acomp_ctx.req, or acomp_ctx.acomp).&lt;/p&gt;
&lt;p&gt;The problem was introduced in commit 1ec3b5fe6eec (&amp;amp;quot;mm/zswap: move to use
crypto_acom…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS-SP2: 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;jfs: add check read-only before txBeginAnon() call&lt;/p&gt;
&lt;p&gt;Added a read-only check before calling `txBeginAnon` in `extAlloc`
and `extRecord`. This prevents modification attempts on a read-only
mounted filesystem, avoiding potential errors or crashes.&lt;/p&gt;
&lt;p&gt;Call trace:
 txBeginAnon+0xac/0x154
 extAlloc+0xe8/0xdec fs/jfs/jfs_extent.c:78
 jfs_get_block+0x340/0xb98 fs/jfs/inode.c:248
 __block_write_begin_int+0x580/0x166c fs/buffer.c:2128
 __block_write_begin fs/buffer.c:2177 [inline]
 block_write_begin+0x98/0x11c fs/buffer.c:2236
 jfs_write_begin+0x44/0x88 fs/jfs/inode.c:299(CVE-2024-58095)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;mm: zswap: properly synchronize freeing resources during CPU hotunplug&lt;/p&gt;
&lt;p&gt;In zswap_compress() and zswap_decompress(), the per-CPU acomp_ctx of the
current CPU at the beginning of the operation is retrieved and used
throughout.  However, since neither preemption nor migration are disabled,
it is possible that the operation continues on a different CPU.&lt;/p&gt;
&lt;p&gt;If the original CPU is hotunplugged while the acomp_ctx is still in use,
we run into a UAF bug as some of the resources attached to the acomp_ctx
are freed during hotunplug in zswap_cpu_comp_dead() (i.e. 
acomp_ctx.buffer, acomp_ctx.req, or acomp_ctx.acomp).&lt;/p&gt;
&lt;p&gt;The problem was introduced in commit 1ec3b5fe6eec (&amp;amp;quot;mm/zswap: move to use
crypto_acom…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2025-2776</guid>
    </item>
    <item>
      <title>openSUSE-SU-2025:15671-1 — kernel-devel-6.17.5-1.1 on GA media</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2025:15671-1</link>
      <description>&lt;p&gt;kernel-devel-6.17.5-1.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel-devel-6.17.5-1.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2025:15671-1</guid>
    </item>
    <item>
      <title>SUSE-SU-2025:21040-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2025:21040-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-2025:21040-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2025-40016</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-40016</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 170 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Mark invalid entities with id UVC_INVALID_ENTITY_ID Per UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero unique ID. ``` Each Unit and Terminal within the video function is assigned a unique identification number, the Unit ID (UID) or Terminal ID (TID), contained in the bUnitID or bTerminalID field of the descriptor. The value 0x00 is reserved for undefined ID, ``` If we add a new entity with id 0 or a duplicated ID, it will be marked as UVC_INVALID_ENTITY_ID. In a previous attempt commit 3dd075fe8ebb (&amp;#34;media: uvcvideo: Require entities to have a non-zero unique ID&amp;#34;), we ignored all the invalid units, this broke a lot of non-compatible cameras. Hopefully we are more lucky this time. This also prevents some syzkaller reproducers from triggering warnings due to a chain of entities referring to themselves. In one particular case, an Output Unit is connected to an Input Unit, both with the same ID of 1. But when looking up for the source ID of the Output Unit, that same entity is found instead of the input entity, which leads to such warnings. In another case, a backward chain was considered finished as the source ID was 0. Later on, that entity was found, but its pads were not valid. Here is a sample stack trace for one of those cases. [   20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd [   20.830206] usb 1-1: Using ep0 maxpacket: 8 [   20.833501] usb…&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 170 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Mark invalid entities with id UVC_INVALID_ENTITY_ID Per UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero unique ID. ``` Each Unit and Terminal within the video function is assigned a unique identification number, the Unit ID (UID) or Terminal ID (TID), contained in the bUnitID or bTerminalID field of the descriptor. The value 0x00 is reserved for undefined ID, ``` If we add a new entity with id 0 or a duplicated ID, it will be marked as UVC_INVALID_ENTITY_ID. In a previous attempt commit 3dd075fe8ebb (&amp;#34;media: uvcvideo: Require entities to have a non-zero unique ID&amp;#34;), we ignored all the invalid units, this broke a lot of non-compatible cameras. Hopefully we are more lucky this time. This also prevents some syzkaller reproducers from triggering warnings due to a chain of entities referring to themselves. In one particular case, an Output Unit is connected to an Input Unit, both with the same ID of 1. But when looking up for the source ID of the Output Unit, that same entity is found instead of the input entity, which leads to such warnings. In another case, a backward chain was considered finished as the source ID was 0. Later on, that entity was found, but its pads were not valid. Here is a sample stack trace for one of those cases. [   20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd [   20.830206] usb 1-1: Using ep0 maxpacket: 8 [   20.833501] usb…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-40016</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-2350 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2350</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere, nicht näher bezeichnete Angriffe durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere, nicht näher bezeichnete Angriffe durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2350</guid>
    </item>
  </channel>
</rss>
