ihadzic at research.bell-labs.com
Tue Oct 18 07:25:33 PDT 2011
While hacking something else, I stumbled upon two potential issues
in drm_fb_helper. Could someone who knows this better than me enlighten
whether the problem is realistic or whether I am overseeing something ?
If the problem is real (or a potential trouble waiting to happen), I have
cut some patches that address this and I can send them.
First, in drm_fb_helper_init, the size of crtc_info allocated is for
crtc_count entries, the loop that populates crtc_info at the end of the
_init function scans the whole list of connectors. So if GPU specifies
crtc_count that is smaller than the total number of CRTCs, the loop will
overrun the allocated space and corrupt memory. Although no GPU driver in
current tree does that, I could imagine a GPU using the smaller number for
crtc_count if it does not want some CRTCs used for fbcon.
Second (similar in nature) problem is the loop at the end of
drm_setup_crtcs function that populates modeset->connectors array.
The size of that array is fb_helper->max_conn_count (which is specified by
the GPU driver and can be anything), while the the loop runs for
fb_helper->connector_count iterations which can include all available
connectors (per drm_fb_helper_single_add_all_connectors). So at least in
theory that loop can overrun the modset->connectors array and corrupt
Both cases may be theoretical at this time, but they look like a trouble
waiting to happen (e.g., future GPUs may have a mix of CRTCs and
connectors that could evoke the described error). If those who know
better, agree with my analysis, I'll be glad to send some patchwork.
More information about the dri-devel