Skip to content
GitLab
  1. 05 Jul, 2017 3 commits
  3. 27 Jun, 2017 2 commits
  5. 12 Jun, 2017 3 commits
  7. 09 Jun, 2017 3 commits
    • Florent Rougon's avatar
      Fix erroneous test on language id in FcLangSetPromote() · 209619b1
      Florent Rougon authored and Akira TAGOH's avatar Akira TAGOH committed 
      FcLangSetIndex() indicates "not found" with a non-negative return value.
Return value 0 doesn't imply "not found", it rather means "language
found at index 0 in fcLangCharSets".
      209619b1
    • Florent Rougon's avatar
      Fix an off-by-one error in FcLangSetIndex() · 4970c7e8
      Florent Rougon authored and Akira TAGOH's avatar Akira TAGOH committed 
      This commit fixes a bug that can be reproduced like this:
  - remove all languages starting with 'a' in fc-lang/Makefile.am (in
    ORTH's definition);
  - rebuild fontconfig with this change (-> new fc-lang/fclang.h);
  - create an FcLangSet 'ls1' that contains at least the first language
    from fcLangCharSets (i.e., the first *remaining* in lexicographic
    order); let's assume it is "ba" for the sake of this description;
  - create an FcLangSet 'ls2' that only contains the language "aa" (any
    language starting with 'a' should work as well);
  - check the return value of FcLangSetContains(ls1, ls2);

The expected return value is FcFalse, however it is FcTrue if you use
the code before this commit.

What happens is that FcLangSetIndex() returns 0, because this is the
index of the first slot after the not-found language "aa" in
fcLangCharSets (since we removed all languages starting with 'a').
However, this index happens to be non-negative, therefore
FcLangSetContainsLang() mistakenly infers that the language "aa" was
found in fcLangCharSets, and thus calls FcLangSetBitGet(ls1, 0), which
returns FcTrue since we've put the first remaining language "ba" in the
'ls1' language set.

The "return -low;" statement previously in FcLangSetIndex() was
inconsistent with the final return statement. "return -(low+1);" fixes
this inconsistency as well as the incorrect behavior described above.
      4970c7e8
    • Florent Rougon's avatar
      fc-lang: gracefully handle the case where the last language initial is < 'z' · 02161ef2
      Florent Rougon authored and Akira TAGOH's avatar Akira TAGOH committed 
      FcLangSetIndex() contains code like this:

  low = fcLangCharSetRanges[firstChar - 'a'].begin;
  high = fcLangCharSetRanges[firstChar - 'a'].end;
  /* no matches */
  if (low > high)

The assumption behind this test didn't hold before this commit, unless
there is at least one language name that starts with 'z' (which is
thankfully the case in our world :-). If the last language name in
lexicographic order starts for instance with 'x', this change ensures
that fcLangCharSetRanges['y' - 'a'].begin and
     fcLangCharSetRanges['z' - 'a'].begin
are equal to NUM_LANG_CHAR_SET, in order to make the above assumption
correct in all cases.
      02161ef2
  9. 07 Jun, 2017 1 commit
    • Florent Rougon's avatar
      FcCharSetHash(): use the 'numbers' values to compute the hash · c37eeb8f
      Florent Rougon authored and Akira TAGOH's avatar Akira TAGOH committed 
      Before this commit, FcCharSetHash() repeatedly used the address of the
'numbers' array of an FcCharSet to compute the FcCharSet hash, instead
of the value of each array element. This is not good for even spreading
of the FcCharSet objects among the various buckets of the hash table
(and should thus reduce performance). This bug appears to have been
mistakenly introduced in commit
cd2ec1a9 (June 2005).
      c37eeb8f
  11. 05 Jun, 2017 1 commit
  13. 03 Jun, 2017 1 commit
  15. 01 Jun, 2017 2 commits
  17. 31 May, 2017 5 commits
  19. 24 Mar, 2017 1 commit
  21. 21 Mar, 2017 1 commit
  23. 01 Mar, 2017 1 commit
  25. 23 Feb, 2017 1 commit
    • Akira TAGOH's avatar
      Fix the build issue with gperf 3.1 · 9878b306
      Akira TAGOH authored 
      To support the one of changes in gperf 3.1:
* The 'len' parameter of the hash function and of the lookup function is now
  of type 'size_t' instead of 'unsigned int'. This makes it safe to call these
  functions with strings of length > 4 GB, on 64-bit machines.
      9878b306
  27. 20 Dec, 2016 1 commit
  29. 14 Nov, 2016 1 commit
    • Akira TAGOH's avatar
      Fix FcCacheOffsetsValid() · 0e9b2a15
      Akira TAGOH authored 
      Validation fails when the FcValueList contains more than font->num.
this logic was wrong because font->num contains a number of the elements
in FcPatternElt but FcValue in FcValueList.

This corrects 7a4a5bd7.

Patch from Tobias Stoeckmann
      0e9b2a15
  31. 23 Sep, 2016 1 commit
  33. 16 Sep, 2016 1 commit
  35. 07 Sep, 2016 1 commit
  37. 15 Aug, 2016 1 commit
  39. 05 Aug, 2016 3 commits
    • Akira TAGOH's avatar
      Bump version to 2.12.1 · 6b222c52
      Akira TAGOH authored
      6b222c52
    • Akira TAGOH's avatar
      Update libtool revision · 68869149
      Akira TAGOH authored
      68869149
    • Tobias Stoeckmann's avatar
      Properly validate offsets in cache files. · 7a4a5bd7
      Tobias Stoeckmann authored and Akira TAGOH's avatar Akira TAGOH committed 
      

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>
      7a4a5bd7
  41. 08 Jul, 2016 3 commits
  43. 23 Jun, 2016 2 commits
  45. 15 Jun, 2016 1 commit