CVE-2024-35932

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© bcm2835_codec©
bcm2835_isp© v4l2_mem2mem videobuf2_dma_contig snd_pcm bcm2835_v4l2©
raspberrypi_gpiomem bcm2835_mmal_vchiq© videobuf2_v4l2 snd_timer
videobuf2_vmalloc videobuf2_memops videobuf2_common snd videodev
vc_sm_cma© 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—