Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Trac Trac
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Service Desk
    • Milestones
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
  • Wiki
    • Wiki
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar
  • Legacy
  • TracTrac
  • Issues
  • #30561
Closed (moved) (moved)
Open
Created May 21, 2019 by Trac@tracbot

Fixed tor_vasprintf on systems without vasprintf.

If tor is compiled on a system with neither vasprintf nor _vscprintf, the fallback implementation exposes a logic flaw which prevents proper usage of strings longer than 127 characters:

  • tor_vsnprintf returns -1 if supplied buffer is not large enough, but tor_vasprintf uses this function to retrieve required length
  • the result of tor_vsnprintf is not properly checked for negative return values

Both aspects together could in theory lead to exposure of uninitialized stack memory in the resulting string. This requires an invalid format string or data that exceeds integer limitations.

Fortunately tor is not even able to run with this implementation because it runs into asserts early on during startup. Also the unit tests fail during a "make check" run.

At this point it would make sense to check if support for these systems is still a desired option. It seems that nobody noticed lack of support for at least a year.

Trac:
Username: paldium

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking