1. 05 Aug, 2016 3 commits
    • Akira TAGOH's avatar
      Bump version to 2.12.1 · 6b222c52
      Akira TAGOH authored
    • Akira TAGOH's avatar
      Update libtool revision · 68869149
      Akira TAGOH authored
    • Tobias Stoeckmann's avatar
      Properly validate offsets in cache files. · 7a4a5bd7
      Tobias Stoeckmann authored
      The cache files are insufficiently validated. Even though the magic
      number at the beginning of the file as well as time stamps are checked,
      it is not verified if contained offsets are in legal ranges or are
      even pointers.
      The lack of validation allows an attacker to trigger arbitrary free()
      calls, which in turn allows double free attacks and therefore arbitrary
      code execution. Due to the conversion from offsets into pointers through
      macros, this even allows to circumvent ASLR protections.
      This attack vector allows privilege escalation when used with setuid
      binaries like fbterm. A user can create ~/.fonts or any other
      system-defined user-private font directory, run fc-cache and adjust
      cache files in ~/.cache/fontconfig. The execution of setuid binaries will
      scan these files and therefore are prone to attacks.
      If it's not about code execution, an endless loop can be created by
      letting linked lists become circular linked lists.
      This patch verifies that:
      - The file is not larger than the maximum addressable space, which
        basically only affects 32 bit systems. This allows out of boundary
        access into unallocated memory.
      - Offsets are always positive or zero
      - Offsets do not point outside file boundaries
      - No pointers are allowed in cache files, every "pointer or offset"
        field must be an offset or NULL
      - Iterating linked lists must not take longer than the amount of elements
        specified. A violation of this rule can break a possible endless loop.
      If one or more of these points are violated, the cache is recreated.
      This is current behaviour.
      Even though this patch fixes many issues, the use of mmap() shall be
      forbidden in setuid binaries. It is impossible to guarantee with these
      checks that a malicious user does not change cache files after
      verification. This should be handled in a different patch.
      Signed-off-by: Tobias Stoeckmann's avatarTobias Stoeckmann <tobias@stoeckmann.org>
  2. 08 Jul, 2016 3 commits
  3. 23 Jun, 2016 2 commits
  4. 15 Jun, 2016 2 commits
  5. 09 Jun, 2016 1 commit
  6. 30 May, 2016 1 commit
  7. 27 May, 2016 1 commit
  8. 26 May, 2016 1 commit
  9. 25 May, 2016 1 commit
  10. 23 May, 2016 1 commit
  11. 19 May, 2016 1 commit
  12. 07 Apr, 2016 2 commits
  13. 06 Apr, 2016 3 commits
  14. 09 Mar, 2016 2 commits
  15. 08 Mar, 2016 3 commits
  16. 12 Jan, 2016 1 commit
    • Patrick Haller's avatar
      Optimizations in FcStrSet · d570a841
      Patrick Haller authored
      Applied optimizations:
      - skip duplicate check in FcStrSetAppend for values originating from readdir()
      - grow FcStrSet in 64-element bulks for local FcStrSets (FcConfig layout unaltered)
      Starting gedit is measured to
                              Unoptimized     Optimized
      user[s]                         0,806         0,579
      sys[s]                          0,062         0,062
      Total Instr Fetch Cost: 1.658.683.750   895.069.820
      Cachegrind D Refs:        513.917.619   312.000.436
      Cachegrind Dl Misses:       8.605.632     4.954.639
  17. 02 Dec, 2015 1 commit
  18. 25 Nov, 2015 1 commit
  19. 24 Nov, 2015 1 commit
  20. 18 Nov, 2015 1 commit
  21. 16 Oct, 2015 1 commit
  22. 15 Oct, 2015 2 commits
  23. 13 Oct, 2015 2 commits
  24. 17 Aug, 2015 1 commit
  25. 14 Aug, 2015 1 commit
  26. 27 Jun, 2015 1 commit
    • Behdad Esfahbod's avatar
      Revert changes made to FcConfigAppFontAddDir() recently · 46ec6a52
      Behdad Esfahbod authored
      In 32ac7c75 the behavior of
      FcConfigAppFontAddFile/Dir() were changed to return false
      if not fonts were found.  While this is welldefined and useful
      for AddFile(), it's quite problematic for AddDir().  For example,
      if the directory is empty, is that a failure or success?  Worse,
      the false value from AddDir() was being propagated all the way
      to FcInit() returning false now.  This only happened upon memory
      allocation failure before, and some clients assert that FcInit()
      is successful.
      With this change, AddDir() is reverted back to what it was.
      AddFont() change (which was actually in fcdir.c) from the original
      commit is left in.