[SRU][F][PATCH 0/2] CVE-2022-36402

Fri Sep 20 08:08:31 UTC 2024

On Fri, Sep 20, 2024 at 03:57:04PM +0900, 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].
                                                    ^^^
should actually be [2], not [1]. --------------------'
I'll send v2 for the fix. Please review the rest of the parts, thanks.

> 
> 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(-)
> 
> -- 
> 2.43.0
>