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

[Koichiro Den]

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

-- 
2.43.0