Bug 1227492 (CVE-2024-39486) - VUL-0: CVE-2024-39486: kernel: drm/drm_file: Fix pid refcounting race
Summary: VUL-0: CVE-2024-39486: kernel: drm/drm_file: Fix pid refcounting race
Status: NEW
Alias: CVE-2024-39486
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents (show other bugs)
Version: unspecified
Hardware: Other Other
: P3 - Medium : Normal
Target Milestone: ---
Assignee: Mel Gorman
QA Contact: Security Team bot
URL: https://smash.suse.de/issue/412950/
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-07-08 09:05 UTC by SMASH SMASH
Modified: 2024-07-09 15:11 UTC (History)
5 users (show)

See Also:
Found By: Security Response Team
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description SMASH SMASH 2024-07-08 09:05:33 UTC
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, <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.

References:
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-39486
https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2024/CVE-2024-39486.mbox
https://git.kernel.org/stable/c/16682588ead4a593cf1aebb33b36df4d1e9e4ffa
https://git.kernel.org/stable/c/0acce2a5c619ef1abdee783d7fea5eac78ce4844
https://git.kernel.org/stable/c/4f2a129b33a2054e62273edd5a051c34c08d96e9
https://www.cve.org/CVERecord?id=CVE-2024-39486
https://bugzilla.redhat.com/show_bug.cgi?id=2296094