CVE-2022-28654

What it actually does

The is_closing_session() function permits authenticated local users to trigger repeated log writes that unboundedly grow apport.log until disk exhaustion occurs.

Why it matters to the business

Low-privilege users can exhaust disk space on GitLab servers, causing service outages, degraded performance, and unplanned operational recovery work; prevalence across many GitLab instances increases exposure.

How an attack unfolds

An authenticated local attacker repeatedly invokes is_closing_session() to force excessive logging entries into apport.log; over time the file consumes all available disk space and halts GitLab services. No public exploit code or threat actors are known.

How to fix it

Upgrade GitLab to the version containing commit 67af793e55bd098111d3c3e265cd2c92eb283f1c; limit log file sizes via OS-level logrotate or similar controls until patches are applied.

How to confirm the fix worked

Confirm the running GitLab binary or source tree includes commit 67af793e55bd098111d3c3e265cd2c92eb283f1c; attempt controlled invocation of is_closing_session() while monitoring apport.log size to verify no unbounded growth occurs.

Typical attack path

1. Obtain a low-privileged local account on a GitLab host
2. Repeatedly call is_closing_session() in a loop or script
3. Observe apport.log growth until disk space is exhausted and services fail

How to detect it

Search GitLab and system logs for unusually high volumes of entries containing is_closing_session references; monitor for rapid, sustained growth of apport.log outside normal crash-reporting patterns.

• apport.log
• is_closing_session()

What your security team should do

• Apply the fixed commit 67af793e55bd098111d3c3e265cd2c92eb283f1c to all GitLab instances without delay
• Enable or tighten log rotation for apport.log and other service logs
• Monitor disk utilization alerts on GitLab hosts and review local user activity for anomalous function calls