There will be a crash if the guest destroy context 0. As the context 0 is
allocate in renderer init, not destroy in vrend_renderer_context_destroy.
The context will be freed in renderer fini by calling vrend_decode_reset.
Signed-off-by: Li Qiang <liq3ea@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
In vrend clear dispatch function, the 'buffers' is read from
guest. A malicious guest can specify a bad 'buffers' to make
a the function call util_format_is_pure_uint() even the
'ctx->sub->surf[i]' is NULL. This can cause a NULL pointer deref.
Make a sanity check to avoid this.
[airlied: use a define]
Signed-off-by: Li Qiang <liq3ea@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
As the 'pkt_length' and 'offlen' can be malicious from guest,
the vrend_create_shader function has an integer overflow, this
will make the next 'memcpy' oob access. This patch avoid this.
Signed-off-by: Li Qiang <liq3ea@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The 'num_elements' can be controlled by the guest but the
'vrend_vertex_element_array' has a fixed 'elements' field.
This can cause a heap overflow. Add sanity check of 'num_elements'.
Signed-off-by: Li Qiang <liq3ea@gmail.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
When parsing texture instruction, it doesn't stop if the
'cur' is ',', the loop variable 'i' will also be increased
and be used to index the 'inst.TexOffsets' array. This can lead
an oob access issue. This patch avoid this.
Signed-off-by: Li Qiang <liq3ea@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
In parse_identifier, it doesn't stop copying '*pcur'
untill encounter the NULL. As the 'ret' has a
fixed-size buffer, if the '*pcur' has a long string,
there will be a buffer overflow. This patch avoid this.
Signed-off-by: Li Qiang <liq3ea@gmail.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The vertext_buffer_index is read from guest and then used
to index the 'vbo' array in struct 'vrend_sub_context'.
Add sanity check for this to avoid oob issue.
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Li Qiang <liq3ea@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The 'blit_ctx->initialised' is not setted to true.
Every time init blit context, it will create a new
'blit_ctx->gl_context' thus causing a memory leak.
This patch avoid this.
Signed-off-by: Li Qiang <liq3ea@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Add the sanity check of the 'nr_cbufs' to avoid stack
overflow.
Signed-off-by: Li Qiang <liq3ea@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Create a context more than once causes memory leak issue.
Juest return if the context exists.
Signed-off-by: Li Qiang <liq3ea@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Just return if the resource has been attached a iov
to avoid memory leak.
Signed-off-by: Li Qiang <liq3ea@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The benchmark fails to start, the translation of gl_Identity is incorrect,
UMAD TEMP[0], SV[0].xxxx, TEMP[0].xxxx, TEMP[1]
is translated to:
temp0[0] = vec4(uintBitsToFloat((gl_InstanceID * floatBitsToUint(temp0[0].xxxx) + floatBitsToUint(temp0[1]))));
Which results in the following error:
shader failed to compile
0:23(34): error: could not implicitly convert operands to arithmetic operator
0:23(34): error: operands to arithmetic operators must be numeric
0:23(17): error: no matching function for call to `uintBitsToFloat(error)'; candidates are:
It seems we can use the same workaround as gl_VertexID, I didn't
observe any regression running various gl_InstanceId tests from
piglit:
temp0[0] = vec4(uintBitsToFloat((floatBitsToUint(vec4(intBitsToFloat(gl_InstanceID))) * floatBitsToUint(temp0[0].xxxx) + floatBitsToUint(temp0[1]))));
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
apitrace & epoxy with EGL don't work nicely together, using glx works
around this issue for now (disabled by default).
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
They should mostly be fine, as long the shader compiles. The reported
error should be enough to diagnose something going wrong in case of
failure.
This should help avoiding temporary regressions when new properties are
introduced in mesa.git before they are either handled or filtered out by
virgl, as was the case with commit fbe6e92899.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If the shader failed to be finished, it should be removed from the
hashtable if it was already inserted. Use the goto error path in this
case to handle shader destroy and prevent potential later lookup of
invalid shader from the hashtable.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Some piglit tests read/write outside of fix-sized arrays. Return an
error in this case. Note: further investigation needed to avoid
such access in the first place.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If we have a lot of draws we end up traversing the linked list
looking for the same shader on each draw call even if the
shader is the same one we used the last time.
This removes a chunk of CPU overhead in the draw path.
This seems to do better in xonotic traces, we at least don't
traverse as much of the list to pick up the shaders.
I think we should be using a hash table here really.
We weren't converting integer sampler results correctly,
so bad things ensued, this uses the info in the sampler
view to recreate the proper return values and do the
correct casting.
Li Qiang
Dave Airlie
Marc-André Lureau