{ "schema_version": "1.6.1", "id": "RPI-CVE-2024-35932", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2024-35932" ], "published": "2024-05-19T10:11:49Z", "summary": "drm/vc4: don't check if plane->state->fb == state->fb", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vc4: don't check if plane->state->fb == state->fb\n\nCurrently, when using non-blocking commits, we can see the following\nkernel warning:\n\n[ 110.908514] ------------[ cut here ]------------\n[ 110.908529] refcount_t: underflow; use-after-free.\n[ 110.908620] WARNING: CPU: 0 PID: 1866 at lib/refcount.c:87 refcount_dec_not_one+0xb8/0xc0\n[ 110.908664] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device cmac algif_hash aes_arm64 aes_generic algif_skcipher af_alg bnep hid_logitech_hidpp vc4 brcmfmac hci_uart btbcm brcmutil bluetooth snd_soc_hdmi_codec cfg80211 cec drm_display_helper drm_dma_helper drm_kms_helper snd_soc_core snd_compress snd_pcm_dmaengine fb_sys_fops sysimgblt syscopyarea sysfillrect raspberrypi_hwmon ecdh_generic ecc rfkill libaes i2c_bcm2835 binfmt_misc joydev snd_bcm2835(C) bcm2835_codec(C) bcm2835_isp(C) v4l2_mem2mem videobuf2_dma_contig snd_pcm bcm2835_v4l2(C) raspberrypi_gpiomem bcm2835_mmal_vchiq(C) videobuf2_v4l2 snd_timer videobuf2_vmalloc videobuf2_memops videobuf2_common snd videodev vc_sm_cma(C) mc hid_logitech_dj uio_pdrv_genirq uio i2c_dev drm fuse dm_mod drm_panel_orientation_quirks backlight ip_tables x_tables ipv6\n[ 110.909086] CPU: 0 PID: 1866 Comm: kodi.bin Tainted: G C 6.1.66-v8+ #32\n[ 110.909104] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)\n[ 110.909114] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 110.909132] pc : refcount_dec_not_one+0xb8/0xc0\n[ 110.909152] lr : refcount_dec_not_one+0xb4/0xc0\n[ 110.909170] sp : ffffffc00913b9c0\n[ 110.909177] x29: ffffffc00913b9c0 x28: 000000556969bbb0 x27: 000000556990df60\n[ 110.909205] x26: 0000000000000002 x25: 0000000000000004 x24: ffffff8004448480\n[ 110.909230] x23: ffffff800570b500 x22: ffffff802e03a7bc x21: ffffffecfca68c78\n[ 110.909257] x20: ffffff8002b42000 x19: ffffff802e03a600 x18: 0000000000000000\n[ 110.909283] x17: 0000000000000011 x16: ffffffffffffffff x15: 0000000000000004\n[ 110.909308] x14: 0000000000000fff x13: ffffffed577e47e0 x12: 0000000000000003\n[ 110.909333] x11: 0000000000000000 x10: 0000000000000027 x9 : c912d0d083728c00\n[ 110.909359] x8 : c912d0d083728c00 x7 : 65646e75203a745f x6 : 746e756f63666572\n[ 110.909384] x5 : ffffffed579f62ee x4 : ffffffed579eb01e x3 : 0000000000000000\n[ 110.909409] x2 : 0000000000000000 x1 : ffffffc00913b750 x0 : 0000000000000001\n[ 110.909434] Call trace:\n[ 110.909441] refcount_dec_not_one+0xb8/0xc0\n[ 110.909461] vc4_bo_dec_usecnt+0x4c/0x1b0 [vc4]\n[ 110.909903] vc4_cleanup_fb+0x44/0x50 [vc4]\n[ 110.910315] drm_atomic_helper_cleanup_planes+0x88/0xa4 [drm_kms_helper]\n[ 110.910669] vc4_atomic_commit_tail+0x390/0x9dc [vc4]\n[ 110.911079] commit_tail+0xb0/0x164 [drm_kms_helper]\n[ 110.911397] drm_atomic_helper_commit+0x1d0/0x1f0 [drm_kms_helper]\n[ 110.911716] drm_atomic_commit+0xb0/0xdc [drm]\n[ 110.912569] drm_mode_atomic_ioctl+0x348/0x4b8 [drm]\n[ 110.913330] drm_ioctl_kernel+0xec/0x15c [drm]\n[ 110.914091] drm_ioctl+0x24c/0x3b0 [drm]\n[ 110.914850] __arm64_sys_ioctl+0x9c/0xd4\n[ 110.914873] invoke_syscall+0x4c/0x114\n[ 110.914897] el0_svc_common+0xd0/0x118\n[ 110.914917] do_el0_svc+0x38/0xd0\n[ 110.914936] el0_svc+0x30/0x8c\n[ 110.914958] el0t_64_sync_handler+0x84/0xf0\n[ 110.914979] el0t_64_sync+0x18c/0x190\n[ 110.914996] ---[ end trace 0000000000000000 ]---\n\nThis happens because, although `prepare_fb` and `cleanup_fb` are\nperfectly balanced, we cannot guarantee consistency in the check\nplane->state->fb == state->fb. This means that sometimes we can increase\nthe refcount in `prepare_fb` and don't decrease it in `cleanup_fb`. The\nopposite can also be true.\n\nIn fact, the struct drm_plane .state shouldn't be accessed directly\nbut instead, the `drm_atomic_get_new_plane_state()` helper function should\nbe used. So, we could stick to this check, but using\n`drm_atomic_get_new_plane_state()`. But actually, this check is not re\n---truncated---", "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.1.21-1+rpt1", "1:6.1.47-1+rpt2", "1:6.1.47-1+rpt4", "1:6.1.54-1+rpt2", "1:6.1.58-1+rpt2", "1:6.1.63-1+rpt1", "1:6.1.73-1+rpt1", "1:6.6.20-1+rpt1" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.1.0-rpi1-rpi-v6", "binary_version": "1:6.1.21-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi1-rpi-v7", "binary_version": "1:6.1.21-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi1-rpi-v7l", "binary_version": "1:6.1.21-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi1-rpi-v8", "binary_version": "1:6.1.21-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi2-rpi-v6", "binary_version": "1:6.1.47-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi2-rpi-v7", "binary_version": "1:6.1.47-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi2-rpi-v7l", "binary_version": "1:6.1.47-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi2-rpi-v8", "binary_version": "1:6.1.47-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-2712", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v6", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v8", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi4-rpi-2712", "binary_version": "1:6.1.54-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi4-rpi-v6", "binary_version": "1:6.1.54-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi4-rpi-v7", "binary_version": "1:6.1.54-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi4-rpi-v7l", "binary_version": "1:6.1.54-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi4-rpi-v8", "binary_version": "1:6.1.54-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi6-rpi-2712", "binary_version": "1:6.1.58-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi6-rpi-v6", "binary_version": "1:6.1.58-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi6-rpi-v7", "binary_version": "1:6.1.58-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi6-rpi-v7l", "binary_version": "1:6.1.58-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi6-rpi-v8", "binary_version": "1:6.1.58-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi7-rpi-2712", "binary_version": "1:6.1.63-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi7-rpi-v6", "binary_version": "1:6.1.63-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi7-rpi-v7", "binary_version": "1:6.1.63-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi7-rpi-v7l", "binary_version": "1:6.1.63-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi7-rpi-v8", "binary_version": "1:6.1.63-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi8-rpi-2712", "binary_version": "1:6.1.73-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi8-rpi-v6", "binary_version": "1:6.1.73-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi8-rpi-v7", "binary_version": "1:6.1.73-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi8-rpi-v7l", "binary_version": "1:6.1.73-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi8-rpi-v8", "binary_version": "1:6.1.73-1+rpt1" }, { "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" } ] }, "database_specific": { "per_version": { "1:6.1.21-1+rpt1": { "linux_commit": "0afb5e98488aed7017b9bf321b575d0177feb7ed", "upstream_version": "6.1.21", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.86" }, "1:6.1.47-1+rpt2": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.86" }, "1:6.1.47-1+rpt4": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.86", "compiled_filter": false }, "1:6.1.54-1+rpt2": { "linux_commit": "2906f7abdc03d4a92b6b0e2e0c87ea2a9dffe8f7", "upstream_version": "6.1.54", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.86" }, "1:6.1.58-1+rpt2": { "linux_commit": "ccf1586ad0663fa91238ac56abf6340d6d740d18", "upstream_version": "6.1.58", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.86" }, "1:6.1.63-1+rpt1": { "linux_commit": null, "upstream_version": "6.1.63", "assessment": "upstream version (no usable Linux commit)", "upstream_fixed": "6.1.86" }, "1:6.1.73-1+rpt1": { "linux_commit": null, "upstream_version": "6.1.73", "assessment": "upstream version (no usable Linux commit)", "upstream_fixed": "6.1.86" }, "1:6.6.20-1+rpt1": { "linux_commit": "6f16847710cc0502450788b9f12f0a14d3429668", "upstream_version": "6.6.20", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.6.27" } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2024-35932" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/48bfb4b03c5ff6e1fa1dc73fb915e150b0968c40" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/d6b2fe2db1d0927b2d7df5c763eba55d0e1def3c" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/5343f724c912c77541029123f47ecd3d2ea63bdd" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/5ee0d47dcf33efd8950b347dcf4d20bab12a3fa9" } ], "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 path is entered through `DRM_IOCTL_MODE_ATOMIC` (and the legacy cursor/async-flip path) on the local DRM device node `/dev/dri/cardN`. There is no network or remote-peer input involved, and no physical device manipulation is needed.\nAC:L - The attacker drives both sides of the race by issuing back-to-back non-blocking atomic commits with a chosen framebuffer pattern, and `drm_atomic_helper_commit()` is documented to overlap the next commit's prepare/swap with the previous commit's `cleanup_planes()`, so the imbalance is produced on demand. It is reliable enough that it fired during ordinary desktop playback (the kodi trace in the commit message).\nPR:L - An unprivileged local user needs only an open FD on the primary DRM node plus DRM master, and `drm_master_open()` grants mastership to the first opener with no capability check \u2014 routine for the console user on Pi-class kiosk/signage/embedded systems via the `video` group or logind ACL. The paired `VC4_GEM_MADVISE` ioctl used to weaponize the underflow is `DRM_RENDER_ALLOW`, requiring even less.\nUI:N - The attacker triggers the imbalance entirely through its own sequence of atomic commit ioctls on its own framebuffers. No victim action, mount, or file open is required.\nS:U - The corruption stays within the kernel's own security authority \u2014 a kernel-managed GEM object refcount and its DMA-coherent backing store. No VM, IOMMU, or sandbox boundary is crossed.\nC:H - The unbalanced decrement steals the `usecnt` reference held by an active scanout, an in-flight V3D job, or an exported dma-buf, letting `vc4_bo_purge()` call `dma_free_wc()` on a buffer still referenced by the HVS display list and the GPU \u2014 a use-after-free of DMA memory whose reallocated contents are then fetched and displayed. Per kernel scoring guidance a use-after-free is High confidentiality since the freed object's contents become attacker-observable.\nI:H - The same premature free leaves the V3D able to keep DMA-writing render targets into CMA memory that has been returned to the allocator and handed to another consumer, giving a write primitive into memory owned by an unrelated allocation. Use-after-free of a hardware-referenced buffer is exploitable memory corruption, so High.\nA:H - The immediate observed effect is a `refcount_t: underflow; use-after-free` WARN in `refcount_dec_not_one()`, which is a kernel panic on the many production and hardened kernels built with `panic_on_warn`. Purging a buffer still under scanout additionally corrupts the display and can oops the driver." } } }