CVE-2023-32611

What it actually does

A crafted GVariant triggers excessive CPU processing during deserialization in GLib, resulting in denial of service via resource exhaustion.

Why it matters to the business

Applications built on GLib, including many desktop and system utilities, can become unresponsive or crash when processing untrusted input, disrupting user workflows and requiring restarts.

How an attack unfolds

An attacker creates a specially malformed GVariant structure and supplies it to a vulnerable GLib-based application through local file handling or input channels; the deserializer enters a prolonged computation loop, starving the system of CPU resources until the process is terminated or times out.

How to fix it

Upgrade gnome/glib (GIT) to the commit b5299ed2055aa3ccd628aceb016c1e9bda516e39 or later; rebuild and redeploy dependent applications after the update.

How to confirm the fix worked

Confirm the installed GLib version contains commit b5299ed2055aa3ccd628aceb016c1e9bda516e39; test deserialization of known-bad test cases to verify processing time remains bounded.

Typical attack path

1. Identify a GLib-based application that accepts external GVariant data
2. Craft a malicious GVariant payload designed to trigger the slowdown path
3. Deliver the payload via local file, command-line argument, or IPC mechanism
4. Trigger deserialization in the target process
5. Observe sustained high CPU usage leading to application or system degradation

How to detect it

Review process accounting and system logs for sustained high CPU usage by GLib-based binaries during file or data ingestion; correlate with application crash or restart events.

What your security team should do

• Prioritize patching GLib in all environments that process untrusted GVariant data
• Monitor for high-CPU processes associated with GLib deserialization routines
• Restrict untrusted file or input sources to affected applications until patched