summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authordumbbell <dumbbell@FreeBSD.org>2013-11-25 11:15:51 +0000
committerdumbbell <dumbbell@FreeBSD.org>2013-11-25 11:15:51 +0000
commitfa0e069a02747538a8e14c1468b8a5cda2005a16 (patch)
treef6c676730f799a2b3738ee114a63d22e81a9d02d
parentc0d52e2df7912cb7b7c172f42c87b0bd46ec41d0 (diff)
downloadFreeBSD-src-fa0e069a02747538a8e14c1468b8a5cda2005a16.zip
FreeBSD-src-fa0e069a02747538a8e14c1468b8a5cda2005a16.tar.gz
drm: Dereference pointers given to qsort_r()'s cmp callback
drm_le_cmp() (qsort_r()'s callback) receives pointers to elements in the array passed to qsort_r(), not the elements themselves. Before this fix, the use of qsort_r() shuffled the array, not sorted it, because the compare callback accessed random memory locations, not the expected elements. This bug triggered an infinite loop in KDE/xserver: 1. KDE has a kded module called "randrmonitor" which queries xserver for current monitors at startup and then listens to RandR notifications from xserver. 2. xserver handles the query from "randrmonitor" by polling the video device using the "drm_mode_getconnector()" ioctl. This ioctl returns a list of connectors and, for those with a connected monitor, the available modes. Each modes list is sorted by the kernel before returning. When xserver gets the connectors list, it sorts the modes lists again. In the case of this bug, when two modes are equal (in xserver's compare function PoV), their order is kept stable (ie. the kernel order is kept for those two modes). And because the list was shuffled by the kernel, the order of two equal modes was frequently changed in the final modes list in xserver. 3. xserver compares the returned connectors list with the list obtained earlier. In particular, it compares the sorted modes lists for each connector. If a property of a connector changes (eg. modes), xserver sends a "RRNotify_OutputChange" notification. Because of the change of order between equal modes, xserver sent a notification after each polling of the connectors. 4. "randrmonitor" receives a notification, triggered by its query. The notification doesn't contain the new connectors list, therefore, it asks for the new list using the same function: go back to step #2. MFC after: 3 days
-rw-r--r--sys/dev/drm2/drm_linux_list_sort.c4
1 files changed, 2 insertions, 2 deletions
diff --git a/sys/dev/drm2/drm_linux_list_sort.c b/sys/dev/drm2/drm_linux_list_sort.c
index 973ce4a..ae4cd64 100644
--- a/sys/dev/drm2/drm_linux_list_sort.c
+++ b/sys/dev/drm2/drm_linux_list_sort.c
@@ -42,8 +42,8 @@ drm_le_cmp(void *priv, const void *d1, const void *d2)
struct drm_list_sort_thunk *thunk;
thunk = priv;
- le1 = __DECONST(struct list_head *, d1);
- le2 = __DECONST(struct list_head *, d2);
+ le1 = *(struct list_head **)d1;
+ le2 = *(struct list_head **)d2;
return ((thunk->cmp)(thunk->priv, le1, le2));
}
OpenPOWER on IntegriCloud