CVE-2026-64435

What it actually does

The flaw is a Linux kernel race condition in the audit subsystem. Multiple code paths read audit_queue.qlen with skb_queue_len() without holding the queue lock or using a lockless-safe read primitive, while kauditd concurrently updates the same queue length during skb_dequeue()/__skb_unlink(). This can cause inconsistent audit backlog decisions in kauditd_thread(), audit_receive_msg(), audit_receive(), and audit_log_start(). The practical technical consequences are incorrect audit queue length observations, audit backlog misreporting, possible audit record loss or mishandling, warning storms, and potential audit subsystem or system availability degradation under audit-event pressure. The upstream fix replaces unsafe readers with skb_queue_len_lockless(), which uses READ_ONCE() semantics compatible with the existing WRITE_ONCE() writer behavior.

Why it matters to the business

Systems that rely on Linux audit logs for compliance, incident response, forensic timelines, or security monitoring may lose or misreport audit events during high-concurrency conditions. In operational terms, this can reduce confidence in audit trails and, in worst cases, contribute to service instability or denial-of-service conditions if audit queues are stressed. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has low EPSS at publication time, but the high availability impact and kernel-level location make timely kernel updates important for Linux servers and appliances that use auditd heavily.

How an attack unfolds

An attacker attempts to create conditions where audit records are generated rapidly while the kernel audit daemon is simultaneously draining the audit queue. In a remote scenario, this usually requires interacting with an exposed service in a way that causes audited events, authentication failures, policy denials, crashes, core dumps, or other syscall activity covered by audit rules. While kauditd dequeues audit messages, other kernel paths read the queue length without proper synchronization. If the race is won repeatedly, the kernel can make incorrect backlog decisions, potentially dropping or delaying audit records, producing misleading audit status, or degrading availability through audit queue pressure. There is no public evidence in the provided data of weaponized exploitation, named threat actor use, or ransomware use; exploitation is more likely to appear as audit-flooding or reliability degradation than as a clean one-shot compromise.

How to fix it

Apply a vendor kernel update that includes the audit_queue skb_queue_len_lockless() fix for this issue. If building kernels directly, ensure all affected audit_queue readers have been changed from skb_queue_len(&audit_queue) to skb_queue_len_lockless(&audit_queue) where appropriate. Because no fixed package versions were provided in the input, use the relevant Linux distribution or appliance vendor advisory as the source of truth for the corrected kernel release. Where immediate patching is not possible, reduce audit-event flood risk by rate-limiting exposed services, limiting unnecessary externally reachable attack surface, reviewing overly broad audit rules, ensuring auditd/kauditd health monitoring is enabled, and tuning audit backlog settings according to vendor guidance. These mitigations reduce exploitability and impact but do not correct the kernel race.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor build containing the fix, not merely that the package is installed but pending reboot. Validate with uname -r, package-manager kernel version checks, and vendor advisory mapping. For source-based validation, inspect the kernel audit code and confirm the affected audit_queue length readers use skb_queue_len_lockless(). After rebooting into the fixed kernel, confirm auditd is running normally, auditctl -s reports expected backlog behavior, and kernel logs do not show recurring KCSAN data-race reports involving audit_log_start and skb_dequeue. In test environments, run audit-event stress workloads with KCSAN-enabled kernels and verify the prior race report is no longer reproducible.

Typical attack path

1. Identify a Linux system or network-facing service likely to generate audit events, such as authentication, access-control, syscall, crash, or policy-denial records.
2. Send a high rate of requests or inputs that cause audited activity, failures, denials, or process crashes.
3. Sustain concurrency so audit_log_start(), audit_receive(), audit status queries, and kauditd queue draining overlap.
4. Trigger the unsynchronized read/write race on audit_queue.qlen.
5. Cause incorrect audit backlog decisions, leading to dropped, delayed, or misreported audit records and possible audit subsystem instability.
6. Use degraded audit visibility or availability disruption to obscure other activity or impair monitoring and response.

How to detect it

Look for signs of audit subsystem stress, data-race diagnostics, or unexplained audit record loss. Relevant sources include kernel logs, system journal entries, auditd logs, audit status output, endpoint telemetry, and crash or watchdog records. Search for KCSAN reports naming audit_log_start and skb_dequeue, repeated audit backlog or lost-record messages, kauditd stalls, auditd restarts, and unusual bursts of events immediately before gaps in audit logs. If investigating possible exploitation, correlate spikes in externally sourced requests, authentication failures, policy denials, crashes, or core dumps with audit backlog growth, lost audit messages, or kernel warnings. Absence of these artifacts does not prove non-exploitation because the main impact can be audit loss or misreporting rather than a durable file or process artifact.

• BUG: KCSAN: data-race in audit_log_start / skb_dequeue
• KCSAN: data-race in audit_log_start
• skb_dequeue+0x
• kauditd_send_queue
• kauditd_thread
• audit_log_start
• audit_core_dumps
• audit: backlog limit exceeded
• audit: kauditd hold queue overflow
• audit_lost=
• lost=
• backlog=

What your security team should do

• Prioritize kernel updates on Linux systems where auditd is enabled, audit rules are extensive, or compliance and forensic logging are critical.
• Track distribution and appliance vendor advisories for the first fixed kernel version and schedule reboots into the corrected kernel.
• Monitor audit health signals, including audit backlog, lost audit records, kauditd activity, and kernel warnings, until patched.
• Review externally reachable services that can generate large volumes of audit events and apply rate limits or access controls where feasible.
• Do not treat mitigation tuning as a substitute for patching; the underlying issue is in kernel synchronization logic.
• Because this issue is not currently KEV-listed and has low EPSS, prioritize ahead of routine maintenance primarily for high-value, audit-dependent, or availability-sensitive Linux systems rather than as an emergency internet-wide exploitation event.