In a recent MR [1], Adrian Johnson writes:
For additional safety you could change the unsigned long to size_t
since long is 32-bits on Win64. The CFF spec says the offset size used
in decode_index_offset must be between 1 and 4 so you could range
check that to avoid overflowing the offset.
This commit implements exactly that.
[1]: https://gitlab.freedesktop.org/cairo/cairo/-/merge_requests/382#note_1700743
Signed-off-by: Uli Schlachter <psychon@znc.in>
While working on the previous commit, I noticed that nothing makes sure
that the entry points within the font data. Thus, this could easily
cause out-of-bounds reads.
This commit adds a suitable length check for this.
Signed-off-by: Uli Schlachter <psychon@znc.in>
I was looking at [1]. While trying to reproduce the problem that is
described there, valgrind reported:
Argument 'size' of function malloc has a fishy (possibly negative) value: -8
at 0x48407B4: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x4B20E92: cairo_cff_font_read_name (cairo-cff-subset.c:895)
by 0x4B221AD: cairo_cff_font_read_font (cairo-cff-subset.c:1351)
by 0x4B24EF2: cairo_cff_font_generate (cairo-cff-subset.c:2587)
by 0x4B25EA3: _cairo_cff_subset_init (cairo-cff-subset.c:2979)
This commit is about fixing the above.
The function decode_index_offset() returns an unsigned long. This value
was cast to an "int" in cff_index_read(), leading to a possibility for
over/underflow. Also, nothing checked that an entry in the index table
had a non-zero length, leading to an entry with length -8 as reported by
valgrind.
Fix this by using "unsigned long" for the local variables and checking
the length to be non-negative.
With the above fixed, the original test case started crashing.
Apparently, cairo_cff_font_read_name() does not expect nor handle
failures from cff_index_read(). Thus, a check for this case was added to
make the new crash go away.
[1]: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=51324
Signed-off-by: Uli Schlachter <psychon@znc.in>
In _cairo_type3_glyph_surface_create(), we call
_cairo_surface_clipper_init(), but nothing ever called
_cairo_surface_clipper_reset() in this call. This commit adds that
missing call.
This fixes a leak of a clip.
Since I have no clue about this code (does _cairo_pdf_operators_fini()
possible use the clipper?), I did the patch like this. This should avoid
any possibility for a use-after-free.
Fixes: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=51043
Signed-off-by: Uli Schlachter <psychon@znc.in>
According to valgrind, there is a use-after-free here. The function
_cairo_ps_surface_emit_surface() temporarily replaces some member of a
struct and then later re-sets it. However, there is an early return
possible that would skip that part of the code.
This commit moves the re-set up so that no freed pointers are left
behind. This seems to fix the crash.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This adds the necessary dependencies for testing cairo-ps to CI and sets
up jobs for testing the ps2 and ps3 backends.
Signed-off-by: Uli Schlachter <psychon@znc.in>
It's not needed anymore.
Linking explicitly with libssp was required for toolchains where the
target libc doesn't implement stack smashing protection routines on
its own, and instead delegates to the generic implementations provided
by libssp. Notably, this was the case of mingw-w64 toolchains.
After discussion upstream with Meson developers [1], the stance taken
is that Meson users (and Meson itself) shall have no knowledge of the
libc internals and whether libssp is required. instead, libc's should
declare a dependency on the generic libssp on their own by means of
.spec files [2].
Following the discussion in Meson Github, the issue was then fixed in
mingw-w64 upstream [3].
References:
* https://github.com/mesonbuild/meson/issues/10673
* https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html
* https://github.com/msys2/MINGW-packages/issues/13401
