CVE-2024-41012 Overview
CVE-2024-41012 is a use-after-free vulnerability [CWE-416] in the Linux kernel's POSIX file locking subsystem. The flaw resides in fcntl_setlk(), where a race between fcntl() and close() can leave a stale lock attached to a freed file structure. Linux Security Modules (LSMs) may permit the first do_lock_file_wait() call that creates the lock while denying the subsequent call that attempts to remove it. A GFP_KERNEL allocation failure in posix_lock_file() during range splitting can produce the same outcome. After the race triggers, reading /proc/locks causes use-after-free reads inside lock_get_status().
Critical Impact
Local low-privileged users can trigger use-after-free reads in kernel memory by reading /proc/locks, enabling potential disclosure of arbitrary kernel memory contents.
Affected Products
- Linux Kernel versions prior to the fixed stable releases
- Linux Kernel 6.10 release candidates (rc1 through rc6)
- Debian distributions covered by the Debian LTS security advisory
Discovery Timeline
- 2024-07-23 - CVE-2024-41012 published to NVD
- 2025-11-03 - Last updated in NVD database
Technical Details for CVE-2024-41012
Vulnerability Analysis
The vulnerability lives in the kernel's filelock subsystem, which manages POSIX advisory locks on open files. When fcntl_setlk() detects that the file descriptor has been closed concurrently by another thread, it attempts to unwind by calling do_lock_file_wait() a second time to remove the lock it just installed. This unwind path is not guaranteed to succeed. An LSM such as SELinux or AppArmor may approve the lock creation but reject the lock removal, leaving the lock attached to a file structure that is about to be freed. Separately, posix_lock_file() can fail with -ENOMEM when it must split an existing lock range and the GFP_KERNEL allocation fails.
Root Cause
The root cause is an asymmetric error-handling assumption: the unwind code assumes lock removal cannot fail, but both LSM hooks and memory allocator failures can cause it to fail. The stale lock then references freed memory once the file's files_struct is torn down.
Attack Vector
An attacker requires local code execution with the ability to call fcntl() and close() on a file descriptor and to read /proc/locks. By racing fcntl(F_SETLK) against close() under an LSM policy that denies lock removal, the attacker plants a dangling lock. Subsequent reads of /proc/locks invoke lock_get_status() on freed memory, returning arbitrary kernel data to userspace. The fix replaces the second do_lock_file_wait() with locks_remove_posix(), which is the same routine used by filp_flush() and is designed to reliably clear POSIX locks for a given file and files_struct.
Detection Methods for CVE-2024-41012
Indicators of Compromise
- Unprivileged processes performing high-frequency fcntl(F_SETLK) calls interleaved with close() on the same file descriptor
- Repeated reads of /proc/locks by non-administrative processes
- Kernel warnings or KASAN reports referencing lock_get_status or posix_lock_file
Detection Strategies
- Audit kernel logs (dmesg, journalctl -k) for use-after-free splats, KASAN reports, or BUG: messages originating in fs/locks.c
- Monitor auditd for syscall=fcntl events correlated with close from the same process under tight time windows
- Inventory running kernel versions against the patched stable releases listed in the kernel.org commits
Monitoring Recommendations
- Enable auditd rules covering fcntl, close, and reads of /proc/locks for non-root users
- Forward kernel ring buffer logs to a centralized SIEM or data lake for retrospective analysis
- Track process behavior anomalies such as sustained syscall storms targeting file locking primitives
How to Mitigate CVE-2024-41012
Immediate Actions Required
- Apply the upstream stable kernel updates that incorporate the fix replacing do_lock_file_wait() with locks_remove_posix() in the fcntl_setlk() unwind path
- For Debian systems, install the kernel package referenced in the Debian LTS Announcement
- Reboot affected systems after patching so the new kernel image is active
Patch Information
The upstream fix is distributed across multiple stable branches. Refer to the corresponding kernel.org commits for each branch: Kernel Git Commit 3cad1bc, Kernel Git Commit 52c87ab, Kernel Git Commit 5661b9, Kernel Git Commit 5f5d07, Kernel Git Commit b6d223, Kernel Git Commit d30ff3, Kernel Git Commit dc2ce1d, and Kernel Git Commit ef8fc41.
Workarounds
- Restrict read access to /proc/locks for unprivileged users where operational requirements permit
- Reduce attack surface by limiting local shell access to untrusted users on multi-tenant systems
- Where patching is delayed, audit and tighten LSM policies that asymmetrically permit lock creation but deny lock removal
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


