{ "schema_version": "1.6.1", "id": "RPI-CVE-2024-39486", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2024-39486" ], "published": "2024-07-06T09:25:53Z", "summary": "drm/drm_file: Fix pid refcounting race", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/drm_file: Fix pid refcounting race\n\n, Maxime Ripard\n, Thomas Zimmermann \n\nfilp->pid is supposed to be a refcounted pointer; however, before this\npatch, drm_file_update_pid() only increments the refcount of a struct\npid after storing a pointer to it in filp->pid and dropping the\ndev->filelist_mutex, making the following race possible:\n\nprocess A process B\n========= =========\n begin drm_file_update_pid\n mutex_lock(&dev->filelist_mutex)\n rcu_replace_pointer(filp->pid, , 1)\n mutex_unlock(&dev->filelist_mutex)\nbegin drm_file_update_pid\nmutex_lock(&dev->filelist_mutex)\nrcu_replace_pointer(filp->pid, , 1)\nmutex_unlock(&dev->filelist_mutex)\nget_pid()\nsynchronize_rcu()\nput_pid() *** pid B reaches refcount 0 and is freed here ***\n get_pid() *** UAF ***\n synchronize_rcu()\n put_pid()\n\nAs far as I know, this race can only occur with CONFIG_PREEMPT_RCU=y\nbecause it requires RCU to detect a quiescent state in code that is not\nexplicitly calling into the scheduler.\n\nThis race leads to use-after-free of a \"struct pid\".\nIt is probably somewhat hard to hit because process A has to pass\nthrough a synchronize_rcu() operation while process B is between\nmutex_unlock() and get_pid().\n\nFix it by ensuring that by the time a pointer to the current task's pid\nis stored in the file, an extra reference to the pid has been taken.\n\nThis fix also removes the condition for synchronize_rcu(); I think\nthat optimization is unnecessary complexity, since in that case we\nwould usually have bailed out on the lockless check above.", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.6.20-1+rpt1", "1:6.6.28-1+rpt1", "1:6.6.31-1+rpt1" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.6.20+rpt-rpi-2712", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-v6", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-v7", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-v7l", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-v8", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.28+rpt-rpi-2712", "binary_version": "1:6.6.28-1+rpt1" }, { "binary_name": "linux-image-6.6.28+rpt-rpi-v6", "binary_version": "1:6.6.28-1+rpt1" }, { "binary_name": "linux-image-6.6.28+rpt-rpi-v7", "binary_version": "1:6.6.28-1+rpt1" }, { "binary_name": "linux-image-6.6.28+rpt-rpi-v7l", "binary_version": "1:6.6.28-1+rpt1" }, { "binary_name": "linux-image-6.6.28+rpt-rpi-v8", "binary_version": "1:6.6.28-1+rpt1" }, { "binary_name": "linux-image-6.6.31+rpt-rpi-2712", "binary_version": "1:6.6.31-1+rpt1" }, { "binary_name": "linux-image-6.6.31+rpt-rpi-v6", "binary_version": "1:6.6.31-1+rpt1" }, { "binary_name": "linux-image-6.6.31+rpt-rpi-v7", "binary_version": "1:6.6.31-1+rpt1" }, { "binary_name": "linux-image-6.6.31+rpt-rpi-v7l", "binary_version": "1:6.6.31-1+rpt1" }, { "binary_name": "linux-image-6.6.31+rpt-rpi-v8", "binary_version": "1:6.6.31-1+rpt1" } ] }, "database_specific": { "per_version": { "1:6.6.20-1+rpt1": { "linux_commit": "6f16847710cc0502450788b9f12f0a14d3429668", "upstream_version": "6.6.20", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.6.37" }, "1:6.6.28-1+rpt1": { "linux_commit": "0c341f47adc3578cd5f817aa20ee2b7f9ae6b23e", "upstream_version": "6.6.28", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.6.37" }, "1:6.6.31-1+rpt1": { "linux_commit": "c1432b4bae5b6582f4d32ba381459f33c34d1424", "upstream_version": "6.6.31", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.6.37" } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2024-39486" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/16682588ead4a593cf1aebb33b36df4d1e9e4ffa" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/0acce2a5c619ef1abdee783d7fea5eac78ce4844" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/4f2a129b33a2054e62273edd5a051c34c08d96e9" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-05T11:52:36Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 7.8, "cvss_v3_severity": "High", "scenario": "AV:L - The vulnerable code is reached through `ioctl()` on a DRM device node (`/dev/dri/card*` or `/dev/dri/renderD*`), which requires local access to the system. There is no network or remote path into `drm_ioctl_kernel()`.\nAC:L - The attacker owns both sides of the race \u2014 `fork()`/SCM_RIGHTS gives two processes sharing one `struct file`, and alternating ioctls from the two tgids re-enter `drm_file_update_pid()`'s update path on demand, so the race can be driven in a tight loop with attacker-controlled CPU pinning and preemption pressure. The required `CONFIG_PREEMPT_RCU` is the default on Android, mainstream distro `PREEMPT_DYNAMIC` kernels, and PREEMPT_RT, so it is not a rare configuration.\nPR:L - Only an unprivileged local user is needed: `drm_file_update_pid()` runs before `drm_ioctl_permit()`, so no DRM_AUTH, DRM_MASTER, or DRM_ROOT_ONLY check applies, and render nodes are routinely accessible to ordinary users (Android apps, desktop `render`/`video` group members) or via a DRM fd passed into a sandbox by the compositor.\nUI:N - The attacker performs the entire sequence itself \u2014 open the DRM node, fork, and issue concurrent ioctls. No victim process needs to act or be in any particular state.\nS:U - The use-after-free corrupts kernel slab memory within the same kernel security authority; no VM, IOMMU, or sandbox boundary is crossed by the flaw itself.\nC:H - The freed `struct pid` can be reallocated with attacker-sprayed data and is subsequently read by `put_pid()` (`pid->numbers[pid->level].ns`) and by pid-lookup paths, giving a use-after-free read primitive that can be leveraged to disclose arbitrary kernel memory.\nI:H - `get_pid()` performs a refcount increment into freed slab memory, and the stale reference later drives `refcount_dec_and_test()` plus `kmem_cache_free()` on a possibly reallocated object \u2014 a UAF write and double-free on a core object, which is a well-established primitive for heap grooming and local privilege escalation.\nA:H - The use-after-free on `struct pid` corrupts the pid slab cache and triggers refcount underflow warnings, invalid frees, and kernel oops/panic, and the race can be re-triggered repeatedly by an unprivileged process." } } }