https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 10 Oct 2026 08:11:08 +0000 https://cve.radiocsirt.org/vuln/bell-cve-2026-80749 <p><strong>Affected:</strong> Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> https://cve.radiocsirt.org/vuln/bell-cve-2026-80749 https://cve.radiocsirt.org/vuln/certfr-2026-avi-1232 certfr-2026-avi-1232 https://cve.radiocsirt.org/vuln/certfr-2026-avi-1232 https://cve.radiocsirt.org/vuln/euvd-2026-363692 EUVD-2026-363692 https://cve.radiocsirt.org/vuln/euvd-2026-363692 https://cve.radiocsirt.org/vuln/fkie_cve-2026-80749 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>drm/connector/hdmi: Fix out of bounds memory read</p> <p>A helper function was copying a given audio infoframe into the connector&#39;s copy but using the size of the destination (a generic target, sized to accept many different data blocks) not the source (a very specific type of data block). Thus, it was copying 60 bytes of data from a 28 byte allocation.</p> <p>Fix that by using the source size instead, together with a build bug on the source size actually being smaller than the destination.</p> <p>I hit this running KUnit tests under KASAN (while debugging something else entirely). In the real world, it seems unlikely to cause an actual problem. It is a read not a write so it can&#39;t corrupt any memory. However, it could potentially fall off the end of a page and cause an accvio bug.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>drm/connector/hdmi: Fix out of bounds memory read</p> <p>A helper function was copying a given audio infoframe into the connector&#39;s copy but using the size of the destination (a generic target, sized to accept many different data blocks) not the source (a very specific type of data block). Thus, it was copying 60 bytes of data from a 28 byte allocation.</p> <p>Fix that by using the source size instead, together with a build bug on the source size actually being smaller than the destination.</p> <p>I hit this running KUnit tests under KASAN (while debugging something else entirely). In the real world, it seems unlikely to cause an actual problem. It is a read not a write so it can&#39;t corrupt any memory. However, it could potentially fall off the end of a page and cause an accvio bug.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-80749 https://cve.radiocsirt.org/vuln/ghsa-4qvv-f8j2-942j <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>drm/connector/hdmi: Fix out of bounds memory read</p> <p>A helper function was copying a given audio infoframe into the connector&#39;s copy but using the size of the destination (a generic target, sized to accept many different data blocks) not the source (a very specific type of data block). Thus, it was copying 60 bytes of data from a 28 byte allocation.</p> <p>Fix that by using the source size instead, together with a build bug on the source size actually being smaller than the destination.</p> <p>I hit this running KUnit tests under KASAN (while debugging something else entirely). In the real world, it seems unlikely to cause an actual problem. It is a read not a write so it can&#39;t corrupt any memory. However, it could potentially fall off the end of a page and cause an accvio bug.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>drm/connector/hdmi: Fix out of bounds memory read</p> <p>A helper function was copying a given audio infoframe into the connector&#39;s copy but using the size of the destination (a generic target, sized to accept many different data blocks) not the source (a very specific type of data block). Thus, it was copying 60 bytes of data from a 28 byte allocation.</p> <p>Fix that by using the source size instead, together with a build bug on the source size actually being smaller than the destination.</p> <p>I hit this running KUnit tests under KASAN (while debugging something else entirely). In the real world, it seems unlikely to cause an actual problem. It is a read not a write so it can&#39;t corrupt any memory. However, it could potentially fall off the end of a page and cause an accvio bug.</p> https://cve.radiocsirt.org/vuln/ghsa-4qvv-f8j2-942j https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-80749 <p><strong>Affected:</strong> 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</p> <p>In the Linux kernel, the following vulnerability has been resolved: drm/connector/hdmi: Fix out of bounds memory read A helper function was copying a given audio infoframe into the connector&#39;s copy but using the size of the destination (a generic target, sized to accept many different data blocks) not the source (a very specific type of data block). Thus, it was copying 60 bytes of data from a 28 byte allocation. Fix that by using the source size instead, together with a build bug on the source size actually being smaller than the destination. I hit this running KUnit tests under KASAN (while debugging something else entirely). In the real world, it seems unlikely to cause an actual problem. It is a read not a write so it can&#39;t corrupt any memory. However, it could potentially fall off the end of a page and cause an accvio bug.</p> <p><strong>Affected:</strong> 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</p> <p>In the Linux kernel, the following vulnerability has been resolved: drm/connector/hdmi: Fix out of bounds memory read A helper function was copying a given audio infoframe into the connector&#39;s copy but using the size of the destination (a generic target, sized to accept many different data blocks) not the source (a very specific type of data block). Thus, it was copying 60 bytes of data from a 28 byte allocation. Fix that by using the source size instead, together with a build bug on the source size actually being smaller than the destination. I hit this running KUnit tests under KASAN (while debugging something else entirely). In the real world, it seems unlikely to cause an actual problem. It is a read not a write so it can&#39;t corrupt any memory. However, it could potentially fall off the end of a page and cause an accvio bug.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-80749 https://cve.radiocsirt.org/vuln/wid-sec-w-2026-3152 <p>Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder nicht näher beschriebene Auswirkungen zu erzielen.</p> <p>Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder nicht näher beschriebene Auswirkungen zu erzielen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-3152