💣Exploit CVE-2024-39486 - In the Linux kernel, the following vulnerability h

[Maksim]

CVE ID : CVE-2024-39486
Published : July 6, 2024, 10:15 a.m. | 1 day, 1 hour ago
Description : In the Linux kernel, the following vulnerability has been resolved: drm/drm_file: Fix pid refcounting race filp->pid is supposed to be a refcounted pointer; however, before this patch, drm_file_update_pid() only increments the refcount of a struct pid after storing a pointer to it in filp->pid and dropping the dev->filelist_mutex, making the following race possible: process A process B ========= ========= begin drm_file_update_pid mutex_lock(&dev->filelist_mutex) rcu_replace_pointer(filp->pid,
, 1) mutex_unlock(&dev->filelist_mutex) begin drm_file_update_pid mutex_lock(&dev->filelist_mutex) rcu_replace_pointer(filp->pid,
, 1) mutex_unlock(&dev->filelist_mutex) get_pid(
) synchronize_rcu() put_pid(
) *** pid B reaches refcount 0 and is freed here *** get_pid(
) *** UAF *** synchronize_rcu() put_pid(
) As far as I know, this race can only occur with CONFIG_PREEMPT_RCU=y because it requires RCU to detect a quiescent state in code that is not explicitly calling into the scheduler. This race leads to use-after-free of a "struct pid". It is probably somewhat hard to hit because process A has to pass through a synchronize_rcu() operation while process B is between mutex_unlock() and get_pid(). Fix it by ensuring that by the time a pointer to the current task's pid is stored in the file, an extra reference to the pid has been taken. This fix also removes the condition for synchronize_rcu(); I think that optimization is unnecessary complexity, since in that case we would usually have bailed out on the lockless check above.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
Full story here:

To view the content, you need to Sign In or Register.