summaryrefslogtreecommitdiff
path: root/devices
diff options
context:
space:
mode:
authorKen Sharp <ken.sharp@artifex.com>2023-05-04 13:25:54 +0100
committerKen Sharp <ken.sharp@artifex.com>2023-05-04 13:25:54 +0100
commit3dab3b466b2ed956875386f0675a37448cc5faba (patch)
treeddec745d720b164cad7816042f093fc2753b43f4 /devices
parentba57f3868fd9539d008032976da44b152332627d (diff)
downloadghostpdl-3dab3b466b2ed956875386f0675a37448cc5faba.tar.gz
GhostPDF, pdfwrite, graphics library - fix WMode usage
OSS-fuzz #58582 The fundamental problem here is that pdfwrite was assuming that the font WMode could only ever be 0 or 1 (the only two valid values) and so was using it as a bitfield, shifting and OR'ing it with other values. The file in this case has a CMap which contains : /WMode 8883123282518010140455180910294889 def Which gets clamped to the maximum unsigned integer 0x7fffff This led to a non-zero value in the flags to the glyph info code, when the value *should* have been 0, which caused the graphics library to take a code path which wasn't valid. This led to us trying to use a member of a structure whose pointer was NULL. I can't be certain whether other places in the code use WMode in the same way, so I've chosen to fix this at several levels. Firstly, in the code path we shouldn't reach (gs_type42_glyph_info_by_gid) check the value of pmat before calling gs_default_glyph_info. That code will try to use the matrix to scale the outline, so if it is NULL then the result is undefined. This prevents the seg fault. Secondly, in gdevpdtc.c, scan_cmap_text(), set wmode to be either 0 or 1, to ensure that it does work as a bit, rather than using the integer value from the font and assuming it will be 0 or 1. Finally in the three places in the PDF interpreter where we set the WMode for the font, check to see if the value is either 0 or 1 and if it is not, raise a warning and make it 0 or 1.
Diffstat (limited to 'devices')
-rw-r--r--devices/vector/gdevpdtc.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/devices/vector/gdevpdtc.c b/devices/vector/gdevpdtc.c
index eb366ce10..ba4ea78cb 100644
--- a/devices/vector/gdevpdtc.c
+++ b/devices/vector/gdevpdtc.c
@@ -431,7 +431,7 @@ scan_cmap_text(pdf_text_enum_t *pte, void *vbuf)
gs_font_type0 *const font = (gs_font_type0 *)pte->orig_font; /* Type 0, fmap_CMap */
/* Not sure. Changed for CDevProc callout. Was pte->current_font */
gs_text_enum_t scan = *(gs_text_enum_t *)pte;
- int wmode = font->WMode, code, rcode = 0;
+ int wmode = font->WMode == 0 ? 0 : 1, code, rcode = 0;
pdf_font_resource_t *pdsubf0 = NULL;
gs_font *subfont0 = NULL, *saved_subfont = NULL;
uint index = scan.index, xy_index = scan.xy_index, start_index = index;