cbcvebase.
CVE-2024-39486
published 2024-07-06

CVE-2024-39486: In the Linux kernel, the following vulnerability has been resolved: drm/drm_file: Fix pid refcounting race , Maxime Ripard , Thomas Zimmermann filp->pid is…

PriorityP430high7CVSS 3.1
AVLACHPRLUINSUCHIHAH
EPSS
0.22%
13.0th percentile
In the Linux kernel, the following vulnerability has been resolved: drm/drm_file: Fix pid refcounting race , Maxime Ripard , Thomas Zimmermann 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.

Affected

16 ranges
VendorProductVersion rangeFixed in
debianlinux< linux 6.9.8-1 (forky)linux 6.9.8-1 (forky)
linuxlinux
linuxlinux>= 031ddd28008971cce0b5626379b910d0a05fb4dd < 16682588ead4a593cf1aebb33b36df4d1e9e4ffa16682588ead4a593cf1aebb33b36df4d1e9e4ffa
linuxlinux>= 1c7a387ffef894b1ab3942f0482dac7a6e0a909c < 0acce2a5c619ef1abdee783d7fea5eac78ce48440acce2a5c619ef1abdee783d7fea5eac78ce4844
linuxlinux>= 1c7a387ffef894b1ab3942f0482dac7a6e0a909c < 4f2a129b33a2054e62273edd5a051c34c08d96e94f2a129b33a2054e62273edd5a051c34c08d96e9
linuxlinux>= 6.6.9 < 6.6.376.6.37
linuxlinux_kernel
linuxlinux_kernel>= 0 < 6.9.8-16.9.8-1
linuxlinux_kernel>= 0 < 6.9.8-16.9.8-1
linuxlinux_kernel>= 0 < 6.8.0-48.486.8.0-48.48
linuxlinux_kernel>= 6.6.9 < 6.6.376.6.37
linuxlinux_kernel>= 6.7 < 6.9.86.9.8
msrcazl3_kernel_6.6.35.1-5_on_azure_linux_3.0
msrcazl3_kernel_6.6.47.1-1_on_azure_linux_3.0
msrcazure_linux_3.0_arm
msrcazure_linux_3.0_x64

CVSS provenance

nvdv3.17.0HIGHCVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
osv7.0HIGH
vendor_debian7.0LOW
vendor_msrc7.0HIGH
vendor_redhat7.0HIGH
vendor_ubuntu5.5MEDIUM
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.