<?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-05T22:29:25.221418+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-02251</id>
    <title>bdu:2026-02251</title>
    <updated>2026-10-05T22:29:25.551697+00:00</updated>
    <content>bdu:2026-02251</content>
    <link href="https://cve.radiocsirt.org/vuln/bdu:2026-02251"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/certfr-2025-avi-0307</id>
    <title>certfr-2025-avi-0307 — 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-05T22:29:25.551757+00:00</updated>
    <content>certfr-2025-avi-0307</content>
    <link href="https://cve.radiocsirt.org/vuln/certfr-2025-avi-0307"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-353022</id>
    <title>EUVD-2026-353022</title>
    <updated>2026-10-05T22:29:25.551778+00:00</updated>
    <content>EUVD-2026-353022</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-353022"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2022-49518</id>
    <title>fkie_cve-2022-49518</title>
    <updated>2026-10-05T22:29:25.551791+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>ASoC: SOF: ipc3-topology: Correct get_control_data for non bytes payload</p>
<p>It is possible to craft a topology where sof_get_control_data() would do
out of bounds access because it expects that it is only called when the
payload is bytes type.
Confusingly it also handles other types of controls, but the payload
parsing implementation is only valid for bytes.</p>
<p>Fix the code to count the non bytes controls and instead of storing a
pointer to sof_abi_hdr in sof_widget_data (which is only valid for bytes),
store the pointer to the data itself and add a new member to save the size
of the data.</p>
<p>In case of non bytes controls we store the pointer to the chanv itself,
which is just an array of values at the end.</p>
<p>In case of bytes control, drop the wrong cdata-&gt;data (wdata[i].pdata) check
against NULL since it is incorrect and invalid in this context.
The data is pointing to the end of cdata struct, so it should never be
null.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2022-49518"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-38r6-jgr4-hw3h</id>
    <title>GHSA-38r6-jgr4-hw3h</title>
    <updated>2026-10-05T22:29:25.551832+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>ASoC: SOF: ipc3-topology: Correct get_control_data for non bytes payload</p>
<p>It is possible to craft a topology where sof_get_control_data() would do
out of bounds access because it expects that it is only called when the
payload is bytes type.
Confusingly it also handles other types of controls, but the payload
parsing implementation is only valid for bytes.</p>
<p>Fix the code to count the non bytes controls and instead of storing a
pointer to sof_abi_hdr in sof_widget_data (which is only valid for bytes),
store the pointer to the data itself and add a new member to save the size
of the data.</p>
<p>In case of non bytes controls we store the pointer to the chanv itself,
which is just an array of values at the end.</p>
<p>In case of bytes control, drop the wrong cdata-&gt;data (wdata[i].pdata) check
against NULL since it is incorrect and invalid in this context.
The data is pointing to the end of cdata struct, so it should never be
null.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-38r6-jgr4-hw3h"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/suse-su-2025:1176-1</id>
    <title>SUSE-SU-2025:1176-1 — Security update for the Linux Kernel</title>
    <updated>2026-10-05T22:29:25.551856+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-2025:1176-1"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-49518</id>
    <title>UBUNTU-CVE-2022-49518</title>
    <updated>2026-10-05T22:29:25.552213+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 162 more</p>
<p>In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: ipc3-topology: Correct get_control_data for non bytes payload It is possible to craft a topology where sof_get_control_data() would do out of bounds access because it expects that it is only called when the payload is bytes type. Confusingly it also handles other types of controls, but the payload parsing implementation is only valid for bytes. Fix the code to count the non bytes controls and instead of storing a pointer to sof_abi_hdr in sof_widget_data (which is only valid for bytes), store the pointer to the data itself and add a new member to save the size of the data. In case of non bytes controls we store the pointer to the chanv itself, which is just an array of values at the end. In case of bytes control, drop the wrong cdata-&gt;data (wdata[i].pdata) check against NULL since it is incorrect and invalid in this context. The data is pointing to the end of cdata struct, so it should never be null.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-49518"/>
  </entry>
</feed>
