CVE-2024-26993

What it actually does

Reference leak in sysfs_break_active_protection() where a kobject reference acquired via kobject_get is never released when kernfs_find_and_get() fails and returns NULL, preventing the matching sysfs_unbreak_active_protection() call.

Why it matters to the business

Repeated triggering of the error path on affected Linux kernels can gradually exhaust kernel memory, leading to degraded performance or denial-of-service conditions on servers and devices that rely on sysfs operations.

How an attack unfolds

An attacker with local access crafts inputs that cause kernfs_find_and_get() to fail inside sysfs_break_active_protection(), forcing the function to return without releasing the previously acquired kobject reference; repeated execution leaks references until memory pressure impacts system stability. No public in-the-wild exploitation or ransomware use is associated with this issue.

How to fix it

Upgrade the Linux kernel to a version containing commit 84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d or later; rebuild and reboot into the patched kernel. Where immediate upgrade is not feasible, restrict untrusted local access and monitor memory usage.

How to confirm the fix worked

Verify the running kernel contains commit 84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d (or equivalent backport) via kernel version string or git log; confirm the explicit kobject_put() call exists in the error path of sysfs_break_active_protection().

Typical attack path

1. Obtain local code execution or shell access on a vulnerable Linux system
2. Trigger sysfs operations that invoke sysfs_break_active_protection() under conditions where kernfs_find_and_get() fails
3. Repeat the triggering sequence to accumulate unreleased kobject references
4. Observe gradual kernel memory exhaustion and resulting service degradation

How to detect it

Review kernel memory usage trends and slab allocator statistics for unexpected growth in kobject or sysfs-related caches; examine audit logs for repeated sysfs access patterns from untrusted processes around the time of memory pressure events.

What your security team should do

• Prioritize kernel upgrades on internet-facing and multi-tenant systems within standard change windows
• Apply the fix to all distributions that have released updated packages containing 84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d
• Review local access controls and limit unprivileged user namespaces where possible until patched
• Include kernel memory leak checks in routine performance monitoring