Skip to main content

CVE-2024-35932: Vulnerability in Linux Linux

High
VulnerabilityCVE-2024-35932cvecve-2024-35932
Published: Sun May 19 2024 (05/19/2024, 10:10:40 UTC)
Source: CVE
Vendor/Project: Linux
Product: Linux

Description

In the Linux kernel, the following vulnerability has been resolved: drm/vc4: don't check if plane->state->fb == state->fb Currently, when using non-blocking commits, we can see the following kernel warning: [ 110.908514] ------------[ cut here ]------------ [ 110.908529] refcount_t: underflow; use-after-free. [ 110.908620] WARNING: CPU: 0 PID: 1866 at lib/refcount.c:87 refcount_dec_not_one+0xb8/0xc0 [ 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 [ 110.909086] CPU: 0 PID: 1866 Comm: kodi.bin Tainted: G C 6.1.66-v8+ #32 [ 110.909104] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT) [ 110.909114] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 110.909132] pc : refcount_dec_not_one+0xb8/0xc0 [ 110.909152] lr : refcount_dec_not_one+0xb4/0xc0 [ 110.909170] sp : ffffffc00913b9c0 [ 110.909177] x29: ffffffc00913b9c0 x28: 000000556969bbb0 x27: 000000556990df60 [ 110.909205] x26: 0000000000000002 x25: 0000000000000004 x24: ffffff8004448480 [ 110.909230] x23: ffffff800570b500 x22: ffffff802e03a7bc x21: ffffffecfca68c78 [ 110.909257] x20: ffffff8002b42000 x19: ffffff802e03a600 x18: 0000000000000000 [ 110.909283] x17: 0000000000000011 x16: ffffffffffffffff x15: 0000000000000004 [ 110.909308] x14: 0000000000000fff x13: ffffffed577e47e0 x12: 0000000000000003 [ 110.909333] x11: 0000000000000000 x10: 0000000000000027 x9 : c912d0d083728c00 [ 110.909359] x8 : c912d0d083728c00 x7 : 65646e75203a745f x6 : 746e756f63666572 [ 110.909384] x5 : ffffffed579f62ee x4 : ffffffed579eb01e x3 : 0000000000000000 [ 110.909409] x2 : 0000000000000000 x1 : ffffffc00913b750 x0 : 0000000000000001 [ 110.909434] Call trace: [ 110.909441] refcount_dec_not_one+0xb8/0xc0 [ 110.909461] vc4_bo_dec_usecnt+0x4c/0x1b0 [vc4] [ 110.909903] vc4_cleanup_fb+0x44/0x50 [vc4] [ 110.910315] drm_atomic_helper_cleanup_planes+0x88/0xa4 [drm_kms_helper] [ 110.910669] vc4_atomic_commit_tail+0x390/0x9dc [vc4] [ 110.911079] commit_tail+0xb0/0x164 [drm_kms_helper] [ 110.911397] drm_atomic_helper_commit+0x1d0/0x1f0 [drm_kms_helper] [ 110.911716] drm_atomic_commit+0xb0/0xdc [drm] [ 110.912569] drm_mode_atomic_ioctl+0x348/0x4b8 [drm] [ 110.913330] drm_ioctl_kernel+0xec/0x15c [drm] [ 110.914091] drm_ioctl+0x24c/0x3b0 [drm] [ 110.914850] __arm64_sys_ioctl+0x9c/0xd4 [ 110.914873] invoke_syscall+0x4c/0x114 [ 110.914897] el0_svc_common+0xd0/0x118 [ 110.914917] do_el0_svc+0x38/0xd0 [ 110.914936] el0_svc+0x30/0x8c [ 110.914958] el0t_64_sync_handler+0x84/0xf0 [ 110.914979] el0t_64_sync+0x18c/0x190 [ 110.914996] ---[ end trace 0000000000000000 ]--- This happens because, although `prepare_fb` and `cleanup_fb` are perfectly balanced, we cannot guarantee consistency in the check plane->state->fb == state->fb. This means that sometimes we can increase the refcount in `prepare_fb` and don't decrease it in `cleanup_fb`. The opposite can also be true. In fact, the struct drm_plane .state shouldn't be accessed directly but instead, the `drm_atomic_get_new_plane_state()` helper function should be used. So, we could stick to this check, but using `drm_atomic_get_new_plane_state()`. But actually, this check is not re ---truncated---

