CVE-2026-53361

What it actually does

This is a race condition in the Linux kernel AF_UNIX garbage-collection path. Under specific timing, unix_gc() can execute while the global gc_in_progress state is false, which can interfere with MSG_PEEK handling in unix_peek_fpl(). That inconsistency can confuse AF_UNIX socket garbage collection and may lead to kernel instability, incorrect reference handling, or other memory-safety side effects. The most likely practical impact is local denial of service through a kernel crash or hang; privilege escalation cannot be ruled out without vendor-specific exploitability analysis, but no public exploit maturity is currently reported.

Why it matters to the business

Systems running affected Linux kernels may be vulnerable to local disruption by a user, workload, container, or compromised service that can create and manipulate Unix domain sockets. A successful attack could crash or destabilize hosts, causing service outages and requiring reboot or failover. The current risk signal is low because the issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, has very low EPSS, and has no known exploit maturity, but kernel flaws should still be prioritized in standard patch cycles because they affect foundational infrastructure.

How an attack unfolds

An attacker first needs local code execution on a Linux system, such as a shell account, compromised application process, or code running inside a container with access to AF_UNIX socket functionality. The attacker creates Unix domain sockets and manipulates file descriptor passing and receive operations to create pressure on AF_UNIX garbage collection. They then attempt to time multiple garbage-collection scheduling paths while also using MSG_PEEK behavior that depends on the gc_in_progress state being accurate. If the race is won, unix_gc() can run while gc_in_progress is false, causing AF_UNIX garbage collection to operate with incorrect state. Depending on kernel build, workload, and timing, the result may be a kernel warning, crash, hang, memory corruption, or potentially a more serious local kernel compromise. There is currently no indication of broad exploitation or named threat actor use.

How to fix it

Apply the Linux kernel update provided by the operating system or distribution vendor that includes the AF_UNIX fix setting gc_in_progress to true inside unix_gc(). Because no product-specific fixed versions were provided, use the relevant vendor advisory for the exact kernel package version. After updating, reboot into the fixed kernel unless a vendor-supported live patch explicitly covers this issue. Where immediate patching is not possible, reduce exposure by limiting untrusted local shell access, tightening container isolation, restricting the ability to run arbitrary local workloads, applying seccomp/AppArmor/SELinux profiles where feasible, and prioritizing patching on multi-tenant, container-hosting, CI/CD, developer workstation, and shared compute systems.

How to confirm the fix worked

Confirm the running kernel is a vendor-fixed build, not merely that the package is installed. On Linux systems, compare the running kernel version from uname -r and package metadata against the vendor advisory for this vulnerability, then verify the host has been rebooted or live-patched. Review kernel changelogs or source patches for the AF_UNIX change that sets gc_in_progress to true in unix_gc(). For fleet validation, inventory kernel versions across hosts and flag systems running older affected builds. Functional validation should focus on patch presence rather than attempting to reproduce the race, because reliable reproduction may require timing-sensitive stress conditions and could crash production systems.

Typical attack path

1. Gain local code execution on a Linux host or inside a workload/container that can create Unix domain sockets.
2. Create many AF_UNIX sockets and use file descriptor passing to build garbage-collection pressure.
3. Trigger concurrent or repeated unix_schedule_gc() activity so AF_UNIX garbage collection work is queued during an existing run.
4. Use socket receive operations involving MSG_PEEK to interact with code paths that rely on gc_in_progress being accurate.
5. Win the race so unix_gc() executes while gc_in_progress is false.
6. Cause kernel instability, denial of service, or potentially memory-safety side effects depending on the affected kernel and system conditions.

How to detect it

There are no reliable network indicators for this issue because exploitation is local and involves Unix domain socket behavior inside the kernel. To assess possible prior exploitation, review kernel logs, system journals, crash dumps, and monitoring alerts for unexplained kernel panics, oops reports, hangs, soft lockups, or reboots that include AF_UNIX, unix_gc(), unix_peek_fpl(), MSG_PEEK, garbage collection, or socket/file-descriptor-passing context. Correlate crash times with local user activity, container starts, CI jobs, suspicious short-lived processes, or workloads that create large numbers of Unix domain sockets. On systems with kdump or crash dump collection, inspect stack traces for AF_UNIX garbage-collection functions. Because ordinary crashes can produce similar symptoms and no known public exploit is reported, treat these artifacts as leads for investigation rather than definitive proof of exploitation.

• unix_gc
• unix_peek_fpl
• unix_schedule_gc
• gc_in_progress
• MSG_PEEK
• af_unix
• AF_UNIX
• BUG: kernel NULL pointer dereference
• kernel BUG at net/unix
• Oops:
• Kernel panic
• soft lockup
• hung task

What your security team should do

• Prioritize kernel updates for shared, multi-user, container-host, virtualization, CI/CD, and internet-facing workload platforms where local code execution by less-trusted users is more likely.
• Use vendor advisories to identify the exact fixed kernel packages for each distribution and confirm systems are rebooted into the fixed kernel after installation.
• Treat this as lower urgency than actively exploited KEV vulnerabilities, but include it in the next regular kernel maintenance window because it affects core kernel behavior.
• Harden local execution boundaries by minimizing interactive user access, constraining containers, and applying mandatory access controls and seccomp profiles where operationally feasible.
• Monitor for unexplained kernel oops, panics, soft lockups, or crashes with AF_UNIX/unix_gc stack traces, especially on systems running untrusted workloads.
• If suspicious crashes are observed, preserve kernel logs, crash dumps, workload metadata, and container/process execution history before rebooting or rebuilding affected systems.