| Summary: | NULL pointer dereference in cairo-polygon-intersect.c:1170 | ||
|---|---|---|---|
| Product: | cairo | Reporter: | foca <foca> |
| Component: | general | Assignee: | Chris Wilson <chris> |
| Status: | RESOLVED MOVED | QA Contact: | cairo-bugs mailing list <cairo-bugs> |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
Proof of concept
Adds the proposed null ptr check |
||
Created attachment 134390 [details] [review] Adds the proposed null ptr check Attached is a patch to implement the proposed null ptr check. However, what's needed is an analysis of the PDF to see how exactly it's constructing this invalid data, since I seriously doubt having right==NULL is a valid software condition. So, ideally, this should be an assert() not a null ptr check. -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/cairo/cairo/issues/274. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 132102 [details] Proof of concept There is a NULL pointer dereference in cairo-polygon-intersect.c:1170 in function active_edges: 1142 static inline void 1143 active_edges (cairo_bo_edge_t *left, 1144 int32_t top, 1145 cairo_polygon_t *polygon) 1146 { ... 1150 /* Yes, this is naive. Consider this a placeholder. */ 1151 1152 while (left != NULL) { 1153 assert (is_zero (winding)); 1154 1155 do { 1156 winding[left->a_or_b] += left->edge.dir; 1157 if (! is_zero (winding)) 1158 break; 1159 1160 if unlikely ((left->deferred.other)) 1161 edges_end (left, top, polygon); 1162 1163 left = left->next; 1164 if (! left) 1165 return; 1166 } while (1); 1167 1168 right = left->next; 1169 do { 1170 if unlikely ((right->deferred.other)) left ->next is NULL in line 1168 so right is also set to NULL. When line 1170 is reached, the program tries to get deferred. Since right is 0, the program tries to dereference 0x30 causing a segmentation fault. This could be avoided with an extra check in 1169: 1169 if (right == NULL) return; This bug was found when using a poppler util, pdftocairo. A PoC is attached. To reproduce the bug use: pdftocairo -svg PoC.pdf This vulnerability has been found by Offensive Research at Salesforce.com: Alberto Garcia (@algillera), Francisco Oca (@francisco_oca) & Suleman Ali (@Salbei_)