Skip to content
Snippets Groups Projects
  1. Aug 01, 2024
  2. Jul 19, 2024
  3. Jul 01, 2024
    • José Expósito's avatar
      stubs/atom.c: Fix memory leak in __libxfont_internal__MakeAtom · 00067372
      José Expósito authored
      Reported by a static analysis tool:
      
           9. libXfont2-2.0.6/src/stubs/atom.c:179:5:
              alloc_fn: Storage is returned from allocation function "malloc".
          10. libXfont2-2.0.6/src/stubs/atom.c:179:5:
              var_assign: Assigning: "a" = storage returned from
              "malloc(24UL + len + 1UL)".
          16. libXfont2-2.0.6/src/stubs/atom.c:194:6:
              leaked_storage: Variable "a" going out of scope leaks the
              storage it points to.
          #   192|  if ((ResizeHashTable() == FALSE) &&
          #   193|     ((hashTable == NULL) || (hashUsed == hashSize)))
          #   194|-> 	 return None;
          #   195|  h = hash & hashMask;
          #   196|  if (hashTable[h]) {
      
      Fixes: 78085e6b ("stubs/atom.c: check for ResizeHashTable failure")
      Part-of: <xorg/lib/libxfont!27>
      00067372
  4. Feb 17, 2024
  5. Feb 03, 2024
  6. Jan 25, 2024
  7. Mar 25, 2023
  8. Mar 04, 2023
  9. Feb 25, 2023
  10. Feb 17, 2023
  11. Nov 27, 2022
  12. Nov 10, 2022
    • Peter Harris's avatar
      Fix font server reconnection timeout · 5ca90ec8
      Peter Harris authored and Alan Coopersmith's avatar Alan Coopersmith committed
      
      The great libxfont2 rewrite 135fb032 split
      fs_wakeup into fs_wakeup and fs_fd_handler. The fs_fd_handler side is
      called when there is new data on the socket. The fs_wakeup side is called
      on a timeout.
      
      If there's a connection timeout, the block handler will set the timeout
      to zero, expecting fs_wakeup to handle the timeout. Therefore, we need to
      call _fs_check_reconnect in fs_wakeup to handle the connection timeout.
      If we don't, the X server will go to 100% CPU (and the font server
      connection will not be retried).
      
      Signed-off-by: default avatarPeter Harris <pharris@opentext.com>
      5ca90ec8
  13. Nov 05, 2022
  14. Oct 06, 2022
  15. Aug 26, 2022
  16. Aug 11, 2022
  17. Jun 22, 2022
  18. Jun 21, 2022
  19. Jun 20, 2022
  20. Apr 06, 2022
  21. Aug 02, 2021
  22. Jul 14, 2021
    • Alexander Richardson's avatar
      Fix out-of-bounds read in FontFileMakeDir() · daff8876
      Alexander Richardson authored
      BuiltinReadDirectory() calls FontFileMakeDir ("", builtin_dir_count); and
      this causes the `dirName[dirlen - 1]` access to read before the start of
      the string. I found this while porting Xvnc to CHERI-RISC-V (which has
      bounds and permissions on all pointers).
      daff8876
  23. Jun 12, 2021
  24. Mar 02, 2021
    • Peter Harris's avatar
      Fix use after free when font server connection lost · 9529d235
      Peter Harris authored
      
      If there are multiple blocks waiting for the same font, only one of them
      will have ->freeFont set. The rest will be in a state of FS_DEPENDING.
      
      If the font server dies before the font finishes opening, the block with
      ->freeFont set will call ->unload_font, invalidating the pfont pointers
      in the remaining FS_DEPENDING blocks.
      
      Avoid a use after free (and potential crash) by passing conn to
      fs_cleanup_font instead of dereferencing pfont to find the conn.
      
      Signed-off-by: default avatarPeter Harris <pharris@opentext.com>
      9529d235
  25. Mar 06, 2020
    • Peter Harris's avatar
      Fix crash when font server connection lost · e7b2cae1
      Peter Harris authored
      
      Always initialize the return value of fs_new_block_rec. Even if the
      conn->blockState is FS_BROKEN_CONNECTION | FS_RECONNECTING, we must not
      return with an uninitialized blockrec on the block list. When the
      blockrec times out, _fs_clean_aborted_blockrec calls fs_cleanup_bfont,
      which will try to follow pointers in the blockrec (which has not been
      initialized).
      
      Signed-off-by: default avatarPeter Harris <pharris@opentext.com>
      e7b2cae1
  26. Oct 25, 2019
  27. Sep 16, 2019
  28. Sep 14, 2019
  29. Aug 17, 2019
Loading