Linux
CVE-2024-41012
MEDIUM
Severity by source
AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:H
Primary rating from NVD · only source for this CVE.
CVSS VectorNVD
Lifecycle Timeline
1DescriptionNVD
In the Linux kernel, the following vulnerability has been resolved:
filelock: Remove locks reliably when fcntl/close race is detected
When fcntl_setlk() races with close(), it removes the created lock with do_lock_file_wait(). However, LSMs can allow the first do_lock_file_wait() that created the lock while denying the second do_lock_file_wait() that tries to remove the lock. Separately, posix_lock_file() could also fail to remove a lock due to GFP_KERNEL allocation failure (when splitting a range in the middle).
After the bug has been triggered, use-after-free reads will occur in lock_get_status() when userspace reads /proc/locks. This can likely be used to read arbitrary kernel memory, but can't corrupt kernel memory.
Fix it by calling locks_remove_posix() instead, which is designed to reliably get rid of POSIX locks associated with the given file and files_struct and is also used by filp_flush().
AnalysisAI
In the Linux kernel, the following vulnerability has been resolved: filelock: Remove locks reliably when fcntl/close race is detected When fcntl_setlk() races with close(), it removes the created. Rated medium severity (CVSS 6.3). This Use After Free vulnerability could allow attackers to access freed memory to execute arbitrary code or crash the application.
Technical ContextAI
This vulnerability is classified as Use After Free (CWE-416), which allows attackers to access freed memory to execute arbitrary code or crash the application. In the Linux kernel, the following vulnerability has been resolved: filelock: Remove locks reliably when fcntl/close race is detected When fcntl_setlk() races with close(), it removes the created lock with do_lock_file_wait(). However, LSMs can allow the first do_lock_file_wait() that created the lock while denying the second do_lock_file_wait() that tries to remove the lock. Separately, posix_lock_file() could also fail to remove a lock due to GFP_KERNEL allocation failure (when splitting a range in the middle). After the bug has been triggered, use-after-free reads will occur in lock_get_status() when userspace reads /proc/locks. This can likely be used to read arbitrary kernel memory, but can't corrupt kernel memory. Fix it by calling locks_remove_posix() instead, which is designed to reliably get rid of POSIX locks associated with the given file and files_struct and is also used by filp_flush(). Affected products include: Linux Linux Kernel.
RemediationAI
A vendor patch is available. Apply the latest security update as soon as possible. Use smart pointers or garbage-collected languages. Set pointers to NULL after freeing. Enable memory sanitizers.
Same weakness CWE-416 – Use After Free
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today