Bug 693248

Summary:	DeviceN remap structure should be dynamically allocated
Product:	Ghostscript	Reporter:	Michael Vrhel <michael.vrhel>
Component:	Color	Assignee:	Ken Sharp <ken.sharp>
Status:	RESOLVED FIXED
Severity:	normal	CC:	ghostpdl-bugs
Priority:	P4
Version:	master
Hardware:	PC
OS:	Windows 7
Customer:		Word Size:	---

Description Michael Vrhel 2012-08-02 23:15:43 UTC

Right now the structure int_remap_color_info_s has a fixed size for the number of colorants that can be handled.  This number is specified by MAX_COMPONENTS_IN_DEVN.   If a document has more than this number of colorants in a DeviceN color space we will have all sort of ugly things occur since the interpreter has no knowledge of the size limit of this structure.  Either the interpreter needs to know the size or better yet, the structure should be dynamically allocated to the number ov colorants needed.

Comment 1 Michael Vrhel 2012-08-02 23:16:18 UTC

Assigning to Ray who wanted to take care of this one

Comment 2 Ray Johnston 2012-08-02 23:49:48 UTC

I investigated and psi/zcolor.c has a check:

       if (r_size(&namesarray) > GS_CLIENT_COLOR_MAX_COMPONENTS)
        return_error(e_limitcheck);

If we change this to MAX_COMPONENTS_IN_DEVN then any overflow in icremap.c
due to access outside the array bounds, however, I still think that we should
have MAX_COMPONENTS_IN_DEVN set to GS_CLIENT_COLOR_MAX_COMPONENTS. Why it
should ever be less is not clear to me.

Comment 3 Michael Vrhel 2012-08-03 03:08:18 UTC

I think MAX_COMPONENTS_IN_DEVN should be replaced with a dynamic allocation but I dont have a problem with going to GS_CLIENT_COLOR_MAX_COMPONENTS if it doesn't effect performance

Comment 4 Ken Sharp 2023-05-31 16:01:55 UTC

'Fixed' in commit 7a8e8f962f45f6f05c34e8ac2626f9caa8fe8460

Replaces MAX_COMPONENTS_IN_DEVN with GS_CLIENT_COLOR_MAX_COMPONENTS.