An issue was discovered in GNOME GLib before 2.66.7 and 2.67.x before 2.67.4. If g_byte_array_new_take() was called with a buffer of 4GB or more on a 64-bit platform, the length would be truncated modulo 2**32, causing unintended length truncation. References: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1942 https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1944
Created glib tracking bugs for this issue: Affects: epel-7 [bug 1929851] Affects: fedora-all [bug 1929848] Created glib2 tracking bugs for this issue: Affects: fedora-all [bug 1929849] Created mingw-glib2 tracking bugs for this issue: Affects: fedora-all [bug 1929850]
This issue is about an integer truncation that occurs only when an application uses g_byte_array_new_take (or inderectly uses it, like with g_bytes_unref_to_array), provides a way for an attacker to provide both size and data and that could lead to at most an impact on the availability of the application/service. Moreover, if the application correctly uses the array->len field to determine the size of the GBytesArray, where array is the GBytesArray returned by g_byte_array_new_take/g_bytes_unref_to_array, no other direct security problem could happen because the stored length is less than what initially was. For these reason, this flaw got a Moderate Impact.
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2021:3058 https://access.redhat.com/errata/RHSA-2021:3058
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2021-27218
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2021:4526 https://access.redhat.com/errata/RHSA-2021:4526