{"uuid": "b90326d3-e5f1-4723-a7a6-21fb9f455d09", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-41012", "type": "seen", "source": "https://t.me/cvedetector/1498", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-41012 - In the Linux kernel, the following vulnerability h\", \n  \"Content\": \"CVE ID : CVE-2024-41012 \nPublished : July 23, 2024, 8:15 a.m. | 15\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nfilelock: Remove locks reliably when fcntl/close race is detected  \n  \nWhen fcntl_setlk() races with close(), it removes the created lock with  \ndo_lock_file_wait().  \nHowever, LSMs can allow the first do_lock_file_wait() that created the lock  \nwhile denying the second do_lock_file_wait() that tries to remove the lock.  \nSeparately, posix_lock_file() could also fail to  \nremove a lock due to GFP_KERNEL allocation failure (when splitting a range  \nin the middle).  \n  \nAfter the bug has been triggered, use-after-free reads will occur in  \nlock_get_status() when userspace reads /proc/locks. This can likely be used  \nto read arbitrary kernel memory, but can't corrupt kernel memory.  \n  \nFix it by calling locks_remove_posix() instead, which is designed to  \nreliably get rid of POSIX locks associated with the given file and  \nfiles_struct and is also used by filp_flush(). \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"23 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-23T10:32:59.000000Z"}