CVE-2022-28656

What it actually does

A local user can invoke is_closing_session() to trigger unbounded memory allocations inside the Apport crash-reporting process, exhausting RAM and causing denial of service.

Why it matters to the business

Crash reporting becomes unavailable, complicating post-incident diagnostics on Ubuntu systems while high memory consumption may degrade overall host performance or trigger OOM kills of other services.

How an attack unfolds

A local attacker with a low-privileged account repeatedly calls the vulnerable function with crafted session data, causing the Apport daemon to allocate ever-increasing amounts of memory until the system is starved or the process is terminated.

How to fix it

Upgrade the apport package to the first patched release once published by Canonical; until then, apply systemd resource limits (MemoryMax) to the apport service and restrict local user access where feasible.

How to confirm the fix worked

Confirm the installed apport version contains the corrected is_closing_session() implementation; run memory-profiling tests that exercise session-closing paths and verify memory usage remains bounded.

Typical attack path

1. Obtain a local shell as a non-root user
2. Locate the running apport process
3. Invoke is_closing_session() in a tight loop or with large inputs
4. Observe progressive RAM consumption until service or host impact

How to detect it

Inspect system and apport logs for repeated session-closing activity; correlate with process accounting or cgroups memory metrics showing sustained high allocation by the apport daemon.

What your security team should do

• Prioritize patching apport once fixed packages are released
• Apply temporary MemoryMax limits via systemd to contain resource abuse
• Review local user permissions on systems running apport
• Monitor process memory metrics for anomalous growth