CVE-2026-53334

What it actually does

This is a local denial-of-service flaw in the Linux kernel DAMON_RECLAIM feature. When DAMON_RECLAIM attempts to allocate a damon_ctx object and that allocation fails, the enable path can continue as if the context exists and pass a NULL pointer into damon_commit_ctx(), causing a kernel NULL-pointer dereference. The expected result is a kernel oops or panic, depending on kernel configuration, panic-on-oops settings, and workload state. The vulnerability does not provide confidentiality or integrity impact by itself; the primary impact is loss of system availability.

Why it matters to the business

A local user or process with sufficient access to the affected kernel interface could crash a Linux system, causing service interruption, workload failure, node eviction in clustered environments, or availability loss for applications running on the host. Exploitation is less likely than many remote vulnerabilities because it requires local access and a low-memory allocation-failure condition, EPSS is very low, and it is not listed in CISA KEV; however, systems that expose DAMON_RECLAIM controls to untrusted users or run with panic-on-oops enabled have a higher operational risk.

How an attack unfolds

An attacker first obtains local execution on a Linux system where the affected DAMON_RECLAIM kernel code is present and usable. They then interact with the DAMON_RECLAIM enable path, typically through the kernel parameter/sysfs control used to enable reclaim behavior. To make the vulnerable condition reachable, the attacker attempts to create memory pressure or otherwise cause the small damon_ctx allocation to fail. If allocation fails, the vulnerable kernel path continues and calls into DAMON context commit logic with a NULL context pointer. This triggers a NULL-pointer dereference in kernel mode, resulting in an oops or kernel panic and denying service to workloads on the affected host.

How to fix it

Apply the Linux kernel update that includes the upstream fix for DAMON_RECLAIM allocation-failure handling. Because no exact fixed package versions were provided, use the fixed kernel builds supplied by the relevant Linux distribution, appliance vendor, cloud image provider, or kernel maintainer. Prioritize systems where local users, containers, batch workloads, or untrusted code can interact with kernel tunables. If immediate patching is not possible, reduce exposure by disabling or avoiding DAMON_RECLAIM where feasible, restricting write access to DAMON_RECLAIM sysfs/module parameters, limiting untrusted local shell access, enforcing least privilege, and reviewing panic-on-oops settings to reduce full-system outage risk where operationally acceptable.

How to confirm the fix worked

Confirm the running kernel version includes the vendor backport or upstream patch for DAMON_RECLAIM NULL ctx handling. Validate that DAMON_RECLAIM controls are not writable by untrusted users, for example by checking permissions on /sys/module/damon_reclaim/parameters/enabled when present. Review kernel configuration and loaded modules to determine whether DAMON_RECLAIM is available. After remediation, attempts to enable DAMON_RECLAIM under allocation-failure conditions should return an allocation error such as -ENOMEM rather than producing a kernel oops or panic. Also confirm that no recent kernel logs show NULL-pointer dereferences involving damon_reclaim_enabled_store(), damon_commit_ctx(), or DAMON/kdamond paths.

Typical attack path

1. Gain local code execution or shell access on an affected Linux system.
2. Confirm that DAMON_RECLAIM support is present and the relevant control interface is accessible.
3. Create or wait for memory pressure sufficient to make the damon_ctx allocation fail.
4. Write to the DAMON_RECLAIM enable control to trigger damon_reclaim_enabled_store().
5. Cause execution to reach damon_commit_ctx() with a NULL ctx pointer.
6. Crash the kernel or trigger a kernel oops, resulting in system or workload downtime.

How to detect it

To determine whether this was already exploited, review kernel and system logs for oops, panic, or NULL-pointer dereference events referencing DAMON_RECLAIM, damon_reclaim_enabled_store(), damon_commit_ctx(), damon_ctx, or kdamond. Relevant log sources include dmesg output, journald kernel logs, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dump metadata, kdump/vmcore analysis, and EDR telemetry that records kernel panics or reboot reasons. If auditd or equivalent telemetry is enabled, search for writes to the DAMON_RECLAIM enable parameter, especially near memory-exhaustion events, unexpected reboots, or service outages. Correlate suspected events with local user sessions, privilege changes, container activity, stress-testing tools, memory allocation failures, and abnormal process behavior immediately before the crash. There are no known public exploit-specific network indicators for this local kernel denial-of-service issue; detection should focus on kernel crash artifacts and local sysfs/module-parameter access.

• BUG: kernel NULL pointer dereference
• Oops: 0000
• Kernel panic - not syncing
• damon_commit_ctx
• damon_reclaim_enabled_store
• damon_ctx
• kdamond
• damon_reclaim
• DAMON_RECLAIM
• /sys/module/damon_reclaim/parameters/enabled
• Out of memory
• page allocation failure

What your security team should do

• Patch affected Linux kernels using vendor-supported fixed releases or backports as the primary remediation.
• Inventory systems with DAMON_RECLAIM enabled or available, especially multi-user systems, container hosts, CI runners, research systems, and shared compute platforms.
• Restrict write access to DAMON_RECLAIM sysfs/module parameters to trusted administrators only.
• Monitor kernel logs for NULL-pointer dereferences and stack traces involving DAMON_RECLAIM, damon_commit_ctx(), or kdamond.
• Review panic-on-oops and crash-kernel settings on critical systems to balance forensic capture with availability requirements.
• Treat suspicious local attempts to induce memory pressure and toggle DAMON_RECLAIM as potential denial-of-service activity.
• Because EPSS is low and there is no KEV listing or known exploit maturity, prioritize based on local-user exposure and business criticality rather than emergency internet-facing response.