[rpms/glib2] cve-2026-58016-f44: Handle EPERM to allow Fedora to be used on CircleCI and GitHub actions

[rpms/glib2] cve-2026-58016-f44: Handle EPERM to allow Fedora to be used on CircleCI and GitHub actions

[Richard Hughes]

            A new commit has been pushed.

            Repo   : rpms/glib2
            Branch : cve-2026-58016-f44
            Commit : 744bd637628f7018be83ee519b4253aac4f028d7
            Author : Richard Hughes <richard@hughsie.com>
            Date   : 2023-07-19T14:59:40+01:00
            Stats  : +47/-0 in 2 file(s)
            URL    : https://src.fedoraproject.org/rpms/glib2/c/744bd637628f7018be83ee519b4253aac4f028d7?branch=cve-2026-58016-f44

            Log:
            Handle EPERM to allow Fedora to be used on CircleCI and GitHub actions

It appears both CI systems are running docker with an old libseccomp
that doesn't have __SNR_close_range which the latest GLib hard-depends
on.

Relax the requirements a little until the two most popular CI systems
have deployed a new enough docker image.

---
diff --git a/glib2.spec b/glib2.spec
index 92bb607..2eacc2b 100644
--- a/glib2.spec
+++ b/glib2.spec
@@ -16,6 +16,10 @@ Patch0: gnutls-hmac.patch
 # https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3501
 Patch1: 0001-gmain-Add-a-missing-return-on-error-path-in-g_main_c.patch
 
+# recent close_range() changes break CircleCI and GitHub actions -- we can remove this when
+# the baremetal Docker is updated there i.e. lets be a little bit pragmatic...
+Patch2: gspawn-eperm.patch
+
 BuildRequires: gcc
 BuildRequires: gcc-c++
 BuildRequires: gettext

diff --git a/gspawn-eperm.patch b/gspawn-eperm.patch
new file mode 100644
index 0000000..f233bc9
--- /dev/null
+++ b/gspawn-eperm.patch
@@ -0,0 +1,43 @@
+diff --git a/glib/gspawn.c b/glib/gspawn.c
+index 67be6a6af..aaefd5b0d 100644
+--- a/glib/gspawn.c
++++ b/glib/gspawn.c
+@@ -1533,9 +1533,18 @@ safe_fdwalk_set_cloexec (int lowfd)
+    *
+    * Handle ENOSYS in case it’s supported in libc but not the kernel; if so,
+    * fall back to safe_fdwalk(). Handle EINVAL in case `CLOSE_RANGE_CLOEXEC`
+-   * is not supported. */
++   * is not supported.
++   *
++   * Also handle EPERM for the cases where GLib is running under broken versions
++   * of Docker+libseccomp which don’t recognise `close_range()` so block calls
++   * to it under a default security policy which returns EPERM rather than (the
++   * correct) ENOSYS. This workaround should be carried in distributions until
++   * they have versions of libseccomp and Docker which contain:
++   *  - https://salsa.debian.org/debian/libseccomp/-/blob/debian/bullseye/debian/patches/syscalls_add_close_range_syscall.patch
++   *  - https://github.com/opencontainers/runc/issues/2151
++   */
+   int ret = close_range (lowfd, G_MAXUINT, CLOSE_RANGE_CLOEXEC);
+-  if (ret == 0 || !(errno == ENOSYS || errno == EINVAL))
++  if (ret == 0 || !(errno == ENOSYS || errno == EINVAL || errno == EPERM))
+     return ret;
+ #endif  /* HAVE_CLOSE_RANGE */
+   return safe_fdwalk (set_cloexec, GINT_TO_POINTER (lowfd));
+@@ -1586,9 +1595,15 @@ safe_closefrom (int lowfd)
+    * situations: https://bugs.python.org/issue38061
+    *
+    * Handle ENOSYS in case it’s supported in libc but not the kernel; if so,
+-   * fall back to safe_fdwalk(). */
++   * fall back to safe_fdwalk().
++   *
++   * Also handle EPERM for the cases where GLib is running under broken versions
++   * of Docker+libseccomp which don’t recognise `close_range()` so block calls
++   * to it under a default security policy which returns EPERM rather than (the
++   * correct) ENOSYS.
++   */
+   int ret = close_range (lowfd, G_MAXUINT, 0);
+-  if (ret == 0 || errno != ENOSYS)
++  if (ret == 0 || !(errno == ENOSYS || errno == EPERM))
+     return ret;
+ #endif  /* HAVE_CLOSE_RANGE */
+   return safe_fdwalk (close_func, GINT_TO_POINTER (lowfd));