public inbox for git-commits@fedoraproject.org
help / color / mirror / Atom feed
From: David King <amigadave@amigadave.com>
To: git-commits@fedoraproject.org
Subject: [rpms/glib2] cve-2026-58016-f44: Update to 2.83.2
Date: Tue, 11 Aug 2026 10:38:26 GMT	[thread overview]
Message-ID: <178644470646.1.8108446647276504989.rpms-glib2-328bb2142baf@fedoraproject.org> (raw)

A new commit has been pushed.

Repo   : rpms/glib2
Branch : cve-2026-58016-f44
Commit : 328bb2142baf0d035df4b8c08f1d12e2cf9fb03b
Author : David King <amigadave@amigadave.com>
Date   : 2024-12-12T09:20:46+00:00
Stats  : +2/-289 in 4 file(s)
URL    : https://src.fedoraproject.org/rpms/glib2/c/328bb2142baf0d035df4b8c08f1d12e2cf9fb03b?branch=cve-2026-58016-f44

Log:
Update to 2.83.2

---
diff --git a/0001-glib-gbytes-Be-more-careful-when-saving-a-GBytes-of-.patch b/0001-glib-gbytes-Be-more-careful-when-saving-a-GBytes-of-.patch
deleted file mode 100644
index 7de1417..0000000
--- a/0001-glib-gbytes-Be-more-careful-when-saving-a-GBytes-of-.patch
+++ /dev/null
@@ -1,46 +0,0 @@
-From 9ddc97314ba4313493f0979455a13838de1317ac Mon Sep 17 00:00:00 2001
-From: Richard Hughes <richard@hughsie.com>
-Date: Wed, 20 Nov 2024 13:28:25 +0000
-Subject: [PATCH] glib/gbytes: Be more careful when saving a GBytes of NULL
-
-In 1e3b010 the behaviour of `g_bytes_new (NULL, 0)` was changed; before the
-`g_bytes_get_data()` would return NULL as expected, but now it returns a pointer
-outside the single GBytes allocation.
-
-This breaks the fwupd self tests as we use a GBytes of NULL to signify that
-the emulation data exists, but it has no content.
-
-Catch this case and restore the old behaviour.
----
- glib/gbytes.c      | 2 +-
- glib/tests/bytes.c | 1 +
- 2 files changed, 2 insertions(+), 1 deletion(-)
-
-diff --git a/glib/gbytes.c b/glib/gbytes.c
-index 9b358c4a0..a3647caee 100644
---- a/glib/gbytes.c
-+++ b/glib/gbytes.c
-@@ -128,7 +128,7 @@ g_bytes_new (gconstpointer data,
-       GBytesInline *bytes;
- 
-       bytes = g_malloc (sizeof *bytes + size);
--      bytes->bytes.data = bytes->inline_data;
-+      bytes->bytes.data = data != NULL ? bytes->inline_data : NULL;
-       bytes->bytes.size = size;
-       bytes->bytes.free_func = NULL;
-       bytes->bytes.user_data = NULL;
-diff --git a/glib/tests/bytes.c b/glib/tests/bytes.c
-index 16a08e222..7d432fdee 100644
---- a/glib/tests/bytes.c
-+++ b/glib/tests/bytes.c
-@@ -451,6 +451,7 @@ test_null (void)
-   gsize size;
- 
-   bytes = g_bytes_new (NULL, 0);
-+  g_assert_null (g_bytes_get_data (bytes, NULL));
- 
-   data = g_bytes_unref_to_data (bytes, &size);
- 
--- 
-2.47.0
-

diff --git a/0001-gutf8-Drop-ifunc-code-and-always-call-strlen-when-va.patch b/0001-gutf8-Drop-ifunc-code-and-always-call-strlen-when-va.patch
deleted file mode 100644
index a2ad4b3..0000000
--- a/0001-gutf8-Drop-ifunc-code-and-always-call-strlen-when-va.patch
+++ /dev/null
@@ -1,235 +0,0 @@
-From 9a67e20d3cc1258ae10be7a2f9cf89ddd9aba025 Mon Sep 17 00:00:00 2001
-From: Philip Withnall <pwithnall@gnome.org>
-Date: Tue, 19 Nov 2024 13:49:34 +0000
-Subject: [PATCH] gutf8: Drop ifunc code and always call strlen() when
- validating UTF-8
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-This fixes a heap buffer overflow read in `g_utf8_validate()` and
-`g_str_is_ascii()`, at the cost of always calling `strlen()` on the
-input string if its length isn’t known already.
-
-The overflow read was not a security vulnerability, but getting valgrind
-and asan to understand that, across all platforms and build
-configurations, doesn’t seem to be possible with the resources available
-to us. In particular, the `ifunc` approach doesn’t work on muslc, and
-doesn’t work when statically linked.
-
-The UTF-8 validation code should still be faster than the old approach
-(GLib 2.82 and older), as `strlen()` is SIMD-accelerated in glibc, and
-UTF-8 validation is SIMD accelerated in GLib. The combination of the two
-should still be faster than the bytewise read loop we used to have.
-
-Unfortunately, correctness and testability have to be prioritised over
-absolute performance.
-
-Signed-off-by: Philip Withnall <pwithnall@gnome.org>
-
-Fixes: #3493
-Fixes: #3511
-Fixes: #3526
----
- glib/gutf8.c | 133 ++++-----------------------------------------------
- 1 file changed, 8 insertions(+), 125 deletions(-)
-
-diff --git a/glib/gutf8.c b/glib/gutf8.c
-index bca3358c2..95c683b5c 100644
---- a/glib/gutf8.c
-+++ b/glib/gutf8.c
-@@ -42,10 +42,6 @@
- #include "glibintl.h"
- #include "gvalgrind.h"
- 
--#if g_macro__has_attribute(ifunc) && !defined(G_OS_WIN32)
--#define HAVE_WORKING_IFUNC_ATTRIBUTE 1
--#endif
--
- #define UTF8_COMPUTE(Char, Mask, Len)					      \
-   if (Char < 128)							      \
-     {									      \
-@@ -1642,7 +1638,7 @@ utf8_verify_ascii (const char **strp,
-                    gsize       *lenp)
- {
-   const char *str = *strp;
--  gsize len = lenp ? *lenp : (gsize)-1;
-+  gsize len = lenp ? *lenp : strlen (str);
- 
-   while (len > 0 && load_u8 (str, 0) < 128)
-     {
-@@ -1691,7 +1687,7 @@ utf8_verify (const char **strp,
-              gsize       *lenp)
- {
-   const char *str = *strp;
--  gsize len = lenp ? *lenp : (gsize)-1;
-+  gsize len = lenp ? *lenp : strlen (str);
- 
-   /* See Unicode 10.0.0, Chapter 3, Section D92 */
- 
-@@ -1829,77 +1825,6 @@ out:
-     *lenp = len;
- }
- 
--static gboolean
--g_utf8_validate_native (const char  *str,
--                        gssize       max_len,
--                        const char **end)
--{
--  if (max_len >= 0)
--    return g_utf8_validate_len (str, max_len, end);
--
--  utf8_verify (&str, NULL);
--
--  if (end != NULL)
--    *end = str;
--
--  return *str == 0;
--}
--
--#ifdef HAVE_WORKING_IFUNC_ATTRIBUTE
--/* The fast implementation of UTF-8 validation in `utf8_verify()` technically
-- * uses undefined behaviour when the string length is not provided (i.e. when
-- * it’s looking for a trailing nul terminator): when doing word-sized reads of
-- * the string, it can read up to the word size (minus one byte) beyond the end
-- * of the string in order to find the nul terminator.
-- *
-- * While this is guaranteed to not cause a page fault (at worst, the nul
-- * terminator could be in the final word of the page, and the code won’t read
-- * any further than that), it is still technically undefined behaviour in C,
-- * because we’re reading off the end of an array.
-- *
-- * We don’t *think* this can cause any bugs due to compiler optimisations,
-- * because glibc does exactly the same thing in its string handling code, and
-- * that code has been extensively tested. For example:
-- * https://github.com/bminor/glibc/blob/2c1903cbbac0022153a67776f474c221250ad6ed/string/strchrnul.c
-- *
-- * However, both valgrind and asan warn about the read beyond the end of the
-- * array (a ‘heap buffer overflow read’). They’re right to do this (they can’t
-- * know the read is bounded to the word size minus one, and guaranteed to not
-- * cross a page boundary), but it’s annoying for any application which calls
-- * `g_utf8_validate()`.
-- *
-- * Use an [indirect function (`ifunc`)](https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-ifunc-function-attribute)
-- * to use a fallback implementation of `g_utf8_validate()` when running under
-- * valgrind. This is resolved at load time using `resolve_g_utf8_validate()`.
-- *
-- * Similarly, mark the real implementation so that it’s not instrumented by asan
-- * using `no_sanitize_address`.
-- */
--static gboolean
--g_utf8_validate_valgrind (const char  *str,
--                          gssize       max_len,
--                          const char **end)
--{
--  if (max_len < 0)
--    max_len = strlen (str);
--
--  return g_utf8_validate_len (str, max_len, end);
--}
--
--typedef gboolean (*GUtf8ValidateFunc) (const char  *str,
--                                       gssize       max_len,
--                                       const char **end);
--
--static GUtf8ValidateFunc
--resolve_g_utf8_validate (void)
--{
--  if (RUNNING_ON_VALGRIND)
--    return g_utf8_validate_valgrind;
--  else
--    return g_utf8_validate_native;
--}
--#endif  /* HAVE_WORKING_IFUNC_ATTRIBUTE */
--
- /**
-  * g_utf8_validate:
-  * @str: (array length=max_len) (element-type guint8): a pointer to character data
-@@ -1926,20 +1851,15 @@ resolve_g_utf8_validate (void)
-  * 
-  * Returns: `TRUE` if the text was valid UTF-8
-  */
--#if g_macro__has_attribute(no_sanitize_address)
--  __attribute__((no_sanitize_address))
--#endif
- gboolean
- g_utf8_validate (const char   *str,
-                  gssize        max_len,
-                  const gchar **end)
--#ifdef HAVE_WORKING_IFUNC_ATTRIBUTE
--  __attribute__((ifunc ("resolve_g_utf8_validate")));
--#else
- {
--  return g_utf8_validate_native (str, max_len, end);
-+  size_t max_len_unsigned = (max_len >= 0) ? (size_t) max_len : strlen (str);
-+
-+  return g_utf8_validate_len (str, max_len_unsigned, end);
- }
--#endif
- 
- /**
-  * g_utf8_validate_len:
-@@ -1969,38 +1889,6 @@ g_utf8_validate_len (const char   *str,
-   return max_len == 0;
- }
- 
--static gboolean
--g_str_is_ascii_native (const char *str)
--{
--  utf8_verify_ascii (&str, NULL);
--
--  return *str == 0;
--}
--
--#ifdef HAVE_WORKING_IFUNC_ATTRIBUTE
--/* See above comment about `ifunc` use for g_utf8_validate(). */
--static gboolean
--g_str_is_ascii_valgrind (const char *str)
--{
--  size_t len = strlen (str);
--
--  utf8_verify_ascii (&str, &len);
--
--  return *str == 0;
--}
--
--typedef gboolean (*GStrIsAsciiFunc) (const char *str);
--
--static GStrIsAsciiFunc
--resolve_g_str_is_ascii (void)
--{
--  if (RUNNING_ON_VALGRIND)
--    return g_str_is_ascii_valgrind;
--  else
--    return g_str_is_ascii_native;
--}
--#endif  /* HAVE_WORKING_IFUNC_ATTRIBUTE */
--
- /**
-  * g_str_is_ascii:
-  * @str: a string
-@@ -2012,18 +1900,13 @@ resolve_g_str_is_ascii (void)
-  *
-  * Since: 2.40
-  */
--#if g_macro__has_attribute(no_sanitize_address)
--  __attribute__((no_sanitize_address))
--#endif
- gboolean
- g_str_is_ascii (const gchar *str)
--#ifdef HAVE_WORKING_IFUNC_ATTRIBUTE
--  __attribute__((ifunc ("resolve_g_str_is_ascii")));
--#else
- {
--  return g_str_is_ascii_native (str);
-+  utf8_verify_ascii (&str, NULL);
-+
-+  return *str == 0;
- }
--#endif
- 
- /**
-  * g_unichar_validate:
--- 
-2.46.0
-

diff --git a/glib2.spec b/glib2.spec
index adf342c..cf1aad5 100644
--- a/glib2.spec
+++ b/glib2.spec
@@ -1,5 +1,5 @@
 Name:           glib2
-Version:        2.83.0
+Version:        2.83.2
 Release:        %autorelease
 Summary:        A library of handy utility functions
 
@@ -15,12 +15,6 @@ Patch:          gnutls-hmac.patch
 # https://bugzilla.redhat.com/show_bug.cgi?id=2192204
 Patch:          default-terminal.patch
 
-# https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4406
-Patch:          0001-glib-gbytes-Be-more-careful-when-saving-a-GBytes-of-.patch
-
-# https://gitlab.gnome.org/GNOME/glib/-/issues/3526
-Patch: 0001-gutf8-Drop-ifunc-code-and-always-call-strlen-when-va.patch
-
 BuildRequires:  gcc
 BuildRequires:  gcc-c++
 BuildRequires:  gettext

diff --git a/sources b/sources
index 76cd667..baed200 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (glib-2.83.0.tar.xz) = 293a164d93441e89303f65fda7ce1d212040e5ffbe526d121c2f0f352a9074235ae687430889b8a56d003e067931bf70ad69653cdafb0dcb64f6dfa683177375
+SHA512 (glib-2.83.2.tar.xz) = 1686ef719122d2b3e8bcc569ba1e125cde51fbe645811e1eb7ddd49e300ff834eed712bb619bba13629f23ad5f801fdc2d37e3103b5150ad3cb7ff9d1168d902

                 reply	other threads:[~2026-08-11 10:38 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=178644470646.1.8108446647276504989.rpms-glib2-328bb2142baf@fedoraproject.org \
    --to=amigadave@amigadave.com \
    --cc=git-commits@fedoraproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox