i965 renderbuffer miptree creation failure not properly handled
Submitted by Anssi Hannula
Assigned to Intel 3D Bugs Mailing List
Link to original bug (#110601)
Description
Created attachment 144142 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.
Attachment 144142, "Fix for issue (1), singlesample_mt use after free":
0001-i965-fix-singlesample_mt-use-after-free.patch
Version: git