[Bug 99451] polygon offset use after free

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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:
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux