Integer underflow in the vrend_decode_set_shader_images() on virglrenderer

[Jun Yao]

Env
===
  Description: Ubuntu 20.04.3 LTS
  Release: 20.04

Package
=======
  virglrenderer_0.8.2

Vulnerability
=============
The is an integer underflow bug in the vrend_decode_set_shader_images(). Which
can be used to bypass the checking and leads to OOB write.

------------------------------------------------------------------------------
virgl_renderer_submit_cmd()
|
|-> vrend_decode_block()
 |
 | VIRGL_CCMD_SET_SHADER_IMAGES
 |
 |-> vrend_decode_set_shader_images()
  |
  | /**
  | * When the num_images is larger than PIPE_MAX_SHADER_IMAGES,
  | * we can obey the checking. The value of PIPE_MAX_SHADER_IMAGES
  | * is 32, if num_images is 33, the result of sub is -1. However,
  | * the type of num_images and start_slot is uint, -1 is bigger than
  | * start_slot, and it's ok.
  | */
  |
  | if (start_slot > PIPE_MAX_SHADER_BUFFERS ||
  | start_slot > PIPE_MAX_SHADER_BUFFERS - num_images)
  |
  | /* OOB write */
  | for (uint32_t i = 0; i < num_images; i++)
  | vrend_set_single_image_view(..., start_slot + i, format, access, layer_offset, level_size, handle);
------------------------------------------------------------------------------

The start_slot+i is larger than the PIPE_MAX_SHADER_IMAGES, which causes OOB write in the vrend_set_single_image_view():
------------------------------------------------------------------------------
 2941 void vrend_set_single_image_view(struct vrend_context *ctx,
 2942 uint32_t shader_type,
 2943 uint32_t index,
 2944 uint32_t format, uint32_t access,
 2945 uint32_t layer_offset, uint32_t level_size,
 2946 uint32_t handle)
 2947 {
 2948 struct vrend_image_view *iview = &ctx->sub->image_views[shader_type][index]; // oob read
 2951 if (handle) {
 2952 if (!has_feature(feat_images))
 2953 return;
 2954
 2955 res = vrend_renderer_ctx_res_lookup(ctx, handle);
 2956 if (!res) {
 2957 report_context_error(ctx, VIRGL_ERROR_CTX_ILLEGAL_RESOURCE, handle);
 2958 return;
 2959 }
 2960 iview->texture = res; // oob write
 2961 iview->format = tex_conv_table[format].internalformat;
 2962 iview->access = access;
 2963 iview->u.buf.offset = layer_offset;
 2964 iview->u.buf.size = level_size;
 2965 ctx->sub->images_used_mask[shader_type] |= (1u << index);
 2966 } else {
------------------------------------------------------------------------------

[Marc Deslauriers (mdeslaur)]

Hi,

Have you reported this issue to the virglrenderer developers?

If not, please report it to them. The bug tracker is here:

https://gitlab.freedesktop.org/virgl/virglrenderer/-/issues

Once you have done that, please let us know the bug number and once a fix is available we will package it for Ubuntu.

Thanks!

[Jun Yao (2freeman)]

Hi,

The bug number is https://gitlab.freedesktop.org/virgl/virglrenderer/-/issues/251.

Thanks,
Jun Yao

[Seth Arnold (seth-arnold)]

Hello Jun Yao, the upstream bug is still private -- is there progress being made upstream?

Thanks

[Jun Yao (2freeman)]

> Hello Jun Yao, the upstream bug is still private -- is there progress being made upstream?

Hi Seth, this problem has been fixed on upstream.

Thanks

[Steve Beattie (sbeattie)]

Issue 251 is not open upstream, but it looks like this was addressed in https://gitlab.freedesktop.org/virgl/virglrenderer/-/commit/2aed5d419722a0d9fbd17be9c7a1147e22b681de along with a couple of other security fixes in https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/654 . It does not look like these fixes have landed in a release yet upstream.

Hoever, the other two issues (249, 250) did get CVEs assigned for them, CVE-2022-0175 and CVE-2022-0135 respectively.

Jun Yao, was a CVE ever assigned for this issue?

[Jun Yao (2freeman)]

Hi,

> Issue 251 is not open upstream, but it looks like this was addressed in
>
https://gitlab.freedesktop.org/virgl/virglrenderer/-/commit/2aed5d419722a0d9fbd17be9c7a1147e22b681de
> along with a couple of other security fixes in
> https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/654
> . It does not look like these fixes have landed in a release yet upstream.

These two problems had been reported to the upstream, and they have been
fixed. As they are security problem, I marked the issues confidential and
they are not visible for others.

> Jun Yao, was a CVE ever assigned for this issue?

There are no CVEs assigned for these two issues.

Thanks,
Jun Yao

Steve Beattie <email address hidden> 于2022年4月12日周二 14:51写道：

> Issue 251 is not open upstream, but it looks like this was addressed in
>
> https://gitlab.freedesktop.org/virgl/virglrenderer/-/commit/2aed5d419722a0d9fbd17be9c7a1147e22b681de
> along with a couple of other security fixes in
> https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/654
> . It does not look like these fixes have landed in a release yet
> upstream.
>
> Hoever, the other two issues (249, 250) did get CVEs assigned for them,
> CVE-2022-0175 and CVE-2022-0135 respectively.
>
> Jun Yao, was a CVE ever assigned for this issue?
>
> ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2022-0135
>
> ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2022-0175
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1950940
>
> Title:
> Integer underflow in the vrend_decode_set_shader_images() on
> virglrenderer
>
> Status in virglrenderer package in Ubuntu:
> New
>
> Bug description:
> Env
> ===
> Description: Ubuntu 20.04.3 LTS
> Release: 20.04
>
> Package
> =======
> virglrenderer_0.8.2
>
> Vulnerability
> =============
> The is an integer underflow bug in the vrend_decode_set_shader_images().
> Which
> can be used to bypass the checking and leads to OOB write.
>
>
> ------------------------------------------------------------------------------
> virgl_renderer_submit_cmd()
> |
> |-> vrend_decode_block()
> |
> | VIRGL_CCMD_SET_SHADER_IMAGES
> |
> |-> vrend_decode_set_shader_images()
> |
> | /**
> | * When the num_images is larger than
> PIPE_MAX_SHADER_IMAGES,
> | * we can obey the checking. The value of
> PIPE_MAX_SHADER_IMAGES
> | * is 32, if num_images is 33, the result of sub is -1.
> However,
> | * the type of num_images and start_slot is uint, -1 is
> bigger than
> | * start_slot, and it's ok.
> | */
> |
> | if (start_slot > PIPE_MAX_SHADER_BUFFERS ||
> | start_slot > PIPE_MAX_SHADER_BUFFERS - num_images)
> |
> | /* OOB write */
> | for (uint32_t i = 0; i < num_images; i++)
> | vrend_set_single_image_view(..., start_slot + i,
> format, access, layer_offset, level_size, han...