CVE-2024-26655

What it actually does

Memory leak in posix_clock_open() when clk ops.open() returns an error, without releasing the allocated pccontext, leading to gradual resource exhaustion in the kernel.

Why it matters to the business

Prolonged operation of affected systems can exhaust memory, causing service degradation, crashes, or denial of service for local processes and workloads running on Linux-based environments.

How an attack unfolds

An attacker with local access triggers repeated failures in clock open operations to accumulate leaked memory allocations until system resources are depleted, potentially leading to crashes or instability.

How to fix it

Update to a fixed kernel version that resolves the leak in posix_clock_open(); for Alpine v3.13 environments listed, apply the ghostscript package update to 9.51-r0 or later equivalent kernel fix.

How to confirm the fix worked

Confirm kernel source or package version includes the reorganized posix_clock_open() logic that releases pccontext on error; test by simulating open failures and monitoring for memory growth.

Typical attack path

1. Obtain local user access on an affected Linux system
2. Repeatedly invoke operations that call posix_clock_open() and cause the open callback to fail
3. Monitor memory consumption until exhaustion occurs
4. Trigger denial of service or system instability

How to detect it

Review kernel logs and memory usage metrics for patterns of repeated clock open failures without corresponding deallocations; look for increasing memory footprint in processes handling POSIX clocks.

What your security team should do

• Prioritize patching affected Linux kernels on all systems within standard maintenance windows
• Monitor memory usage on systems with clock-related workloads
• Review local access controls to reduce attack surface for memory exhaustion