APPLIED/Cmnt: [SRU][F][PATCH 0/2] CVE-2022-36402
Stefan Bader
stefan.bader at canonical.com
Wed Sep 25 09:50:13 UTC 2024
On 20.09.24 08:57, Koichiro Den wrote:
> [Impatct]
>
> drm/vmwgfx: Fix shader stage validation
>
> For multiple commands the driver was not correctly validating the shader
> stages resulting in possible kernel oopses. The validation code was only.
> if ever, checking the upper bound on the shader stages but never a lower
> bound (valid shader stages start at 1 not 0).
>
> Fixes kernel oopses ending up in vmw_binding_add, e.g.:
> Oops: 0000 [#1] PREEMPT SMP PTI
> CPU: 1 PID: 2443 Comm: testcase Not tainted 6.3.0-rc4-vmwgfx #1
> Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020
> RIP: 0010:vmw_binding_add+0x4c/0x140 [vmwgfx]
> Code: 7e 30 49 83 ff 0e 0f 87 ea 00 00 00 4b 8d 04 7f 89 d2 89 cb 48 c1 e0 03 4c 8b b0 40 3d 93 c0 48 8b 80 48 3d 93 c0 49 0f af de <48> 03 1c d0 4c 01 e3 49 8>
> RSP: 0018:ffffb8014416b968 EFLAGS: 00010206
> RAX: ffffffffc0933ec0 RBX: 0000000000000000 RCX: 0000000000000000
> RDX: 00000000ffffffff RSI: ffffb8014416b9c0 RDI: ffffb8014316f000
> RBP: ffffb8014416b998 R08: 0000000000000003 R09: 746f6c735f726564
> R10: ffffffffaaf2bda0 R11: 732e676e69646e69 R12: ffffb8014316f000
> R13: ffffb8014416b9c0 R14: 0000000000000040 R15: 0000000000000006
> FS: 00007fba8c0af740(0000) GS:ffff8a1277c80000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00000007c0933eb8 CR3: 0000000118244001 CR4: 00000000003706e0
> Call Trace:
> <TASK>
> vmw_view_bindings_add+0xf5/0x1b0 [vmwgfx]
> ? ___drm_dbg+0x8a/0xb0 [drm]
> vmw_cmd_dx_set_shader_res+0x8f/0xc0 [vmwgfx]
> vmw_execbuf_process+0x590/0x1360 [vmwgfx]
> vmw_execbuf_ioctl+0x173/0x370 [vmwgfx]
> ? __drm_dev_dbg+0xb4/0xe0 [drm]
> ? __pfx_vmw_execbuf_ioctl+0x10/0x10 [vmwgfx]
> drm_ioctl_kernel+0xbc/0x160 [drm]
> drm_ioctl+0x2d2/0x580 [drm]
> ? __pfx_vmw_execbuf_ioctl+0x10/0x10 [vmwgfx]
> ? do_fault+0x1a6/0x420
> vmw_generic_ioctl+0xbd/0x180 [vmwgfx]
> vmw_unlocked_ioctl+0x19/0x20 [vmwgfx]
> __x64_sys_ioctl+0x96/0xd0
> do_syscall_64+0x5d/0x90
> ? handle_mm_fault+0xe4/0x2f0
> ? debug_smp_processor_id+0x1b/0x30
> ? fpregs_assert_state_consistent+0x2e/0x50
> ? exit_to_user_mode_prepare+0x40/0x180
> ? irqentry_exit_to_user_mode+0xd/0x20
> ? irqentry_exit+0x3f/0x50
> ? exc_page_fault+0x8b/0x180
> entry_SYSCALL_64_after_hwframe+0x72/0xdc
>
> [Backport]
>
> The primary fix commit 14abdfae5082 targeted vmwgfx 2.20.0 and was
> successfully backported to stable trees 5.15.y and newer, hence already
> present in Jammy [1]. On the other hand, applying the fix to Focal,
> where vmwgfx version is 2.15.0, causes several conflicts due to the
> driver changes up to 2.20.0, highlighted by the missing
> "[PATCH v2 00/17] drm/vmwgfx add support for GL4" [1].
>
> To backport it without bumping the driver version and to minimize the
> introduction of various changes or features from the 2.15.0 to 2.20.0
> updates, I opted not to backport all dependent patches except for commit
> 878c6ecd3e24 ("drm/vmwgfx: Use enum to represent graphics context
> capabilities"); this helps preserve the structure of the primary fix
> with the added enum vmw_sm_type and vmw_private.sm_type, without adding
> any new feature.
>
> To backport 878c6ecd3e24 ("drm/vmwgfx: Use enum to represent graphics
> context capabilities"),
> - adjusted context due to missing commits:
> * 2bdb7380fe12 ("drm/vmwgfx: Remove a few unused functions")
> * ef7c7b7497d6 ("drm/vmwgfx: Also check for SVGA_CAP_DX before reading DX context support")]
>
> To backport 14abdfae5082 ("drm/vmwgfx: Fix shader stage validation"),
> - adjusted context due to missing commits:
> * c593197b6ece ("drm/vmwgfx: Fix fencing on SVGAv3")
> * d2e90ab3744f ("drm/vmwgfx: Support SM5 shader type in command buffer")]
> - manually adjusted vmw_shadertype_is_valid() so that max_allowed is to be
> SVGA3D_SHADERTYPE_DX10_MAX.
>
> [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2039227
> [2] https://lore.kernel.org/all/20200323231238.14839-1-rscheidegger.oss@gmail.com/
>
> [Fix]
>
> Noble: not affected
> Jammy: fixed via stable
> Focal: Backport - backported an additional commit and adjusted contexts, see [Backport]
> Bionic: fix will be sent to esm ML
> Xenial: fix will be sent to esm ML
> Trusty: not affected
>
> [Test Case]
>
> Compile and boot tested.
>
> Boot test was done on Ubuntu Desktop under two conditions on VMware
> Workstation 17.6.0 build-24238078; with SM4_1 support and Pre-DX Legacy.
> Confirmed that with SM4_1 support, the patched vmw_cmd_dx_* functions
> work without issues, while stressing simply using glxgears.
> - vmw_cmd_dx_set_shader
> - vmw_cmd_dx_set_single_constant_buffer
> - vmw_cmd_dx_set_shader_res
>
> [Where problems could occur]
>
> This fix affects those who use vmwgfx driver, an issue with this fix
> would be visible to the user via unpredicted system behavior or a system
> crash.
>
>
> Zack Rusin (1):
> drm/vmwgfx: Fix shader stage validation
>
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 11 +++++++++++
> drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 24 ++++++++++++------------
> 2 files changed, 23 insertions(+), 12 deletions(-)
>
Realized that the typo was actually only in the cover email. While this
is important to have for doing the review, it is not reflected anywhere
in the patches. So no adjustment needed there.
Applied to focal:linux/master-next. Thanks.
-Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xE8675DEECBEECEA3.asc
Type: application/pgp-keys
Size: 48643 bytes
Desc: OpenPGP public key
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20240925/1b6c48ad/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20240925/1b6c48ad/attachment-0001.sig>
More information about the kernel-team
mailing list