CVE-2024-35932
- Source
- https://nvd.nist.gov/vuln/detail/CVE-2024-35932
- Import Source
- https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2024-35932.json
- JSON Data
- https://api.test.osv.dev/v1/vulns/CVE-2024-35932
- Downstream
- Related
- Published
- 2024-05-19T10:10:40Z
- Modified
- 2025-10-09T09:47:20.361837Z
- Summary
- drm/vc4: don't check if plane->state->fb == state->fb
- Details
-
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] refcountt: underflow; use-after-free. [ 110.908620] WARNING: CPU: 0 PID: 1866 at lib/refcount.c:87 refcountdecnotone+0xb8/0xc0 [ 110.908664] Modules linked in: rfcomm sndseqdummy sndhrtimer sndseq sndseqdevice cmac algifhash aesarm64 aesgeneric algifskcipher afalg bnep hidlogitechhidpp vc4 brcmfmac hciuart btbcm brcmutil bluetooth sndsochdmicodec cfg80211 cec drmdisplayhelper drmdmahelper drmkmshelper sndsoccore sndcompress sndpcmdmaengine fbsysfops sysimgblt syscopyarea sysfillrect raspberrypihwmon ecdhgeneric ecc rfkill libaes i2cbcm2835 binfmtmisc joydev sndbcm2835(C) bcm2835codec(C) bcm2835isp(C) v4l2mem2mem videobuf2dmacontig sndpcm bcm2835v4l2(C) raspberrypigpiomem bcm2835mmalvchiq(C) videobuf2v4l2 sndtimer videobuf2vmalloc videobuf2memops videobuf2common snd videodev vcsmcma(C) mc hidlogitechdj uiopdrvgenirq uio i2cdev drm fuse dmmod drmpanelorientationquirks backlight iptables xtables 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 : refcountdecnotone+0xb8/0xc0 [ 110.909152] lr : refcountdecnotone+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] refcountdecnotone+0xb8/0xc0 [ 110.909461] vc4bodecusecnt+0x4c/0x1b0 [vc4] [ 110.909903] vc4cleanupfb+0x44/0x50 [vc4] [ 110.910315] drmatomichelpercleanupplanes+0x88/0xa4 [drmkmshelper] [ 110.910669] vc4atomiccommittail+0x390/0x9dc [vc4] [ 110.911079] committail+0xb0/0x164 [drmkmshelper] [ 110.911397] drmatomichelpercommit+0x1d0/0x1f0 [drmkmshelper] [ 110.911716] drmatomiccommit+0xb0/0xdc [drm] [ 110.912569] drmmodeatomicioctl+0x348/0x4b8 [drm] [ 110.913330] drmioctlkernel+0xec/0x15c [drm] [ 110.914091] drmioctl+0x24c/0x3b0 [drm] [ 110.914850] _arm64sysioctl+0x9c/0xd4 [ 110.914873] invokesyscall+0x4c/0x114 [ 110.914897] el0svccommon+0xd0/0x118 [ 110.914917] doel0svc+0x38/0xd0 [ 110.914936] el0svc+0x30/0x8c [ 110.914958] el0t64synchandler+0x84/0xf0 [ 110.914979] el0t64sync+0x18c/0x190 [ 110.914996] ---[ end trace 0000000000000000 ]---
This happens because, although
prepare_fbandcleanup_fbare perfectly balanced, we cannot guarantee consistency in the check plane->state->fb == state->fb. This means that sometimes we can increase the refcount inprepare_fband don't decrease it incleanup_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 usingdrm_atomic_get_new_plane_state(). But actually, this check is not re ---truncated--- - References
-
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- https://git.kernel.org/stable/c/48bfb4b03c5ff6e1fa1dc73fb915e150b0968c40
- https://git.kernel.org/stable/c/5343f724c912c77541029123f47ecd3d2ea63bdd
- https://git.kernel.org/stable/c/5ee0d47dcf33efd8950b347dcf4d20bab12a3fa9
- https://git.kernel.org/stable/c/d6b2fe2db1d0927b2d7df5c763eba55d0e1def3c
Affected packages
Git / git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Affected ranges
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introduced1da177e4c3f41524e886b7f1b8a0c1fc7321cac2Fixed48bfb4b03c5ff6e1fa1dc73fb915e150b0968c40
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introduced1da177e4c3f41524e886b7f1b8a0c1fc7321cac2Fixedd6b2fe2db1d0927b2d7df5c763eba55d0e1def3c
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introduced1da177e4c3f41524e886b7f1b8a0c1fc7321cac2Fixed5343f724c912c77541029123f47ecd3d2ea63bdd
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introduced1da177e4c3f41524e886b7f1b8a0c1fc7321cac2Fixed5ee0d47dcf33efd8950b347dcf4d20bab12a3fa9