CVE-2024-47809

What it actually does

Null pointer dereference in DLM request_lock path when lkb_resource has not yet been assigned via attach_lkb after validate_lock_args; also removes unsafe assumption that resource names are printable ASCII.

Why it matters to the business

Local denial-of-service risk on Linux systems using the DLM subsystem; low likelihood but could cause kernel instability if triggered by crafted local operations or future code changes.

How an attack unfolds

An attacker with local access crafts lock requests that reach the debug logging code before attach_lkb populates lkb_resource, causing a null dereference and potential kernel panic.

How to fix it

Upgrade the Linux kernel to the commit 6fbdc3980b70e9c1c86eccea7d5ee68108008fa7 or later stable releases containing the fix; disable DLM debug logging as a temporary mitigation if patching is delayed.

How to confirm the fix worked

Confirm the kernel source contains commit 6fbdc3980b70e9c1c86eccea7d5ee68108008fa7; verify that resource name printing has been removed from the debug log statement and that lkb id alone is used.

Typical attack path

1. Obtain local user access on an affected Linux kernel
2. Trigger DLM request_lock path with a newly created lkb that lacks an attached resource
3. Cause the vulnerable debug print path to execute, dereferencing the null lkb_resource pointer

How to detect it

Search kernel logs for DLM-related null pointer oops or panic messages referencing lkb or request_lock; enable and review DLM debug logs for unexpected lock requests if the subsystem is active.

What your security team should do

• Apply the kernel patch containing commit 6fbdc3980b70e9c1c86eccea7d5ee68108008fa7 as soon as possible
• Monitor for local privilege-escalation or DoS attempts targeting DLM subsystems
• Review and restrict local access to systems running DLM-enabled workloads