rpms/glib2
7
0
Fork 0
Code Issues Pull Requests Releases Activity

Backport patch to prevent sending a serial of zero on overflow

Browse Source 
A patch has been backported to fix an issue where GDBusConnection could send a
message with an invalid serial of zero after the serial counter overflowed.
This could happen in very long-running processes that use a single
GDBusConnection to send a large number of messages.

Upstream fix: b94b44407a.patch
Resolves: RHEL-114857

This commit was backported by Jotnar, a Red Hat Enterprise Linux software maintenance AI agent.

Assisted-by: Jotnar
This commit is contained in:
RHEL Packaging Agent 2025-09-16 07:13:27 +00:00 committed by Tomas Tomecek
parent 15f2cb8a8d
commit 1f6d149941
2 changed files with 73 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

70
RHEL-114857.patch Normal file
View File

@ -0,0 +1,70 @@
From b94b44407a088e6e8278d9db8b59fb377e84bda4 Mon Sep 17 00:00:00 2001
From: Philip Withnall <pwithnall@gnome.org>
Date: Mon, 3 Feb 2025 18:27:21 +0000
Subject: [PATCH] gdbusconnection: Prevent sending a serial of zero on overflow
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
It finally happened: someone managed to keep a process alive long
enough, and using a single `GDBusConnection`, to overflow the
`last_serial` counter in the connection and send an invalid message with
serial of zero (which is disallowed by the D-Bus specification).
Avoid that happening in future by skipping serials of zero on overflow,
and wrapping straight back around to 1.
This looks a little more confusing than it is, because `last_serial` is
pre-incremented on use, so to skip zero, we explicitly set it to zero.
This is exactly what happens when the `GDBusConnection` is initialised
anyway.
I can’t think of a way to add a unit test for this — there is no way to
affect the value of `last_serial` except by sending messages (each one
increments it), and in order to get it to overflow by sending messages
at 1kHz, the test would have to run for 49 days.
Instead, I tested this manually by temporarily modifying
`GDBusConnection` to initialise `last_serial` to `G_MAXUINT32 - 3`, then
checked that the unit tests all still passed, and that the overflow code
was being executed.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3592
---
gio/gdbusconnection.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/gio/gdbusconnection.c b/gio/gdbusconnection.c
index 1f6ca5745e..75371dca07 100644
--- a/gio/gdbusconnection.c
+++ b/gio/gdbusconnection.c
@@ -1763,9 +1763,22 @@ g_dbus_connection_send_message_unlocked (GDBusConnection *connection,
return FALSE;
if (flags & G_DBUS_SEND_MESSAGE_FLAGS_PRESERVE_SERIAL)
- serial_to_use = g_dbus_message_get_serial (message);
+ {
+ serial_to_use = g_dbus_message_get_serial (message);
+ }
else
- serial_to_use = ++connection->last_serial; /* TODO: handle overflow */
+ {
+ /* The serial_to_use must not be zero, as per
+ * https://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-messages. */
+ if (connection->last_serial == G_MAXUINT32)
+ connection->last_serial = 1;
+ else
+ connection->last_serial++;
+
+ serial_to_use = connection->last_serial;
+ }
+
+ g_assert (serial_to_use != 0);
switch (blob[0])
{
--
GitLab

3
glib2.spec
View File

@ -28,6 +28,9 @@ Patch: CVE-2024-52533.patch
# https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4592
Patch: CVE-2025-4373.patch
# https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4470
Patch: RHEL-114857.patch
BuildRequires: gcc
BuildRequires: gcc-c++
BuildRequires: gettext