https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 02:38:40 +0000 https://cve.radiocsirt.org/vuln/bdu:2025-12471 bdu:2025-12471 https://cve.radiocsirt.org/vuln/bdu:2025-12471 https://cve.radiocsirt.org/vuln/bell-cve-2025-6052 <p><strong>Affected:</strong> Alpaquita:25: glib, Alpaquita:stream: glib</p> <p><strong>Affected:</strong> Alpaquita:25: glib, Alpaquita:stream: glib</p> https://cve.radiocsirt.org/vuln/bell-cve-2025-6052 https://cve.radiocsirt.org/vuln/bit-java-2025-6052 <p><strong>Affected:</strong> Bitnami: java</p> <p>A flaw was found in how GLib’s GString manages memory when adding data to strings. If a string is already very large, combining it with more input can cause a hidden overflow in the size calculation. This makes the system think it has enough memory when it doesn’t. As a result, data may be written past the end of the allocated memory, leading to crashes or memory corruption.</p> <p><strong>Affected:</strong> Bitnami: java</p> <p>A flaw was found in how GLib’s GString manages memory when adding data to strings. If a string is already very large, combining it with more input can cause a hidden overflow in the size calculation. This makes the system think it has enough memory when it doesn’t. As a result, data may be written past the end of the allocated memory, leading to crashes or memory corruption.</p> https://cve.radiocsirt.org/vuln/bit-java-2025-6052 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0969 certfr-2025-avi-0969 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0969 https://cve.radiocsirt.org/vuln/euvd-2026-323835 EUVD-2026-323835 https://cve.radiocsirt.org/vuln/euvd-2026-323835 https://cve.radiocsirt.org/vuln/fkie_cve-2025-6052 <p>A flaw was found in how GLib’s GString manages memory when adding data to strings. If a string is already very large, combining it with more input can cause a hidden overflow in the size calculation. This makes the system think it has enough memory when it doesn’t. As a result, data may be written past the end of the allocated memory, leading to crashes or memory corruption.</p> <p>A flaw was found in how GLib’s GString manages memory when adding data to strings. If a string is already very large, combining it with more input can cause a hidden overflow in the size calculation. This makes the system think it has enough memory when it doesn’t. As a result, data may be written past the end of the allocated memory, leading to crashes or memory corruption.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2025-6052 https://cve.radiocsirt.org/vuln/ghsa-99rj-3595-5frj <p>A flaw was found in how GLib’s GString manages memory when adding data to strings. If a string is already very large, combining it with more input can cause a hidden overflow in the size calculation. This makes the system think it has enough memory when it doesn’t. As a result, data may be written past the end of the allocated memory, leading to crashes or memory corruption.</p> <p>A flaw was found in how GLib’s GString manages memory when adding data to strings. If a string is already very large, combining it with more input can cause a hidden overflow in the size calculation. This makes the system think it has enough memory when it doesn’t. As a result, data may be written past the end of the allocated memory, leading to crashes or memory corruption.</p> https://cve.radiocsirt.org/vuln/ghsa-99rj-3595-5frj https://cve.radiocsirt.org/vuln/icsa-26-134-10 <p>In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check link_res-&gt;hpo_dp_link_enc before using it [WHAT &amp; HOW] Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res without initializing hpo_dp_link_enc and it is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity. In the Linux kernel, the following vulnerability has been resolved:</p> <p>fs: relax assertions on failure to encode file handles</p> <p>Encoding file handles is usually performed by a filesystem &gt;encode_fh() method that may fail for various reasons.</p> <p>The legacy users of exportfs_encode_fh(), namely, nfsd and name_to_handle_at(2) syscall are ready to cope with the possibility of failure to encode a file handle.</p> <p>There are a few other users of exportfs_encode_{fh,fid}() that currently have a WARN_ON() assertion when -&gt;encode_fh() fails. Relax those assertions because they are wrong.</p> <p>The second linked bug report states commit 16aac5ad1fa9 (&#34;ovl: support encoding non-decodable file handles&#34;) in v6.6 as the regressing commit, but this is not accurate.</p> <p>The aforementioned commit only increases the chances of the assertion and allows triggering the assertion with the reproducer using overlayfs, inotify and drop_caches.</p> <p>Triggering this assertion was always possible with other filesystems and other reasons of -&gt;encode_fh() failures and more particularly, it was also possible with the exact same reproducer using overlay…</p> <p>In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check link_res-&gt;hpo_dp_link_enc before using it [WHAT &amp; HOW] Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res without initializing hpo_dp_link_enc and it is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity. In the Linux kernel, the following vulnerability has been resolved:</p> <p>fs: relax assertions on failure to encode file handles</p> <p>Encoding file handles is usually performed by a filesystem &gt;encode_fh() method that may fail for various reasons.</p> <p>The legacy users of exportfs_encode_fh(), namely, nfsd and name_to_handle_at(2) syscall are ready to cope with the possibility of failure to encode a file handle.</p> <p>There are a few other users of exportfs_encode_{fh,fid}() that currently have a WARN_ON() assertion when -&gt;encode_fh() fails. Relax those assertions because they are wrong.</p> <p>The second linked bug report states commit 16aac5ad1fa9 (&#34;ovl: support encoding non-decodable file handles&#34;) in v6.6 as the regressing commit, but this is not accurate.</p> <p>The aforementioned commit only increases the chances of the assertion and allows triggering the assertion with the reproducer using overlayfs, inotify and drop_caches.</p> <p>Triggering this assertion was always possible with other filesystems and other reasons of -&gt;encode_fh() failures and more particularly, it was also possible with the exact same reproducer using overlay…</p> https://cve.radiocsirt.org/vuln/icsa-26-134-10 https://cve.radiocsirt.org/vuln/msrc_cve-2025-6052 msrc_CVE-2025-6052 https://cve.radiocsirt.org/vuln/msrc_cve-2025-6052 https://cve.radiocsirt.org/vuln/ncsc-2026-0030 NCSC-2026-0030 https://cve.radiocsirt.org/vuln/ncsc-2026-0030 https://cve.radiocsirt.org/vuln/oesa-2025-1795 <p><strong>Affected:</strong> openEuler:24.03-LTS: glib2</p> <p>GLib is a bundle of three (formerly five) low-level system libraries written in C and developed mainly by GNOME. GLib&amp;amp;apos;s code was separated from GTK, so it can be used by software other than GNOME and has been developed in parallel ever since. Security Fix(es):</p> <p>A flaw was found in how GLib’s GString manages memory when adding data to strings. If a string is already very large, combining it with more input can cause a hidden overflow in the size calculation. This makes the system think it has enough memory when it doesn’t. As a result, data may be written past the end of the allocated memory, leading to crashes or memory corruption.(CVE-2025-6052)</p> <p><strong>Affected:</strong> openEuler:24.03-LTS: glib2</p> <p>GLib is a bundle of three (formerly five) low-level system libraries written in C and developed mainly by GNOME. GLib&amp;amp;apos;s code was separated from GTK, so it can be used by software other than GNOME and has been developed in parallel ever since. Security Fix(es):</p> <p>A flaw was found in how GLib’s GString manages memory when adding data to strings. If a string is already very large, combining it with more input can cause a hidden overflow in the size calculation. This makes the system think it has enough memory when it doesn’t. As a result, data may be written past the end of the allocated memory, leading to crashes or memory corruption.(CVE-2025-6052)</p> https://cve.radiocsirt.org/vuln/oesa-2025-1795 https://cve.radiocsirt.org/vuln/opensuse-su-2025:15221-1 <p>gio-branding-upstream-2.84.3-1.1 on GA media</p> <p>gio-branding-upstream-2.84.3-1.1 on GA media</p> https://cve.radiocsirt.org/vuln/opensuse-su-2025:15221-1 https://cve.radiocsirt.org/vuln/ssa-032379 <p>In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check link_res-&gt;hpo_dp_link_enc before using it [WHAT &amp; HOW] Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res without initializing hpo_dp_link_enc and it is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity. In the Linux kernel, the following vulnerability has been resolved:</p> <p>fs: relax assertions on failure to encode file handles</p> <p>Encoding file handles is usually performed by a filesystem &gt;encode_fh() method that may fail for various reasons.</p> <p>The legacy users of exportfs_encode_fh(), namely, nfsd and name_to_handle_at(2) syscall are ready to cope with the possibility of failure to encode a file handle.</p> <p>There are a few other users of exportfs_encode_{fh,fid}() that currently have a WARN_ON() assertion when -&gt;encode_fh() fails. Relax those assertions because they are wrong.</p> <p>The second linked bug report states commit 16aac5ad1fa9 (&#34;ovl: support encoding non-decodable file handles&#34;) in v6.6 as the regressing commit, but this is not accurate.</p> <p>The aforementioned commit only increases the chances of the assertion and allows triggering the assertion with the reproducer using overlayfs, inotify and drop_caches.</p> <p>Triggering this assertion was always possible with other filesystems and other reasons of -&gt;encode_fh() failures and more particularly, it was also possible with the exact same reproducer using overlay…</p> <p>In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check link_res-&gt;hpo_dp_link_enc before using it [WHAT &amp; HOW] Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res without initializing hpo_dp_link_enc and it is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity. In the Linux kernel, the following vulnerability has been resolved:</p> <p>fs: relax assertions on failure to encode file handles</p> <p>Encoding file handles is usually performed by a filesystem &gt;encode_fh() method that may fail for various reasons.</p> <p>The legacy users of exportfs_encode_fh(), namely, nfsd and name_to_handle_at(2) syscall are ready to cope with the possibility of failure to encode a file handle.</p> <p>There are a few other users of exportfs_encode_{fh,fid}() that currently have a WARN_ON() assertion when -&gt;encode_fh() fails. Relax those assertions because they are wrong.</p> <p>The second linked bug report states commit 16aac5ad1fa9 (&#34;ovl: support encoding non-decodable file handles&#34;) in v6.6 as the regressing commit, but this is not accurate.</p> <p>The aforementioned commit only increases the chances of the assertion and allows triggering the assertion with the reproducer using overlayfs, inotify and drop_caches.</p> <p>Triggering this assertion was always possible with other filesystems and other reasons of -&gt;encode_fh() failures and more particularly, it was also possible with the exact same reproducer using overlay…</p> https://cve.radiocsirt.org/vuln/ssa-032379 https://cve.radiocsirt.org/vuln/suse-su-2025:20508-1 <p>Security update for glib2</p> <p>Security update for glib2</p> https://cve.radiocsirt.org/vuln/suse-su-2025:20508-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-6052 <p><strong>Affected:</strong> Ubuntu:24.04:LTS: glib2.0</p> <p>A flaw was found in how GLib’s GString manages memory when adding data to strings. If a string is already very large, combining it with more input can cause a hidden overflow in the size calculation. This makes the system think it has enough memory when it doesn’t. As a result, data may be written past the end of the allocated memory, leading to crashes or memory corruption.</p> <p><strong>Affected:</strong> Ubuntu:24.04:LTS: glib2.0</p> <p>A flaw was found in how GLib’s GString manages memory when adding data to strings. If a string is already very large, combining it with more input can cause a hidden overflow in the size calculation. This makes the system think it has enough memory when it doesn’t. As a result, data may be written past the end of the allocated memory, leading to crashes or memory corruption.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-6052 https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0164 <p>Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in Oracle Java SE ausnutzen, um die Vertraulichkeit, Integrität und Verfügbarkeit zu gefährden.</p> <p>Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in Oracle Java SE ausnutzen, um die Vertraulichkeit, Integrität und Verfügbarkeit zu gefährden.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0164