cve/published/2024/CVE-2024-35932.mbox - pub/scm/linux/security/vulns - Git at Google

 From bippy-5f407fcff5a0 Mon Sep 17 00:00:00 2001
 From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 To: <linux-cve-announce@vger.kernel.org>
 Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org>
 Subject: CVE-2024-35932: drm/vc4: don't check if plane->state->fb == state->fb

 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 really
 needed. We can increase and decrease the refcount symmetrically without
 problems.

 This is going to make the code more simple and consistent.

 The Linux kernel CVE team has assigned CVE-2024-35932 to this issue.


 Affected and fixed versions
 ===========================

 	Fixed in 6.1.86 with commit 48bfb4b03c5ff6e1fa1dc73fb915e150b0968c40
 	Fixed in 6.6.27 with commit d6b2fe2db1d0927b2d7df5c763eba55d0e1def3c
 	Fixed in 6.8.6 with commit 5343f724c912c77541029123f47ecd3d2ea63bdd
 	Fixed in 6.9 with commit 5ee0d47dcf33efd8950b347dcf4d20bab12a3fa9

 Please see https://www.kernel.org for a full list of currently supported
 kernel versions by the kernel community.

 Unaffected versions might change over time as fixes are backported to
 older supported kernel versions.  The official CVE entry at
 	https://cve.org/CVERecord/?id=CVE-2024-35932
 will be updated if fixes are backported, please check that for the most
 up to date information about this issue.


 Affected files
 ==============

 The file(s) affected by this issue are:
 	drivers/gpu/drm/vc4/vc4_plane.c


 Mitigation
 ==========

 The Linux kernel CVE team recommends that you update to the latest
 stable kernel version for this, and many other bugfixes.  Individual
 changes are never tested alone, but rather are part of a larger kernel
 release.  Cherry-picking individual commits is not recommended or
 supported by the Linux kernel community at all.  If however, updating to
 the latest release is impossible, the individual changes to resolve this
 issue can be found at these commits:
 	https://git.kernel.org/stable/c/48bfb4b03c5ff6e1fa1dc73fb915e150b0968c40
 	https://git.kernel.org/stable/c/d6b2fe2db1d0927b2d7df5c763eba55d0e1def3c
 	https://git.kernel.org/stable/c/5343f724c912c77541029123f47ecd3d2ea63bdd
 	https://git.kernel.org/stable/c/5ee0d47dcf33efd8950b347dcf4d20bab12a3fa9
	From bippy-5f407fcff5a0 Mon Sep 17 00:00:00 2001
	From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
	To: <linux-cve-announce@vger.kernel.org>
	Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org>
	Subject: CVE-2024-35932: drm/vc4: don't check if plane->state->fb == state->fb

	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 really
	needed. We can increase and decrease the refcount symmetrically without
	problems.

	This is going to make the code more simple and consistent.

	The Linux kernel CVE team has assigned CVE-2024-35932 to this issue.


	Affected and fixed versions
	===========================

	Fixed in 6.1.86 with commit 48bfb4b03c5ff6e1fa1dc73fb915e150b0968c40
	Fixed in 6.6.27 with commit d6b2fe2db1d0927b2d7df5c763eba55d0e1def3c
	Fixed in 6.8.6 with commit 5343f724c912c77541029123f47ecd3d2ea63bdd
	Fixed in 6.9 with commit 5ee0d47dcf33efd8950b347dcf4d20bab12a3fa9

	Please see https://www.kernel.org for a full list of currently supported
	kernel versions by the kernel community.

	Unaffected versions might change over time as fixes are backported to
	older supported kernel versions. The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2024-35932
	will be updated if fixes are backported, please check that for the most
	up to date information about this issue.


	Affected files
	==============

	The file(s) affected by this issue are:
	drivers/gpu/drm/vc4/vc4_plane.c


	Mitigation
	==========

	The Linux kernel CVE team recommends that you update to the latest
	stable kernel version for this, and many other bugfixes. Individual
	changes are never tested alone, but rather are part of a larger kernel
	release. Cherry-picking individual commits is not recommended or
	supported by the Linux kernel community at all. If however, updating to
	the latest release is impossible, the individual changes to resolve this
	issue can be found at these commits:
	https://git.kernel.org/stable/c/48bfb4b03c5ff6e1fa1dc73fb915e150b0968c40
	https://git.kernel.org/stable/c/d6b2fe2db1d0927b2d7df5c763eba55d0e1def3c
	https://git.kernel.org/stable/c/5343f724c912c77541029123f47ecd3d2ea63bdd
	https://git.kernel.org/stable/c/5ee0d47dcf33efd8950b347dcf4d20bab12a3fa9