[Bug 110601] i965 renderbuffer miptree creation failure not properly handled

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Fri May 3 14:10:16 UTC 2019


https://bugs.freedesktop.org/show_bug.cgi?id=110601

            Bug ID: 110601
           Summary: i965 renderbuffer miptree creation failure not
                    properly handled
           Product: Mesa
           Version: git
          Hardware: All
                OS: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Drivers/DRI/i965
          Assignee: intel-3d-bugs at lists.freedesktop.org
          Reporter: anssi.hannula at bitwise.fi
        QA Contact: intel-3d-bugs at lists.freedesktop.org

Created attachment 144142
  --> https://bugs.freedesktop.org/attachment.cgi?id=144142&action=edit
Fix for issue (1), singlesample_mt use after free

In src/mesa/drivers/dri/i965/intel_mipmap_tree.c
intel_update_winsys_renderbuffer_miptree() the
intel_miptree_create_for_renderbuffer() call can fail and the function is
prepared for it.

However, there are several issues with the error handling:

(1) On failure exit from intel_update_winsys_renderbuffer_miptree(), the
singlesample_mt received via parameter remains assigned to
irb->singlesample_mt. However, in both callsites (brw_context.c
intel_process_dri2_buffer() and intel_update_image_buffer()) the miptree is
released on failure. This will lead to use-after-free and undefined behavior,
including crashes.

Either singlesample_mt should be NULLed or it should not be freed by caller.
I have no idea which one would be correct, but I've attached a patch that does
the former that seems to fix the use-after-free issues.


(2) On failure exit from intel_update_winsys_renderbuffer_miptree(), irb->mt
remains NULL. However, many functions seem to assume that irb->mt is non-null:

 (I) do_single_blorp_clear()
 (II) brw_postdraw_set_buffers_need_resolve()
 (III) update_renderbuffer_surfaces()

There are probably more, but those are the ones I saw crashes in with the test
code.

An example callpath for (I) above is:

brw_clear()
  => intel_prepare_render()
    => intel_update_renderbuffers()
      => intel_process_dri2_buffer()
        => intel_update_winsys_renderbuffer_miptree()
           => fails, irb->mt = NULL
  => brw_blorp_clear_color()
    => do_single_blorp_clear()
      => dereferences irb->mt, segfault

Attached is a hack patch that adds NULL checks to some places, but I imagine a
better way would be to somehow remove the renderbuffer altogether or something
to avoid having to add mt NULL checks everywhere...


I will open a separate issue for the failure in
intel_miptree_create_for_renderbuffer() that triggers this, but I think the
error handling should be fixed regardless of the failure reason - at least so
that there are no crashes.

I've attached the test application I used as mesa-issue-qt3d.cc. With the
patches I still don't see correct graphical output with it (I see the red line
as expected but the picture flashes rapidly), but I guess it may be expected
with the miptree creation failure - I do see correct output after making
miptree creation work.
Also included is an apitrace and glxinfo with mesa master without any patches.

This was tested on a ValleyView Gen7 (8086:0f31) with kernel 3.10.35, git
master mesa (2019-05-02). AFAICS the issues can happen with any HW/kernel as
long as intel_update_winsys_renderbuffer_miptree() manages to fail.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20190503/85f269be/attachment.html>


More information about the intel-3d-bugs mailing list