| Bug ID | 99451 |
|---|---|
| Summary | polygon offset use after free |
| Product | Mesa |
| Version | git |
| Hardware | Other |
| OS | Linux (All) |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | Drivers/Gallium/radeonsi |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | zmichaels@oblong.com |
| QA Contact | dri-devel@lists.freedesktop.org |
Created attachment 129030 [details]
gdb script to verify use after free
Our application enables and disables GL_POLYGON_OFFSET_FILL multiple times per
frame, and it has been crashing on Ubuntu 16.04. (We are aware that our usage
pattern is probably not ideal.) We believe the crash is occurring because the
radeonsi driver is using the memory pointed to by
si_context->queued.named.poly_offset after it has been freed.
We have verified the use after free behavior by running the attached gdb script
against the master branch (commit 1e1bddf15a1720917b11e44dc639351ad613c3dc).
Unfortunately we are not yet able to provide a sample application to run this
against.
The following scenario may not be completely accurate, but hopefully it should
give a feel for the sequence of events leading up to this issue:
glEnable(GL_POLYGON_OFFSET_FILL)
* sets pipe_rasterizer_state->offset_tri to true
si_create_rs_state
* callocs rasterizer A
* sets A->uses_poly_offset to true because pipe_rasterizer_state->offset_tri
is true
si_bind_rs_state
* changes si_context->queued.named.rasterizer to rasterizer A
* calls si_update_poly_offset_state to make queued.named.poly_offset point
into rasterizer A
glDisable(GL_POLYGON_OFFSET_FILL)
* sets pipe_rasterizer_state->offset_tri to false
si_create_rs_state
* callocs rasterizer B
* sets B->uses_poly_offset to false because pipe_rasterizer_state->offset_tri
is false
si_bind_rs_state
* changes the rasterizer to rasterizer B
* calls si_update_poly_offset_state to make sure poly_offset is up to date
* si_update_poly_offset_state
* sets rs to si_context.queued.named.rasterizer, which is B
* returns without updating poly_offset because B->uses_poly_offset is
false
* poly_offset still points into rasterizer A
si_delete_rs_state
* does NOT set poly_offset to NULL because queued.named.rasterizer no longer
points to rasterizer A
* frees rasterizer A via si_pm4_delete_state
si_draw_vbo
* calls si_pm4_emit_dirty
* follows poly_offset into rasterizer A, which has been freed
* bad things happen
The patch attached below ensures si_update_poly_offset sets poly_offset to NULL
if uses_poly_offset is false. We think this makes sense because it always
leaves poly_offset in a valid state. Either it points into the currently queued
rasterizer, or it is NULL. If this does turn out to be the correct fix, the
attempt to NULL poly_offset from si_delete_rs_state should probably be removed
as well.
Thanks!
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
