<?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 15:21:36 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-74640</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-74640</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2026-74640</guid>
    </item>
    <item>
      <title>EUVD-2026-358530</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-358530</link>
      <description>EUVD-2026-358530</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-358530</guid>
    </item>
    <item>
      <title>fkie_cve-2026-74640</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-74640</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ALSA: FCP: fix OOB write in fcp_meter_ctl_get()&lt;/p&gt;
&lt;p&gt;fcp_ioctl_set_meter_map() bounds the user-supplied Level Meter map size
by the driver&amp;#39;s own limit of 255&lt;/p&gt;
&lt;p&gt;if (map.map_size &amp;lt; 1 || map.map_size &amp;gt; 255 ||
	    map.meter_slots &amp;lt; 1 || map.meter_slots &amp;gt; 255)
		return -EINVAL;&lt;/p&gt;
&lt;p&gt;and passes it to fcp_add_new_ctl() as the control&amp;#39;s channel count, where
it is stored as elem-&amp;gt;channels.&lt;/p&gt;
&lt;p&gt;Every control read writes into struct snd_ctl_elem_value, whose integer
array is declared long value[128], so the limit is 128, not 255.
fcp_meter_ctl_get() stores one 64-bit word per channel into that array
with no bound of its own:&lt;/p&gt;
&lt;p&gt;for (i = 0; i &amp;lt; elem-&amp;gt;channels; i++) {
		int idx = private-&amp;gt;meter_level_map[i];
		int value = idx &amp;lt; 0 ? 0 : le32_to_cpu(resp[idx]);&lt;/p&gt;
&lt;p&gt;ucontrol-&amp;gt;value.integer.value[i] = value;
	}&lt;/p&gt;
&lt;p&gt;snd_ctl_elem_read_user() serves that object from
memdup_user(_control, sizeof(*control)), 1224 bytes on LP64 out of
kmalloc-2048.  offsetof(struct snd_ctl_elem_value, value) is 72, so
element i is written at byte 72 + 8 * i and element 144 already lands
past the allocation.  At map_size 255 the last store ends at byte 2112,
888 bytes past the object and 64 bytes into the adjacent slab object.
The stored words come from the device and meter_level_map[] selects
which word lands in which slot, so extent and contents are both
controlled.&lt;/p&gt;
&lt;p&gt;The core does not catch this.  snd_ctl_check_elem_info() is reached only
from __snd_ctl_elem_i…&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;ALSA: FCP: fix OOB write in fcp_meter_ctl_get()&lt;/p&gt;
&lt;p&gt;fcp_ioctl_set_meter_map() bounds the user-supplied Level Meter map size
by the driver&amp;#39;s own limit of 255&lt;/p&gt;
&lt;p&gt;if (map.map_size &amp;lt; 1 || map.map_size &amp;gt; 255 ||
	    map.meter_slots &amp;lt; 1 || map.meter_slots &amp;gt; 255)
		return -EINVAL;&lt;/p&gt;
&lt;p&gt;and passes it to fcp_add_new_ctl() as the control&amp;#39;s channel count, where
it is stored as elem-&amp;gt;channels.&lt;/p&gt;
&lt;p&gt;Every control read writes into struct snd_ctl_elem_value, whose integer
array is declared long value[128], so the limit is 128, not 255.
fcp_meter_ctl_get() stores one 64-bit word per channel into that array
with no bound of its own:&lt;/p&gt;
&lt;p&gt;for (i = 0; i &amp;lt; elem-&amp;gt;channels; i++) {
		int idx = private-&amp;gt;meter_level_map[i];
		int value = idx &amp;lt; 0 ? 0 : le32_to_cpu(resp[idx]);&lt;/p&gt;
&lt;p&gt;ucontrol-&amp;gt;value.integer.value[i] = value;
	}&lt;/p&gt;
