|Summary:||Null pointer dereference in gx_default_create_buf_device()|
|Component:||Fuzzing||Assignee:||Robin Watts <robin.watts>|
Description zhailiangliang 2022-02-14 12:11:49 UTC
Comment 1 Ken Sharp 2022-02-14 13:37:41 UTC
This does indeed seg fault on both Windows and Linux, including on current master. The problem is something to do with trying to render a large number of bits in memory. In gx_default_create_buf_device() if 'mem' is NULL (a signal from gdev_prn_allocate that we should render entirely in memory, see line 442 of gdevprn.c) then at line 1402 we set mdev to be *pbdev, which in this case means that target and mdev are the same. Since they are the same (devicen) we pick up the initialise routine from the mdproto prototype. In this case that prototype is 'mem_x_device' (see base/gdevmx.h) which is some kind of special device prototype as it has **no** function prototypes at all. We don't check device function pointers for NULL, because device function tables are not supposed to contain NULL (with the special exception of fill_rectangle). And at this point, I'm at a loss.....
Comment 2 Robin Watts 2022-02-16 17:02:54 UTC
Fixed in: commit ae1061d948d88667bdf51d47d918c4684d0f67df Author: Robin Watts <Robin.Watts@artifex.com> Date: Wed Feb 16 15:22:50 2022 +0000 Bug 704945: Add init_device_procs entry for mem_x_device. When allocating a buffer device, we rely on an init_device_procs being defined for the device we are using as a prototype. Which device we use as a prototype depends upon the number of bits per pixel we are using. For bpp > 64, we use mem_x_device, which does not currently have an init_device_procs defined. This is a fairly hard case to tickle, as very few devices use more than 64 bits per pixel. The DeviceN device is one of the few that does, and then the problem only kicks in if the MaxBitmap figure is high enough (or conversely the resolution is low enough).