UBUNTU-CVE-2024-39486
In the Linux kernel, the following vulnerability has been resolved: drm/drm_file: Fix pid refcounting race <[email protected]>, Maxime Ripard <[email protected]>, Thomas Zimmermann <[email protected]> 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, <pid B>, 1) mutex_unlock(&dev->filelist_mutex) begin drm_file_update_pid mutex_lock(&dev->filelist_mutex) rcu_replace_pointer(filp->pid, <pid A>, 1) mutex_unlock(&dev->filelist_mutex) get_pid(<pid A>) synchronize_rcu() put_pid(<pid B>) *** pid B reaches refcount 0 and is freed here *** get_pid(<pid B>) *** UAF *** synchronize_rcu() put_pid(<pid A>) 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.
02 / AFFECTED SOFTWARE
Affected packages
11 explicit affected versions
50 explicit affected versions
6 explicit affected versions
12 explicit affected versions
19 explicit affected versions
6 explicit affected versions
12 explicit affected versions
10 explicit affected versions
12 explicit affected versions
7 explicit affected versions
7 explicit affected versions
13 explicit affected versions
9 explicit affected versions
35 explicit affected versions
18 explicit affected versions
12 explicit affected versions
13 explicit affected versions
4 explicit affected versions
23 explicit affected versions
16 explicit affected versions
21 explicit affected versions
16 explicit affected versions
10 explicit affected versions
14 explicit affected versions
7 explicit affected versions
12 explicit affected versions
12 explicit affected versions
14 explicit affected versions
1 explicit affected versions
7 explicit affected versions
12 explicit affected versions
12 explicit affected versions
7 explicit affected versions
1 explicit affected versions
37 explicit affected versions
13 explicit affected versions
5 explicit affected versions
10 explicit affected versions
26 explicit affected versions
13 explicit affected versions
29 explicit affected versions
13 explicit affected versions
6 explicit affected versions
7 explicit affected versions
33 explicit affected versions
23 explicit affected versions
10 explicit affected versions
12 explicit affected versions
7 explicit affected versions
12 explicit affected versions
10 explicit affected versions
26 explicit affected versions
14 explicit affected versions
5 explicit affected versions
15 explicit affected versions
13 explicit affected versions
14 explicit affected versions
16 explicit affected versions
15 explicit affected versions
3 explicit affected versions
51 explicit affected versions
12 explicit affected versions
12 explicit affected versions
27 explicit affected versions
8 explicit affected versions
8 explicit affected versions
5 explicit affected versions
8 explicit affected versions
10 explicit affected versions
11 explicit affected versions
13 explicit affected versions
13 explicit affected versions
7 explicit affected versions
10 explicit affected versions
12 explicit affected versions
44 explicit affected versions
16 explicit affected versions
3 explicit affected versions
13 explicit affected versions
26 explicit affected versions
37 explicit affected versions
15 explicit affected versions
14 explicit affected versions
38 explicit affected versions
9 explicit affected versions
11 explicit affected versions
6 explicit affected versions
7 explicit affected versions
4 explicit affected versions
13 explicit affected versions
43 explicit affected versions
10 explicit affected versions
8 explicit affected versions
10 explicit affected versions
14 explicit affected versions
4 explicit affected versions
11 explicit affected versions
1 explicit affected versions
8 explicit affected versions
03 / CONNECTIONS
Connected vulnerabilities
04 / EVIDENCE
Source records
In the Linux kernel, the following vulnerability has been resolved: drm/drm_file: Fix pid refcounting race <[email protected]>, Maxime Ripard <[email protected]>, Thomas Zimmermann <[email protected]> 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, <pid B>, 1) mutex_unlock(&dev->filelist_mutex) begin drm_file_update_pid mutex_lock(&dev->filelist_mutex) rcu_replace_pointer(filp->pid, <pid A>, 1) mutex_unlock(&dev->filelist_mutex) get_pid(<pid A>) synchronize_rcu() put_pid(<pid B>) *** pid B reaches refcount 0 and is freed here *** get_pid(<pid B>) *** UAF *** synchronize_rcu() put_pid(<pid A>) 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.
05 / REFERENCES
Further evidence
- https://git.kernel.org/linus/4f2a129b33a2054e62273edd5a051c34c08d96e9
- https://git.kernel.org/stable/c/0acce2a5c619ef1abdee783d7fea5eac78ce4844
- https://git.kernel.org/stable/c/16682588ead4a593cf1aebb33b36df4d1e9e4ffa
- https://git.kernel.org/stable/c/4f2a129b33a2054e62273edd5a051c34c08d96e9
- https://ubuntu.com/security/CVE-2024-39486
- https://ubuntu.com/security/notices/USN-7089-1
- https://ubuntu.com/security/notices/USN-7089-2
- https://ubuntu.com/security/notices/USN-7089-3
- https://ubuntu.com/security/notices/USN-7089-4
- https://ubuntu.com/security/notices/USN-7089-5
- https://ubuntu.com/security/notices/USN-7089-6
- https://ubuntu.com/security/notices/USN-7089-7
- https://ubuntu.com/security/notices/USN-7090-1
- https://ubuntu.com/security/notices/USN-7095-1
- https://ubuntu.com/security/notices/USN-7156-1
- https://www.cve.org/CVERecord?id=CVE-2024-39486