CVE-2024-41012: Linux Kernel Use-After-Free Vulnerability

CVE-2024-41012 Overview

CVE-2024-41012 is a Use-After-Free vulnerability in the Linux kernel's filelock subsystem that occurs when the fcntl_setlk() function races with close(). When this race condition is triggered, the kernel attempts to remove a lock using do_lock_file_wait(), but this operation can fail under specific circumstances—either when Linux Security Modules (LSMs) deny the lock removal operation or when posix_lock_file() fails due to GFP_KERNEL memory allocation failure during range splitting operations.

The consequence of this vulnerability is that dangling references to freed lock structures remain accessible. When userspace subsequently reads /proc/locks, the lock_get_status() function performs use-after-free reads on these stale references, potentially allowing an attacker to read arbitrary kernel memory.

Critical Impact

This vulnerability enables use-after-free reads in the Linux kernel, potentially allowing local attackers to read arbitrary kernel memory through /proc/locks, leading to information disclosure of sensitive kernel data.

Affected Products

• Linux Kernel (multiple versions)
• Linux Kernel 6.10-rc1 through 6.10-rc6
• Various Linux distributions including Debian

Discovery Timeline

• July 23, 2024 - CVE-2024-41012 published to NVD
• November 3, 2025 - Last updated in NVD database

Technical Details for CVE-2024-41012

Vulnerability Analysis

This vulnerability resides in the kernel's POSIX file locking implementation. The race condition occurs in the interaction between fcntl_setlk() and close() system calls. Under normal operation, when a file descriptor is closed while a lock acquisition is in progress, the kernel should cleanly remove any locks that were created. However, the original implementation used do_lock_file_wait() for this cleanup operation, which can fail in two scenarios:

1. LSM Policy Denial: Linux Security Modules may permit the initial lock creation but deny the subsequent lock removal operation, creating an inconsistent state where the lock object exists but cannot be properly cleaned up.

2. Memory Allocation Failure: When posix_lock_file() attempts to remove a lock that requires splitting a range in the middle, it needs to allocate memory using GFP_KERNEL. If this allocation fails, the lock removal fails silently, leaving a dangling lock structure.

After the race condition triggers, the affected lock structure becomes invalid but remains referenced in kernel data structures. The lock_get_status() function, which populates /proc/locks for userspace consumption, will read from these freed memory regions—a classic use-after-free condition.

Root Cause

The root cause is the use of do_lock_file_wait() for lock cleanup during the fcntl/close race condition. This function was not designed to reliably remove locks and can fail silently under LSM restrictions or memory pressure. The proper solution is to use locks_remove_posix() instead, which is specifically designed to reliably remove all POSIX locks associated with a given file and files_struct, and is already used by filp_flush() for this exact purpose.

Attack Vector

This is a local attack vector requiring authenticated access to the system. An attacker with local access can exploit this vulnerability by:

1. Opening a file and initiating a POSIX lock operation via fcntl()
2. Racing a close() call against the lock operation
3. Triggering conditions that cause the lock removal to fail (either through LSM policy manipulation or memory pressure)
4. Reading /proc/locks to trigger use-after-free reads and potentially extract sensitive kernel memory contents

The vulnerability primarily enables information disclosure—attackers can read arbitrary kernel memory but cannot corrupt kernel memory through this specific flaw. However, leaked kernel addresses or sensitive data could facilitate further exploitation of other vulnerabilities.

Detection Methods for CVE-2024-41012

Indicators of Compromise

• Unusual patterns of rapid fcntl() and close() system calls on the same file descriptors
• Repeated access to /proc/locks by non-administrative processes
• Kernel warnings or oops messages related to filelock operations or use-after-free detection
• Anomalous memory access patterns detected by kernel memory sanitizers (KASAN)

Detection Strategies

• Enable Kernel Address Sanitizer (KASAN) to detect use-after-free memory access violations in real-time
• Monitor system call patterns using auditd or eBPF-based tools to identify suspicious fcntl()/close() race patterns
• Deploy SentinelOne Singularity Platform with Linux agent to detect kernel exploitation attempts and anomalous process behaviors
• Implement file integrity monitoring on /proc/locks access patterns

Monitoring Recommendations

• Configure kernel logging to capture filelock subsystem warnings and errors
• Use performance monitoring tools to track unusual memory allocation failures in kernel context
• Deploy runtime security solutions that can detect kernel memory corruption attempts
• Monitor for processes that repeatedly access /proc/locks without legitimate administrative purpose

How to Mitigate CVE-2024-41012

Immediate Actions Required

• Update the Linux kernel to a patched version that addresses CVE-2024-41012
• Review and restrict access to /proc/locks if possible in your environment
• Enable kernel security features such as KASAN in development and testing environments
• Apply distribution-specific security updates from your Linux vendor

Patch Information

The fix replaces the unreliable do_lock_file_wait() call with locks_remove_posix() for handling the fcntl/close race condition. The locks_remove_posix() function is designed to reliably remove all POSIX locks associated with a given file and files_struct combination, matching the behavior already used in filp_flush().

Multiple patch commits are available across kernel stable branches:

• Kernel commit 3cad1bc010416c6dd780643476bc59ed742436b9
• Kernel commit 5f5d0799eb0a01d550c21b7894e26b2d9db55763
• Kernel commit dc2ce1dfceaa0767211a9d963ddb029ab21c4235

Debian users should refer to the Debian LTS Security Announcement for distribution-specific patch information.

Workarounds

• Limit local user access to systems running vulnerable kernel versions where possible
• Implement mandatory access control policies using SELinux or AppArmor to restrict which processes can perform file locking operations
• Consider restricting read access to /proc/locks to reduce the exploitability of the information disclosure aspect
• Use container isolation with restricted capabilities to limit kernel attack surface for untrusted workloads

# Check current kernel version for vulnerability assessment
uname -r

# Verify if patched kernel is available in your distribution
apt-cache policy linux-image-$(uname -r)  # Debian/Ubuntu
yum check-update kernel  # RHEL/CentOS

# Restrict /proc/locks access (temporary mitigation)
chmod 400 /proc/locks