Skip to content

Conversation

@LinusU
Copy link
Collaborator

@LinusU LinusU commented Mar 15, 2019

ping @zbjornson, @chearon

I think that size_t might be the correct type here since it's a "type which is used to represent sizes of objects in bytes", and "it is guaranteed to be big enough to contain the size of the biggest object that system can handle".

Copy link
Collaborator

@zbjornson zbjornson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for picking this up! I think I said I'd work on it months ago and never did :(. Just a few questions.

(Github is being finicky. On the second comment, add: "Maybe consider keeping the members ints and just using size_t for the mul product?")

jpeg_destroy_decompress(args);
this->errorInfo.set(NULL, "malloc", errno);
return CAIRO_STATUS_NO_MEMORY;
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could consider combining these two if bodies into one since you don't have to check overflow immediately after doing the mul.

int width, height;
int naturalWidth, naturalHeight;
size_t width, height;
size_t naturalWidth, naturalHeight;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm trying to find any cases where int isn't big enough. The only one I found is reading a jpeg, where it's unsigned. GifLib, Cairo and librsvg all use int as far as I can tell. Was this type itself responsible for overflow?

One concern making this size_t is that width and height are passed directly to e.g. cairo_image_surface_create(format, int width, int height).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the image is 32798x32798 it will overflow and allocate way to little bytes since:

Screenshot 2019-03-16 at 10 12 57

Good point about passing to cairo, I think that we already check for some specific value since cairo only accepts a maxiumum width or height of 2^15 - 1 (I think, ref:

node-canvas/src/Image.cc

Lines 610 to 613 in 3d81e0a

/* Cairo limit:
* https://lists.cairographics.org/archives/cairo/2010-December/021422.html
*/
if (width > 32767 || height > 32767) {
)

Okay, I just realized that the image I'm loading has a larger width & height than that, maybe we should just check that before even setting naturalWidht and naturalHeight at all 🤔

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I meant to propose: keep the members as int (or unsigned) since that's the largest Cairo can take, and only cast to a larger type where you multiply them and risk overflow.

uint8_t *data = new uint8_t[naturalWidth * naturalHeight * 4];

size_t stride = naturalWidth * 4;
if (naturalWidth != 0 && stride / naturalWidth != 4) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We've got a host of these unchecked muls... might be worth copying a version of this function so it's easier to continue addressing them later.

https://github.com/nodejs/node/blob/master/src/util-inl.h#L297-304

(not sure if that link works, github is acting up. Line 297-304.)

@zbjornson
Copy link
Collaborator

@LinusU do you still want to move forward with this since #1385 was merged?

@LinusU
Copy link
Collaborator Author

LinusU commented Apr 4, 2019

Hmm, I don't know 😄

If Cairo is using int I don't really think that there is much we can gain by changing anything, let's just keep it as it is?

@zbjornson
Copy link
Collaborator

Makes senses to me! 😃

@LinusU LinusU closed this Apr 4, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants