Carl Worth <cwo...@cworth.org> writes: > And here's another that isn't the same pattern, (no "1", so not part of > the same search/replace issue), but potentially still worth looking > at. Here, there are three things being multiplied. I haven't looked at ... > src/mesa/tnl/t_vertex.c: vtx->vertex_buf = _mesa_align_calloc(vb_size * > max_vertex_size, 32 );
Sorry. I misread that one. The second argument is an alignment, not a term being multiplied. There is still a potential integer overflow here in computing a size to be allocated. And that same potential issue still exists in all calls to _mesa_align_malloc, _mesa_align_calloc, _mesa_align_realloc, malloc, and realloc where there is multiplication involved in computing the buffer size to be allocated. So the patch I just put together only fixes the tip of the iceberg, (the piece that's easy to fix since calloc already accepts two arguments with an implicit multiplication and catches overflow). For this issue in cairo, the Mozilla folks cooked up a little macro to provide a two-argument malloc that explicitly checks for integer overflow and evaluates to NULL in that case, (with no call to malloc at all). For mesa, a slightly more general solution would be useful, since a three-argument multiplication is quite common, (primitive_size * stride * height) in allocations. > Since the first list above is small enough, I'm happy to put together a > patch for this issue and trust that with peer review we can avoid > introducing any new bugs with the patch. I've got this done now and I'll send it to the list separately. -Carl
pgpsPVIITdMvk.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
