https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 00:51:51 +0000 https://cve.radiocsirt.org/vuln/bell-cve-2026-80702 <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-80702 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-361579 EUVD-2026-361579 https://cve.radiocsirt.org/vuln/euvd-2026-361579 https://cve.radiocsirt.org/vuln/fkie_cve-2026-80702 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>drm/vmwgfx: fix guest_memory_dirty bitfield clobbered as size</p> <p>Two sites in vmwgfx_resource.c assign boolean literals to res-&gt;guest_memory_size, which is an unsigned long allocation-size field; the intended target is the adjacent res-&gt;guest_memory_dirty bitfield. After the assignments the field holds 0 or 1 instead of the resource&#39;s MOB allocation size:</p> <p>- vmw_resource_release() writes 0 (false), and - vmw_resource_unbind_list() writes 1 (true).</p> <p>Subsequent revalidation paths read guest_memory_size when computing the dirty page range (vmw_bo_dirty_transfer_to_res()) and the buffer allocation size (vmw_resource_buf_alloc()), producing zero-length walks or wrap-around ranges that read or write past the MOB bitmap. The dirty-tracking intent of the original code (mark the resource as dirtied since the last sync) is also lost, since guest_memory_dirty is never updated.</p> <p>Rename both assignments to guest_memory_dirty.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>drm/vmwgfx: fix guest_memory_dirty bitfield clobbered as size</p> <p>Two sites in vmwgfx_resource.c assign boolean literals to res-&gt;guest_memory_size, which is an unsigned long allocation-size field; the intended target is the adjacent res-&gt;guest_memory_dirty bitfield. After the assignments the field holds 0 or 1 instead of the resource&#39;s MOB allocation size:</p> <p>- vmw_resource_release() writes 0 (false), and - vmw_resource_unbind_list() writes 1 (true).</p> <p>Subsequent revalidation paths read guest_memory_size when computing the dirty page range (vmw_bo_dirty_transfer_to_res()) and the buffer allocation size (vmw_resource_buf_alloc()), producing zero-length walks or wrap-around ranges that read or write past the MOB bitmap. The dirty-tracking intent of the original code (mark the resource as dirtied since the last sync) is also lost, since guest_memory_dirty is never updated.</p> <p>Rename both assignments to guest_memory_dirty.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-80702 https://cve.radiocsirt.org/vuln/ghsa-736r-87mh-h3gr <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>drm/vmwgfx: fix guest_memory_dirty bitfield clobbered as size</p> <p>Two sites in vmwgfx_resource.c assign boolean literals to res-&gt;guest_memory_size, which is an unsigned long allocation-size field; the intended target is the adjacent res-&gt;guest_memory_dirty bitfield. After the assignments the field holds 0 or 1 instead of the resource&#39;s MOB allocation size:</p> <p>- vmw_resource_release() writes 0 (false), and - vmw_resource_unbind_list() writes 1 (true).</p> <p>Subsequent revalidation paths read guest_memory_size when computing the dirty page range (vmw_bo_dirty_transfer_to_res()) and the buffer allocation size (vmw_resource_buf_alloc()), producing zero-length walks or wrap-around ranges that read or write past the MOB bitmap. The dirty-tracking intent of the original code (mark the resource as dirtied since the last sync) is also lost, since guest_memory_dirty is never updated.</p> <p>Rename both assignments to guest_memory_dirty.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>drm/vmwgfx: fix guest_memory_dirty bitfield clobbered as size</p> <p>Two sites in vmwgfx_resource.c assign boolean literals to res-&gt;guest_memory_size, which is an unsigned long allocation-size field; the intended target is the adjacent res-&gt;guest_memory_dirty bitfield. After the assignments the field holds 0 or 1 instead of the resource&#39;s MOB allocation size:</p> <p>- vmw_resource_release() writes 0 (false), and - vmw_resource_unbind_list() writes 1 (true).</p> <p>Subsequent revalidation paths read guest_memory_size when computing the dirty page range (vmw_bo_dirty_transfer_to_res()) and the buffer allocation size (vmw_resource_buf_alloc()), producing zero-length walks or wrap-around ranges that read or write past the MOB bitmap. The dirty-tracking intent of the original code (mark the resource as dirtied since the last sync) is also lost, since guest_memory_dirty is never updated.</p> <p>Rename both assignments to guest_memory_dirty.</p> https://cve.radiocsirt.org/vuln/ghsa-736r-87mh-h3gr https://cve.radiocsirt.org/vuln/msrc_cve-2026-80702 msrc_CVE-2026-80702 https://cve.radiocsirt.org/vuln/msrc_cve-2026-80702 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-80702 <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 154 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: fix guest_memory_dirty bitfield clobbered as size Two sites in vmwgfx_resource.c assign boolean literals to res-&gt;guest_memory_size, which is an unsigned long allocation-size field; the intended target is the adjacent res-&gt;guest_memory_dirty bitfield. After the assignments the field holds 0 or 1 instead of the resource&#39;s MOB allocation size: - vmw_resource_release() writes 0 (false), and - vmw_resource_unbind_list() writes 1 (true). Subsequent revalidation paths read guest_memory_size when computing the dirty page range (vmw_bo_dirty_transfer_to_res()) and the buffer allocation size (vmw_resource_buf_alloc()), producing zero-length walks or wrap-around ranges that read or write past the MOB bitmap. The dirty-tracking intent of the original code (mark the resource as dirtied since the last sync) is also lost, since guest_memory_dirty is never updated. Rename both assignments to guest_memory_dirty.</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 154 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: fix guest_memory_dirty bitfield clobbered as size Two sites in vmwgfx_resource.c assign boolean literals to res-&gt;guest_memory_size, which is an unsigned long allocation-size field; the intended target is the adjacent res-&gt;guest_memory_dirty bitfield. After the assignments the field holds 0 or 1 instead of the resource&#39;s MOB allocation size: - vmw_resource_release() writes 0 (false), and - vmw_resource_unbind_list() writes 1 (true). Subsequent revalidation paths read guest_memory_size when computing the dirty page range (vmw_bo_dirty_transfer_to_res()) and the buffer allocation size (vmw_resource_buf_alloc()), producing zero-length walks or wrap-around ranges that read or write past the MOB bitmap. The dirty-tracking intent of the original code (mark the resource as dirtied since the last sync) is also lost, since guest_memory_dirty is never updated. Rename both assignments to guest_memory_dirty.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-80702 https://cve.radiocsirt.org/vuln/wid-sec-w-2026-3075 <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, darunter möglicherweise Speicherbeschädigungen, die Offenlegung oder Manipulation von Daten sowie Denial-of-Service-Zustände.</p> <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, darunter möglicherweise Speicherbeschädigungen, die Offenlegung oder Manipulation von Daten sowie Denial-of-Service-Zustände.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-3075