Opened 8 months ago

Last modified 3 months ago

#21996 new defect

Should we treat BUG messages as fatal errors during fuzzing?

Reported by: Sebastian Owned by:
Priority: Medium Milestone: Tor: 0.3.3.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: 031-deferred-20170425
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

While wondering why #21966 wasn't caught during consdiff code fuzzing, I noticed that in the C implementation failing to apply a generated diff is not a reason to assert, but rather an LD_BUG log message is generated. Unapplying the 21966 fix and fuzzing promptly leads to the discovery of that bug. I think it might make sense to ensure any BUG message that gets triggered fails an assertion if we're currently fuzzing?

Child Tickets

Change History (6)

comment:1 Changed 8 months ago by asn

That seems smart to me, if it doesn't require a huge code change.

comment:2 Changed 8 months ago by nickm

This could be a good idea, if we go through all the cases where there are BUG warnings and make sure that they are really supposed to be untriggerable on arbitrary inputs.

(I think that some places, we might do something like BUGing an attempt to compute a diff between things with a ".")

comment:3 Changed 8 months ago by Sebastian

I meant it more generally possibly, like asserting in log_fn_ if we're running under fuzzing and trigger an LD_BUG message (as well as fixing all cases where we're triggering a BUG message through fuzzing)

comment:4 Changed 8 months ago by teor

We might also want to do this in the unit tests, once we've removed all the BUG() messages in them. And maybe using chutney as well.

comment:5 Changed 8 months ago by nickm

Keywords: 031-deferred-20170425 added
Milestone: Tor: 0.3.1.x-finalTor: 0.3.2.x-final

Triage: batch-defer unowned items of priority Medium or lower to 0.3.2.

comment:6 Changed 3 months ago by nickm

Milestone: Tor: 0.3.2.x-finalTor: 0.3.3.x-final
Note: See TracTickets for help on using tickets.