Effectively, this driver has a max safe LINE_LOOP vertex count of 0xffff_ffff/2/4=0x1fff_ffff. If we were to need a polyfill for TRIANGLE_STRIP or TRIANGLE_FAN, then `u_index_count_converted_indices(nr) -> (nr-2)*3`, so a max safe vertex count of `(x-2)*3)*(index_size=4) = 0xffff_ffff` => `x = 0xffff_ffff/3/4+2 = 0x1555_5557`. (~358M) This is all pretty unreasonable numbers. I think the safe thing to do is to just claim OUT_OF_MEMORY above some arbitrary limit like 10M, which both leaves us tons of safety margin and also is more verts than is reasonable in one draw call. We can have a pref for it for tuning and testing. FWIW, the source code for the disassembly with the crashing line is generated here: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/auxiliary/indices/u_indices_gen.py#L222 Is this exploitable? You would need to control where this freshly allocated buffer gets mapped to, and aim your destination e.g. object for writes directly after it. This affects both 32bit and 64bit. (`sizeof(unsigned) -> 4`) How many users hit this? I believe it's just users who run mesa/vmwgfx for their graphics driver. (I think just Linux on vmware?) According to telemetry: https://firefoxgraphics.github.io/telemetry/#view=linux Of Linux users, `mesa/vmwgfx - 1.9%` Of all users, `Linux - 4.3%` So of all users, Linux+mesa/vmwgfx is 0.0817% (~1:1200)
Bug 1836705 Comment 15 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Effectively, this driver has a max safe LINE_LOOP vertex count of 0xffff_ffff/2/4=0x1fff_ffff. If we were to need a polyfill for TRIANGLE_STRIP or TRIANGLE_FAN, then `u_index_count_converted_indices(nr) -> (nr-2)*3`, so a max safe vertex count of `(x-2)*3*(index_size=4) = 0xffff_ffff` => `x = 0xffff_ffff/3/4+2 = 0x1555_5557`. (~358M) This is all pretty unreasonable numbers. I think the safe thing to do is to just claim OUT_OF_MEMORY above some arbitrary limit like 10M, which both leaves us tons of safety margin and also is more verts than is reasonable in one draw call. We can have a pref for it for tuning and testing. FWIW, the source code for the disassembly with the crashing line is generated here: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/auxiliary/indices/u_indices_gen.py#L222 Is this exploitable? You would need to control where this freshly allocated buffer gets mapped to, and aim your destination e.g. object for writes directly after it. This affects both 32bit and 64bit. (`sizeof(unsigned) -> 4`) How many users hit this? I believe it's just users who run mesa/vmwgfx for their graphics driver. (I think just Linux on vmware?) According to telemetry: https://firefoxgraphics.github.io/telemetry/#view=linux Of Linux users, `mesa/vmwgfx - 1.9%` Of all users, `Linux - 4.3%` So of all users, Linux+mesa/vmwgfx is 0.0817% (~1:1200)