<?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>Sun, 04 Oct 2026 10:22:19 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-93067</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-93067</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-93067</guid>
    </item>
    <item>
      <title>certfr-2026-avi-1253 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian. Certaines d'entre elles permettent à un…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-1253</link>
      <description>certfr-2026-avi-1253</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-1253</guid>
    </item>
    <item>
      <title>EUVD-2026-371111</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-371111</link>
      <description>EUVD-2026-371111</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-371111</guid>
    </item>
    <item>
      <title>fkie_cve-2026-93067</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-93067</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;drm/bridge: tc358767: clamp the reported AUX read size to the request&lt;/p&gt;
&lt;p&gt;tc_aux_transfer() clamps an AUX read to the payload limit:&lt;/p&gt;
&lt;p&gt;size_t size = min_t(size_t, DP_AUX_MAX_PAYLOAD_BYTES - 1, msg-&amp;gt;size);&lt;/p&gt;
&lt;p&gt;After the transfer it replaces size with the byte count the controller
reports in AUX_BYTES:&lt;/p&gt;
&lt;p&gt;if (size)
		size = FIELD_GET(AUX_BYTES, auxstatus);&lt;/p&gt;
&lt;p&gt;AUX_BYTES is GENMASK(15, 8), so it can be up to 255. Nothing clamps it
back to the request. tc_aux_read_data() reads that many bytes into the
16-byte auxrdata stack buffer, then copies them into the caller buffer. A
reported count of 255 makes the read run to 256 bytes and overruns both.&lt;/p&gt;
&lt;p&gt;The controller should never report more than it was asked to transfer, so
this is defense in depth rather than a live hole. The reported count is
only lightly trusted, and the check is cheap. Clamp it back to the request,
the same way ti-sn65dsi86 does in commit aca58eac52b8 (&amp;#34;drm/bridge:
ti-sn65dsi86: Never store more than msg-&amp;gt;size bytes in AUX xfer&amp;#34;).&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;drm/bridge: tc358767: clamp the reported AUX read size to the request&lt;/p&gt;
&lt;p&gt;tc_aux_transfer() clamps an AUX read to the payload limit:&lt;/p&gt;
&lt;p&gt;size_t size = min_t(size_t, DP_AUX_MAX_PAYLOAD_BYTES - 1, msg-&amp;gt;size);&lt;/p&gt;
&lt;p&gt;After the transfer it replaces size with the byte count the controller
reports in AUX_BYTES:&lt;/p&gt;
&lt;p&gt;if (size)
		size = FIELD_GET(AUX_BYTES, auxstatus);&lt;/p&gt;
&lt;p&gt;AUX_BYTES is GENMASK(15, 8), so it can be up to 255. Nothing clamps it
back to the request. tc_aux_read_data() reads that many bytes into the
16-byte auxrdata stack buffer, then copies them into the caller buffer. A
reported count of 255 makes the read run to 256 bytes and overruns both.&lt;/p&gt;
&lt;p&gt;The controller should never report more than it was asked to transfer, so
this is defense in depth rather than a live hole. The reported count is
only lightly trusted, and the check is cheap. Clamp it back to the request,
the same way ti-sn65dsi86 does in commit aca58eac52b8 (&amp;#34;drm/bridge:
ti-sn65dsi86: Never store more than msg-&amp;gt;size bytes in AUX xfer&amp;#34;).&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-93067</guid>
    </item>
    <item>
      <title>GHSA-wpcc-v879-hj4w</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-wpcc-v879-hj4w</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;drm/bridge: tc358767: clamp the reported AUX read size to the request&lt;/p&gt;
&lt;p&gt;tc_aux_transfer() clamps an AUX read to the payload limit:&lt;/p&gt;
&lt;p&gt;size_t size = min_t(size_t, DP_AUX_MAX_PAYLOAD_BYTES - 1, msg-&amp;gt;size);&lt;/p&gt;
&lt;p&gt;After the transfer it replaces size with the byte count the controller
reports in AUX_BYTES:&lt;/p&gt;
&lt;p&gt;if (size)
		size = FIELD_GET(AUX_BYTES, auxstatus);&lt;/p&gt;
&lt;p&gt;AUX_BYTES is GENMASK(15, 8), so it can be up to 255. Nothing clamps it
back to the request. tc_aux_read_data() reads that many bytes into the
16-byte auxrdata stack buffer, then copies them into the caller buffer. A
reported count of 255 makes the read run to 256 bytes and overruns both.&lt;/p&gt;
&lt;p&gt;The controller should never report more than it was asked to transfer, so
this is defense in depth rather than a live hole. The reported count is
only lightly trusted, and the check is cheap. Clamp it back to the request,
the same way ti-sn65dsi86 does in commit aca58eac52b8 (&amp;#34;drm/bridge:
ti-sn65dsi86: Never store more than msg-&amp;gt;size bytes in AUX xfer&amp;#34;).&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;drm/bridge: tc358767: clamp the reported AUX read size to the request&lt;/p&gt;
&lt;p&gt;tc_aux_transfer() clamps an AUX read to the payload limit:&lt;/p&gt;
&lt;p&gt;size_t size = min_t(size_t, DP_AUX_MAX_PAYLOAD_BYTES - 1, msg-&amp;gt;size);&lt;/p&gt;
&lt;p&gt;After the transfer it replaces size with the byte count the controller
reports in AUX_BYTES:&lt;/p&gt;
&lt;p&gt;if (size)
		size = FIELD_GET(AUX_BYTES, auxstatus);&lt;/p&gt;
&lt;p&gt;AUX_BYTES is GENMASK(15, 8), so it can be up to 255. Nothing clamps it
back to the request. tc_aux_read_data() reads that many bytes into the
16-byte auxrdata stack buffer, then copies them into the caller buffer. A
reported count of 255 makes the read run to 256 bytes and overruns both.&lt;/p&gt;
&lt;p&gt;The controller should never report more than it was asked to transfer, so
this is defense in depth rather than a live hole. The reported count is
only lightly trusted, and the check is cheap. Clamp it back to the request,
the same way ti-sn65dsi86 does in commit aca58eac52b8 (&amp;#34;drm/bridge:
ti-sn65dsi86: Never store more than msg-&amp;gt;size bytes in AUX xfer&amp;#34;).&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-wpcc-v879-hj4w</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-93067 — drm/bridge: tc358767: clamp the reported AUX read size to the request</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2026-93067</link>
      <description>msrc_CVE-2026-93067</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2026-93067</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:11893-1 — kernel-devel-7.2.8-1.1 on GA media</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:11893-1</link>
      <description>&lt;p&gt;kernel-devel-7.2.8-1.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel-devel-7.2.8-1.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2026:11893-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-93067</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-93067</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:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 219 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: drm/bridge: tc358767: clamp the reported AUX read size to the request tc_aux_transfer() clamps an AUX read to the payload limit: 	size_t size = min_t(size_t, DP_AUX_MAX_PAYLOAD_BYTES - 1, msg-&amp;gt;size); After the transfer it replaces size with the byte count the controller reports in AUX_BYTES: 	if (size) 		size = FIELD_GET(AUX_BYTES, auxstatus); AUX_BYTES is GENMASK(15, 8), so it can be up to 255. Nothing clamps it back to the request. tc_aux_read_data() reads that many bytes into the 16-byte auxrdata stack buffer, then copies them into the caller buffer. A reported count of 255 makes the read run to 256 bytes and overruns both. The controller should never report more than it was asked to transfer, so this is defense in depth rather than a live hole. The reported count is only lightly trusted, and the check is cheap. Clamp it back to the request, the same way ti-sn65dsi86 does in commit aca58eac52b8 (&amp;#34;drm/bridge: ti-sn65dsi86: Never store more than msg-&amp;gt;size bytes in AUX xfer&amp;#34;).&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:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 219 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: drm/bridge: tc358767: clamp the reported AUX read size to the request tc_aux_transfer() clamps an AUX read to the payload limit: 	size_t size = min_t(size_t, DP_AUX_MAX_PAYLOAD_BYTES - 1, msg-&amp;gt;size); After the transfer it replaces size with the byte count the controller reports in AUX_BYTES: 	if (size) 		size = FIELD_GET(AUX_BYTES, auxstatus); AUX_BYTES is GENMASK(15, 8), so it can be up to 255. Nothing clamps it back to the request. tc_aux_read_data() reads that many bytes into the 16-byte auxrdata stack buffer, then copies them into the caller buffer. A reported count of 255 makes the read run to 256 bytes and overruns both. The controller should never report more than it was asked to transfer, so this is defense in depth rather than a live hole. The reported count is only lightly trusted, and the check is cheap. Clamp it back to the request, the same way ti-sn65dsi86 does in commit aca58eac52b8 (&amp;#34;drm/bridge: ti-sn65dsi86: Never store more than msg-&amp;gt;size bytes in AUX xfer&amp;#34;).&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-93067</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-3444 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-3444</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel möglicherweise ausnutzen, um Berechtigungen zu erweitern, Sicherheitsmaßnahmen zu umgehen, Daten offenzulegen oder zu manipulieren, den Speicher zu beschädigen, Denial-of-Service-Zustände zu verursachen oder andere, nicht näher spezifizierte Angriffe durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel möglicherweise ausnutzen, um Berechtigungen zu erweitern, Sicherheitsmaßnahmen zu umgehen, Daten offenzulegen oder zu manipulieren, den Speicher zu beschädigen, Denial-of-Service-Zustände zu verursachen oder andere, nicht näher spezifizierte Angriffe durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-3444</guid>
    </item>
  </channel>
</rss>
