1. 25 Feb, 2021 5 commits
  2. 24 Feb, 2021 3 commits
  3. 23 Feb, 2021 6 commits
  4. 21 Feb, 2021 5 commits
  5. 20 Feb, 2021 2 commits
  6. 14 Feb, 2021 1 commit
  7. 13 Feb, 2021 1 commit
    • Uli Schlachter's avatar
      Fix a memory leak with cairo_tag_begin() + pdf · ac616c27
      Uli Schlachter authored
      The error paths in _cairo_pdf_interchange_begin_dest_tag() do not clean
      up and cause some memory to be leaked. Fix this by adding the necessary
      The first hunk, the missing free(dest) was found by oss-fuzz (see link
      The second hunk is an obvious follow up. It also cleans up the memory
      allocated by _cairo_tag_parse_dest_attributes().
      The cleanup in the second hunk is similar to the function
      _named_dest_pluck() in the same function, but that function also removes
      the entry from a hash table.  The error case here is that exactly this
      hash table insertion failed.  Thus, the code cannot simply use the
      already existing function.
      Fixes: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=30880
      Signed-off-by: Uli Schlachter's avatarUli Schlachter <psychon@znc.in>
  8. 11 Feb, 2021 2 commits
  9. 09 Feb, 2021 1 commit
    • Uli Schlachter's avatar
      pdf font subset: Generate valid font names · a3b69a02
      Uli Schlachter authored
      A hash value is encoded in base 26 with upper case letters for font
      Commit ed984146 replaced "numerator = abs (hash);" with "numerator =
      hash;" in this code, because hash has type uint32_t and the compiler
      warned about taking the absolute value of an unsigned value.  However,
      abs() is actually defined to take an int argument. Thus, there was some
      implicit cast.
      Since numerator has type long, i.e. is signed, it is now actually
      possible to get an overflow in the implicit cast and then have a
      negative number. The following code is not prepared for this and
      produces non-letters when encoding the hash.
      This commit fixes that problem by not using ldiv() and instead using /
      and % to directly compute the needed values. This gets rid of the need
      to convert to type long. Since now everything works with uint32_t, there
      is no more chance for negative numbers messing things up.
      Fixes: #449
      Signed-off-by: Uli Schlac...
  10. 06 Feb, 2021 1 commit
  11. 05 Feb, 2021 1 commit
  12. 04 Feb, 2021 1 commit
  13. 03 Feb, 2021 1 commit
  14. 30 Jan, 2021 1 commit
    • Matthias Clasen's avatar
      recording-surface: Fix offset error · d07fb410
      Matthias Clasen authored
      When a recording surface with non-zero origin is
      saved to a png file, it gets cut off. Fix this by
      setting a device offset when acquiring the source
  15. 22 Jan, 2021 4 commits
    • Uli Schlachter's avatar
      Merge branch 'fill-use-after-free' into 'master' · 48194cf0
      Uli Schlachter authored
      Avoid use after free in cairo_fill
      See merge request cairo/cairo!116
    • Uli Schlachter's avatar
      Merge branch 'set-source-surface-leak' into 'master' · ee90ce59
      Uli Schlachter authored
      Plug a memory leak in an error case
      See merge request cairo/cairo!115
    • Matthias Clasen's avatar
      Avoid a use-after-free · b345be5a
      Matthias Clasen authored
      asan was complaining that the limits struct goes out
      of scope before it is used via the pointer in the polygon struct,
      and it is right:
      ==386746==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7ffd3ccebdfc at pc 0x7f783d5eaaee bp 0x7ffd3cceba80 sp 0x7ffd3cceba70
      READ of size 4 at 0x7ffd3ccebdfc thread T0
          #0 0x7f783d5eaaed in _add_clipped_edge ../src/cairo-polygon.c:351
          #1 0x7f783d5ebba3 in _cairo_polygon_add_edge ../src/cairo-polygon.c:520
          #2 0x7f783d5ebc82 in _cairo_polygon_add_external_edge ../src/cairo-polygon.c:530
          #3 0x7f783d582149 in _cairo_filler_line_to ../src/cairo-path-fill.c:63
          #4 0x7f783d588d9c in _cairo_path_fixed_interpret ../src/cairo-path-fixed.c:831
          #5 0x7f783d582a44 in _cairo_path_fixed_fill_to_polygon ../src/cairo-path-fill.c:147
          #6 0x7f783d6204fe in _cairo_spans_compositor_fill ../src/cairo-spans-compositor.c:1151
          #7 0x7f783d5126de in _cairo_compositor_fill ../src/cairo-compositor.c:203
          #8 0x7f783d5571f9 in _cairo_image_surface_fill ../src/cairo-image-surface.c:1003
          #9 0x7f783d647f2f in _cairo_surface_fill ../src/cairo-surface.c:2424
          #10 0x7f783d52ebea in _cairo_gstate_fill ../src/cairo-gstate.c:1312
          #11 0x7f783d51cca4 in _cairo_default_context_fill ../src/cairo-default-context.c:1057
          #12 0x7f783d6812d6 in cairo_fill ../src/cairo.c:2421
    • Matthias Clasen's avatar
      Plug a memory leak in an error case · 36f5dee4
      Matthias Clasen authored
      GTK has a testcase that tests the error when creating
      an oversize image, and asan tells me that it triggers
      a memory leak in cairo:
      Direct leak of 160 byte(s) in 1 object(s) allocated from:
          #0 0x7f1122755667 in __interceptor_malloc (/lib64/libasan.so.6+0xb0667)
          #1 0x7f1120cc83e8 in _cairo_pattern_create_solid ../src/cairo-pattern.c:607
          #2 0x7f1120cc8487 in _cairo_pattern_create_in_error ../src/cairo-pattern.c:630
          #3 0x7f1120cc87cb in INT_cairo_pattern_create_for_surface ../src/cairo-pattern.c:736
          #4 0x7f1120c1f1c7 in _cairo_default_context_set_source_surface ../src/cairo-default-context.c:327
          #5 0x7f1120d8386a in INT_cairo_set_source_surface ../src/cairo.c:982
          #6 0x7f1121d005a2 in gdk_cairo_set_source_pixbuf ../gdk/gdkcairo.c:234
          #7 0x401427 in test_set_source_big_pixbuf ../testsuite/gdk/cairo.c:23
  16. 21 Jan, 2021 1 commit
  17. 19 Jan, 2021 4 commits