AI-Powered Analysis

AILast updated: 06/29/2025, 08:12:17 UTC

Technical Analysis

CVE-2024-35932 is a vulnerability identified in the Linux kernel's Direct Rendering Manager (DRM) subsystem, specifically within the vc4 driver used for Broadcom VideoCore IV GPUs, commonly found in Raspberry Pi devices. The flaw arises from improper reference count management related to framebuffer (fb) objects during non-blocking atomic commits. The vulnerability manifests as a refcount underflow and use-after-free condition, triggered when the kernel incorrectly handles the lifecycle of framebuffer objects associated with DRM planes. The root cause is the direct access to the drm_plane's .state pointer instead of using the recommended drm_atomic_get_new_plane_state() helper function, leading to inconsistent reference counting between prepare_fb and cleanup_fb functions. This inconsistency can cause the reference count to be decremented more times than it was incremented or vice versa, resulting in memory corruption and potential kernel crashes. The kernel warning logs indicate a refcount_t underflow and a use-after-free error, which can destabilize the system or potentially be leveraged for privilege escalation or arbitrary code execution in a local context. The vulnerability affects Linux kernel versions including commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 and likely other versions incorporating the flawed vc4 driver code. Although no known exploits are currently in the wild, the issue is significant due to the kernel-level memory corruption it causes. The vulnerability is particularly relevant for systems running Linux on Raspberry Pi hardware or other devices using the vc4 DRM driver. The fix involves correcting the reference counting logic and ensuring the use of drm_atomic_get_new_plane_state() to maintain state consistency during atomic commits.

Potential Impact

For European organizations, the impact of CVE-2024-35932 depends largely on the deployment of Linux systems running the affected kernel versions with the vc4 DRM driver, notably Raspberry Pi devices. These devices are widely used in educational, industrial IoT, and prototyping environments across Europe. Exploitation could lead to kernel crashes causing denial of service, system instability, or potentially privilege escalation if combined with other vulnerabilities. This can disrupt critical services, especially in sectors relying on embedded Linux systems such as manufacturing automation, smart city infrastructure, and research institutions. While the vulnerability requires local access and is not remotely exploitable by itself, compromised or untrusted users could leverage it to escalate privileges or cause system failures. The use-after-free condition could also be a stepping stone for more sophisticated attacks if chained with other exploits. Given the increasing adoption of Raspberry Pi and similar hardware in European educational and industrial contexts, the vulnerability poses a moderate risk to availability and integrity of affected systems.

Mitigation Recommendations

European organizations should prioritize patching Linux kernels on all affected devices, especially Raspberry Pi systems running the vc4 DRM driver. This includes updating to the latest stable kernel versions where the fix for CVE-2024-35932 has been applied. For environments where immediate patching is not feasible, organizations should restrict local access to trusted users only and monitor for unusual kernel warnings or crashes related to DRM operations. Implementing strict user privilege separation and employing kernel hardening techniques such as SELinux or AppArmor can reduce the risk of exploitation. Additionally, organizations should audit their use of embedded Linux devices and ensure that firmware and software are regularly updated. For developers and system integrators, avoiding direct access to drm_plane->state and using drm_atomic_get_new_plane_state() as recommended will prevent similar issues in custom kernel modules or drivers. Finally, maintaining comprehensive logging and alerting on kernel errors can facilitate early detection of exploitation attempts.

Need more detailed analysis?Get Pro

Technical Details

Data Version
5.1
Assigner Short Name
Linux
Date Reserved
2024-05-17T13:50:33.130Z
Cisa Enriched
true
Cvss Version
null
State
PUBLISHED

Threat ID: 682d9828c4522896dcbe21ec

Added to database: 5/21/2025, 9:08:56 AM

Last enriched: 6/29/2025, 8:12:17 AM

Last updated: 7/31/2025, 9:47:16 AM

Views: 12

Actions

PRO

Updates to AI analysis are available only with a Pro account. Contact root@offseq.com for access.

Please log in to the Console to use AI analysis features.

Need enhanced features?

Contact root@offseq.com for Pro access with improved analysis and higher rate limits.

Latest Threats