Bug 57733

Summary: read-after-free with llvmpipe in try_update_scene_state
Product: Mesa Reporter: Benoit Jacob <bjacob>
Component: OtherAssignee: Jose Fonseca <jfonseca>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium CC: brianp, glisse, jfonseca, jmuizelaar, zmo
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: apitrace trace

Description Benoit Jacob 2012-11-30 13:26:58 UTC
Created attachment 70829 [details]
apitrace trace

This was originally https://bugzilla.mozilla.org/show_bug.cgi?id=791905 and is what is causing the Mozilla security team to want to blacklist llvmpipe.

This is a use-after-free in llvmpipe in try_update_scene_state, and from looking at the call stacks in Valgrind, it looks like it might be a reference counting error.

I am attaching an apitrace that allows to consistently reproduce in Valgrind.

The error is:

==4016== Invalid read of size 8
==4016==    at 0x402F180: memcpy@@GLIBC_2.14 (mc_replace_strmem.c:877)
==4016==    by 0x4C81573: try_update_scene_state (lp_setup.c:869)
==4016==    by 0x4C7FE91: begin_binning (lp_setup.c:197)
==4016==    by 0x4C8011C: execute_clears (lp_setup.c:262)
==4016==    by 0x4C80254: set_scene_state (lp_setup.c:310)
==4016==    by 0x4C8034E: lp_setup_flush (lp_setup.c:342)
==4016==    by 0x4C71E07: llvmpipe_flush (lp_flush.c:55)
==4016==    by 0x4C71390: do_flush (lp_context.c:103)
==4016==    by 0x4DD6AB0: st_flush (st_cb_flush.c:86)
==4016==    by 0x4DD6B71: st_glFlush (st_cb_flush.c:120)
==4016==    by 0x4D011BE: _mesa_flush (context.c:1612)
==4016==    by 0x4D012A0: _mesa_Flush (context.c:1644)
==4016==  Address 0xce19ff0 is 0 bytes inside a block of size 64 free'd
==4016==    at 0x402C5F9: free (vg_replace_malloc.c:446)
==4016==    by 0x4CFB98D: _mesa_align_free (imports.c:176)
==4016==    by 0x4DCEF0B: _mesa_free_parameter_list (prog_parameter.c:87)
==4016==    by 0x4DC8822: _mesa_delete_program (program.c:357)
==4016==    by 0x4EC3D53: st_delete_program (st_cb_program.c:169)
==4016==    by 0x4DC8A36: _mesa_reference_program_ (program.c:422)
==4016==    by 0x4EB4BDF: _mesa_reference_program (program.h:102)
==4016==    by 0x4EB4C9C: st_reference_fragprog (st_program.h:265)
==4016==    by 0x4EB4E23: update_fp (st_atom_shader.c:93)
==4016==    by 0x4EAF9D6: st_validate_state (st_atom.c:203)
==4016==    by 0x4EBBE1E: st_Clear (st_cb_clear.c:464)
==4016==    by 0x4E1880A: _mesa_Clear (clear.c:231)
==4016== 

The command I use to replay the apitrace in Valgrind is:

LD_PRELOAD=/hack/mesa/build/linux-x86_64-debug/gallium/targets/libgl-xlib/libGL.so.1
LD_LIBRARY_PATH=/hack/mesa/build/linux-x86_64-debug/gallium/targets/libgl-xlib
valgrind --smc-check=all-non-file ../apitrace/build/glretrace -v
firefox.2.trace

As far as avoiding currently llvmpipe blacklisting in browsers goes, here is what would be useful:
 - either a work-around
 - or a careful assessment of the security implications, proving that this is not security-critical (i.e. does not actually allow an attacker to read memory).

Alternatively getting this fixed would allow to un-blacklist at least some newer versions.
Comment 1 Benoit Jacob 2012-11-30 13:32:38 UTC
Please make the default assignee not be a public mailing list.

Assigning to Jose for now just to change that.
Comment 2 Benoit Jacob 2012-11-30 13:34:29 UTC
At least the testcase didn't get published on mesa-dev, and having looked at it for a while I don't think the problem can be easily inferred by a third party just from the call stacks.
Comment 3 Brian Paul 2012-12-11 19:57:23 UTC
Fixed with mesa commit 2ee0b442528c7d0d0207504e8d315dfb5666afcd.

This will be in the Mesa 9.1 branch.
Comment 4 Benoit Jacob 2012-12-11 19:59:02 UTC
That's awesome. When is the 9.1 release scheduled?

The next step is to run the whole trunk conformance test suite on llvmpipe in valgrind, as well as the recent test cases, and if nothing bad comes up, un-blacklist 9.1 and newer versions.
Comment 5 Daniel Stone 2014-11-24 08:58:04 UTC
Un-securing.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.