&lt;p&gt;snd_ctl_elem_read_user() serves that object from
memdup_user(_control, sizeof(*control)), 1224 bytes on LP64 out of
kmalloc-2048.  offsetof(struct snd_ctl_elem_value, value) is 72, so
element i is written at byte 72 + 8 * i and element 144 already lands
past the allocation.  At map_size 255 the last store ends at byte 2112,
888 bytes past the object and 64 bytes into the adjacent slab object.
The stored words come from the device and meter_level_map[] selects
which word lands in which slot, so extent and contents are both
controlled.&lt;/p&gt;
&lt;p&gt;The core does not catch this.  snd_ctl_check_elem_info() is reached only
from __snd_ctl_elem_i…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-74640</guid>
    </item>
    <item>
      <title>GHSA-m9m2-qw72-cj43</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-m9m2-qw72-cj43</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ALSA: FCP: fix OOB write in fcp_meter_ctl_get()&lt;/p&gt;
&lt;p&gt;fcp_ioctl_set_meter_map() bounds the user-supplied Level Meter map size
by the driver&amp;#39;s own limit of 255&lt;/p&gt;
&lt;p&gt;if (map.map_size &amp;lt; 1 || map.map_size &amp;gt; 255 ||
	    map.meter_slots &amp;lt; 1 || map.meter_slots &amp;gt; 255)
		return -EINVAL;&lt;/p&gt;
&lt;p&gt;and passes it to fcp_add_new_ctl() as the control&amp;#39;s channel count, where
it is stored as elem-&amp;gt;channels.&lt;/p&gt;
&lt;p&gt;Every control read writes into struct snd_ctl_elem_value, whose integer
array is declared long value[128], so the limit is 128, not 255.
fcp_meter_ctl_get() stores one 64-bit word per channel into that array
with no bound of its own:&lt;/p&gt;
&lt;p&gt;for (i = 0; i &amp;lt; elem-&amp;gt;channels; i++) {
		int idx = private-&amp;gt;meter_level_map[i];
		int value = idx &amp;lt; 0 ? 0 : le32_to_cpu(resp[idx]);&lt;/p&gt;
&lt;p&gt;ucontrol-&amp;gt;value.integer.value[i] = value;
	}&lt;/p&gt;
&lt;p&gt;snd_ctl_elem_read_user() serves that object from
memdup_user(_control, sizeof(*control)), 1224 bytes on LP64 out of
kmalloc-2048.  offsetof(struct snd_ctl_elem_value, value) is 72, so
element i is written at byte 72 + 8 * i and element 144 already lands
past the allocation.  At map_size 255 the last store ends at byte 2112,
888 bytes past the object and 64 bytes into the adjacent slab object.
The stored words come from the device and meter_level_map[] selects
which word lands in which slot, so extent and contents are both
controlled.&lt;/p&gt;
&lt;p&gt;The core does not catch this.  snd_ctl_check_elem_info() is reached only
from __snd_ctl_elem_i…&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;ALSA: FCP: fix OOB write in fcp_meter_ctl_get()&lt;/p&gt;
&lt;p&gt;fcp_ioctl_set_meter_map() bounds the user-supplied Level Meter map size
by the driver&amp;#39;s own limit of 255&lt;/p&gt;
&lt;p&gt;if (map.map_size &amp;lt; 1 || map.map_size &amp;gt; 255 ||
	    map.meter_slots &amp;lt; 1 || map.meter_slots &amp;gt; 255)
		return -EINVAL;&lt;/p&gt;
&lt;p&gt;and passes it to fcp_add_new_ctl() as the control&amp;#39;s channel count, where
it is stored as elem-&amp;gt;channels.&lt;/p&gt;
&lt;p&gt;Every control read writes into struct snd_ctl_elem_value, whose integer
array is declared long value[128], so the limit is 128, not 255.
fcp_meter_ctl_get() stores one 64-bit word per channel into that array
with no bound of its own:&lt;/p&gt;
&lt;p&gt;for (i = 0; i &amp;lt; elem-&amp;gt;channels; i++) {
		int idx = private-&amp;gt;meter_level_map[i];
		int value = idx &amp;lt; 0 ? 0 : le32_to_cpu(resp[idx]);&lt;/p&gt;
&lt;p&gt;ucontrol-&amp;gt;value.integer.value[i] = value;
	}&lt;/p&gt;
