Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • 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
  • #17041

Closed (moved)
(moved)
Open
Created Sep 11, 2015 by David Goulet@dgoulet🆘

Memory corruption in the HS client

This is in git master and hasn't been released.

Here is how the bug is triggered. You download a descriptor of a valid HS. Then restart that HS (thus making the current descriptor obsolete) and retry right away to download the descriptor for that HS. The tor client stops with a segfault in malloc() (you sometime need couple of tries to trigger the issue).

Now I believe this is a memory corruption of some sort since during the git bisect, I was able to trigger bad free() and other segfaults with tor_memcmp() in some other non related functions with the same usecase. Bisect gave me this commit as the first bad commit:

commit ab9a0e340728abd96128da726f67b4ccca10ba52
Author: David Goulet <dgoulet@ev0ke.net>
Date:   Thu Jun 18 16:09:18 2015 -0400

    Add rend failure cache
[...]

That precise commit introduces a memory corruption somewhere somehow, I can't find it for now so I'm filling this ticket. Attached is a debug log (3.3M) of the issue being triggered. It's also quite easy to run tor in gdb and catch the issue.

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