| Message ID | 20240920065711.8902-1-koichiro.den@canonical.com |
|---|---|
| Headers | show |
| Series | CVE-2022-36402 | expand |
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 >
On 20.09.24 10:08, Koichiro Den wrote: > 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. There is no need for a v2, we can adjust this when applying (and we have been notified). But also if a v2 was necessary, please do not fix individual parts. In such a case NACK the submission yourself and do a complete re-submission as v2 (or whichever version). That is clearer and less confusing. Thanks. But again, no need here. That typo is a simple adjustment which can be done while applying. -Stefan
Acked-by: Thibault Ferrante <thibault.ferrante@canonical.com> On 20-09-2024 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(-) >
Acked-by: Mehmet Basaran <mehmet.basaran@canonical.com> Koichiro Den <koichiro.den@canonical.com> writes: > [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 > > > -- > kernel-team mailing list > kernel-team@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/kernel-team
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
[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(-)