https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 21:14:34 +0000 https://cve.radiocsirt.org/vuln/bell-cve-2026-72046 <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-72046 https://cve.radiocsirt.org/vuln/certfr-2026-avi-1069 certfr-2026-avi-1069 https://cve.radiocsirt.org/vuln/certfr-2026-avi-1069 https://cve.radiocsirt.org/vuln/euvd-2026-353915 EUVD-2026-353915 https://cve.radiocsirt.org/vuln/euvd-2026-353915 https://cve.radiocsirt.org/vuln/fkie_cve-2026-72046 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>gve: fix header buffer corruption with header-split and HW-GRO</p> <p>The DQO RX datapath programs a per-buffer-queue-descriptor header_buf_addr at post time and reads the split header back at completion time. Both the post and the read currently index the header buffer by queue position rather than by the buffer&#39;s identity:</p> <p>- post (gve_rx_post_buffers_dqo): header_buf_addr is computed from bufq-&gt;tail - read (gve_rx_dqo): the header is read from desc_idx (the completion queue head index)</p> <p>This relies on the buffer-queue index and the completion-queue index being equal for the start of every packet, i.e. on the device consuming posted buffers and returning completions in the exact same order. That assumption does not hold once HW-GRO is enabled with multiple flows: coalesced segments are accepted and completed in an order that may differ from the order buffers were posted, and segments from different flows may interleave.</p> <p>That results in two problems:</p> <p>1. Wrong header slot on read. Because the read offset is derived from the completion index (desc_idx) while the device wrote the header to the address programmed for the buffer&#39;s buf_id, the driver can copy a header belonging to a different packet. This shows up as throughput drop (about 30% drop and large numbers of TCP retransmissions) with header-split and HW-GRO both enabled and many streams.</p> <p>2. Header buffer reused while still o…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>gve: fix header buffer corruption with header-split and HW-GRO</p> <p>The DQO RX datapath programs a per-buffer-queue-descriptor header_buf_addr at post time and reads the split header back at completion time. Both the post and the read currently index the header buffer by queue position rather than by the buffer&#39;s identity:</p> <p>- post (gve_rx_post_buffers_dqo): header_buf_addr is computed from bufq-&gt;tail - read (gve_rx_dqo): the header is read from desc_idx (the completion queue head index)</p> <p>This relies on the buffer-queue index and the completion-queue index being equal for the start of every packet, i.e. on the device consuming posted buffers and returning completions in the exact same order. That assumption does not hold once HW-GRO is enabled with multiple flows: coalesced segments are accepted and completed in an order that may differ from the order buffers were posted, and segments from different flows may interleave.</p> <p>That results in two problems:</p> <p>1. Wrong header slot on read. Because the read offset is derived from the completion index (desc_idx) while the device wrote the header to the address programmed for the buffer&#39;s buf_id, the driver can copy a header belonging to a different packet. This shows up as throughput drop (about 30% drop and large numbers of TCP retransmissions) with header-split and HW-GRO both enabled and many streams.</p> <p>2. Header buffer reused while still o…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-72046 https://cve.radiocsirt.org/vuln/ghsa-9vwj-6q4v-p5m2 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>gve: fix header buffer corruption with header-split and HW-GRO</p> <p>The DQO RX datapath programs a per-buffer-queue-descriptor header_buf_addr at post time and reads the split header back at completion time. Both the post and the read currently index the header buffer by queue position rather than by the buffer&#39;s identity:</p> <p>- post (gve_rx_post_buffers_dqo): header_buf_addr is computed from bufq-&gt;tail - read (gve_rx_dqo): the header is read from desc_idx (the completion queue head index)</p> <p>This relies on the buffer-queue index and the completion-queue index being equal for the start of every packet, i.e. on the device consuming posted buffers and returning completions in the exact same order. That assumption does not hold once HW-GRO is enabled with multiple flows: coalesced segments are accepted and completed in an order that may differ from the order buffers were posted, and segments from different flows may interleave.</p> <p>That results in two problems:</p> <p>1. Wrong header slot on read. Because the read offset is derived from the completion index (desc_idx) while the device wrote the header to the address programmed for the buffer&#39;s buf_id, the driver can copy a header belonging to a different packet. This shows up as throughput drop (about 30% drop and large numbers of TCP retransmissions) with header-split and HW-GRO both enabled and many streams.</p> <p>2. Header buffer reused while still o…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>gve: fix header buffer corruption with header-split and HW-GRO</p> <p>The DQO RX datapath programs a per-buffer-queue-descriptor header_buf_addr at post time and reads the split header back at completion time. Both the post and the read currently index the header buffer by queue position rather than by the buffer&#39;s identity:</p> <p>- post (gve_rx_post_buffers_dqo): header_buf_addr is computed from bufq-&gt;tail - read (gve_rx_dqo): the header is read from desc_idx (the completion queue head index)</p> <p>This relies on the buffer-queue index and the completion-queue index being equal for the start of every packet, i.e. on the device consuming posted buffers and returning completions in the exact same order. That assumption does not hold once HW-GRO is enabled with multiple flows: coalesced segments are accepted and completed in an order that may differ from the order buffers were posted, and segments from different flows may interleave.</p> <p>That results in two problems:</p> <p>1. Wrong header slot on read. Because the read offset is derived from the completion index (desc_idx) while the device wrote the header to the address programmed for the buffer&#39;s buf_id, the driver can copy a header belonging to a different packet. This shows up as throughput drop (about 30% drop and large numbers of TCP retransmissions) with header-split and HW-GRO both enabled and many streams.</p> <p>2. Header buffer reused while still o…</p> https://cve.radiocsirt.org/vuln/ghsa-9vwj-6q4v-p5m2 https://cve.radiocsirt.org/vuln/opensuse-su-2026:21910-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/opensuse-su-2026:21910-1 https://cve.radiocsirt.org/vuln/suse-su-2026:23881-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/suse-su-2026:23881-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-72046 <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 126 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: gve: fix header buffer corruption with header-split and HW-GRO The DQO RX datapath programs a per-buffer-queue-descriptor header_buf_addr at post time and reads the split header back at completion time. Both the post and the read currently index the header buffer by queue position rather than by the buffer&#39;s identity: - post (gve_rx_post_buffers_dqo): header_buf_addr is computed from bufq-&gt;tail - read (gve_rx_dqo): the header is read from desc_idx (the completion queue head index) This relies on the buffer-queue index and the completion-queue index being equal for the start of every packet, i.e. on the device consuming posted buffers and returning completions in the exact same order. That assumption does not hold once HW-GRO is enabled with multiple flows: coalesced segments are accepted and completed in an order that may differ from the order buffers were posted, and segments from different flows may interleave. That results in two problems: 1. Wrong header slot on read. Because the read offset is derived from the completion index (desc_idx) while the device wrote the header to the address programmed for the buffer&#39;s buf_id, the driver can copy a header belonging to a different packet. This shows up as throughput drop (about 30% drop and large numbers of TCP retransmissions) with header-split and HW-GRO both enabled and many streams. 2. Header buffer reused while still owned by…</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 126 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: gve: fix header buffer corruption with header-split and HW-GRO The DQO RX datapath programs a per-buffer-queue-descriptor header_buf_addr at post time and reads the split header back at completion time. Both the post and the read currently index the header buffer by queue position rather than by the buffer&#39;s identity: - post (gve_rx_post_buffers_dqo): header_buf_addr is computed from bufq-&gt;tail - read (gve_rx_dqo): the header is read from desc_idx (the completion queue head index) This relies on the buffer-queue index and the completion-queue index being equal for the start of every packet, i.e. on the device consuming posted buffers and returning completions in the exact same order. That assumption does not hold once HW-GRO is enabled with multiple flows: coalesced segments are accepted and completed in an order that may differ from the order buffers were posted, and segments from different flows may interleave. That results in two problems: 1. Wrong header slot on read. Because the read offset is derived from the completion index (desc_idx) while the device wrote the header to the address programmed for the buffer&#39;s buf_id, the driver can copy a header belonging to a different packet. This shows up as throughput drop (about 30% drop and large numbers of TCP retransmissions) with header-split and HW-GRO both enabled and many streams. 2. Header buffer reused while still owned by…</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-72046 https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2852 <p>Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um root Rechte zu erlangen, um einen Denial of Service herbeizuführen oder einen nicht näher spezifizierten Angriff durchzuführen.</p> <p>Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um root Rechte zu erlangen, um einen Denial of Service herbeizuführen oder einen nicht näher spezifizierten Angriff durchzuführen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2852