&lt;p&gt;snd_ctl_elem_read_user() serves that object from
memdup_user(_control, sizeof(*control)), 1224 bytes on LP64 out of
kmalloc-2048.  offsetof(struct snd_ctl_elem_value, value) is 72, so
element i is written at byte 72 + 8 * i and element 144 already lands
past the allocation.  At map_size 255 the last store ends at byte 2112,
888 bytes past the object and 64 bytes into the adjacent slab object.
The stored words come from the device and meter_level_map[] selects
which word lands in which slot, so extent and contents are both
controlled.&lt;/p&gt;
&lt;p&gt;The core does not catch this.  snd_ctl_check_elem_info() is reached only
from __snd_ctl_elem_i…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-m9m2-qw72-cj43</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-74640</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-74640</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 120 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: ALSA: FCP: fix OOB write in fcp_meter_ctl_get() fcp_ioctl_set_meter_map() bounds the user-supplied Level Meter map size by the driver&amp;#39;s own limit of 255 	if (map.map_size &amp;lt; 1 || map.map_size &amp;gt; 255 || 	    map.meter_slots &amp;lt; 1 || map.meter_slots &amp;gt; 255) 		return -EINVAL; and passes it to fcp_add_new_ctl() as the control&amp;#39;s channel count, where it is stored as elem-&amp;gt;channels. Every control read writes into struct snd_ctl_elem_value, whose integer array is declared long value[128], so the limit is 128, not 255. fcp_meter_ctl_get() stores one 64-bit word per channel into that array with no bound of its own: 	for (i = 0; i &amp;lt; elem-&amp;gt;channels; i++) { 		int idx = private-&amp;gt;meter_level_map[i]; 		int value = idx &amp;lt; 0 ? 0 : le32_to_cpu(resp[idx]); 		ucontrol-&amp;gt;value.integer.value[i] = value; 	} snd_ctl_elem_read_user() serves that object from memdup_user(_control, sizeof(*control)), 1224 bytes on LP64 out of kmalloc-2048.  offsetof(struct snd_ctl_elem_value, value) is 72, so element i is written at byte 72 + 8 * i and element 144 already lands past the allocation.  At map_size 255 the last store ends at byte 2112, 888 bytes past the object and 64 bytes into the adjacent slab object. The stored words come from the device and meter_level_map[] selects which word lands in which slot, so extent and contents are both controlled. The core does not catch this.  snd_ctl_check_elem_info() is reached only from __snd_ctl_elem_info(), wh…&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 120 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: ALSA: FCP: fix OOB write in fcp_meter_ctl_get() fcp_ioctl_set_meter_map() bounds the user-supplied Level Meter map size by the driver&amp;#39;s own limit of 255 	if (map.map_size &amp;lt; 1 || map.map_size &amp;gt; 255 || 	    map.meter_slots &amp;lt; 1 || map.meter_slots &amp;gt; 255) 		return -EINVAL; and passes it to fcp_add_new_ctl() as the control&amp;#39;s channel count, where it is stored as elem-&amp;gt;channels. Every control read writes into struct snd_ctl_elem_value, whose integer array is declared long value[128], so the limit is 128, not 255. fcp_meter_ctl_get() stores one 64-bit word per channel into that array with no bound of its own: 	for (i = 0; i &amp;lt; elem-&amp;gt;channels; i++) { 		int idx = private-&amp;gt;meter_level_map[i]; 		int value = idx &amp;lt; 0 ? 0 : le32_to_cpu(resp[idx]); 		ucontrol-&amp;gt;value.integer.value[i] = value; 	} snd_ctl_elem_read_user() serves that object from memdup_user(_control, sizeof(*control)), 1224 bytes on LP64 out of kmalloc-2048.  offsetof(struct snd_ctl_elem_value, value) is 72, so element i is written at byte 72 + 8 * i and element 144 already lands past the allocation.  At map_size 255 the last store ends at byte 2112, 888 bytes past the object and 64 bytes into the adjacent slab object. The stored words come from the device and meter_level_map[] selects which word lands in which slot, so extent and contents are both controlled. The core does not catch this.  snd_ctl_check_elem_info() is reached only from __snd_ctl_elem_info(), wh…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-74640</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>
