Open Bug 1850021 Opened 10 months ago Updated 3 days ago

Fuzzing ASan builds shouldn't be NS_FREE_PERMANENT_DATA

Categories

(Core :: Fuzzing, task)

task

Tracking

()

People

(Reporter: mccr8, Unassigned)

References

(Blocks 1 open bug)

Details

We get the occasional security bug filed by an external reporter about a issue that happens after the ContentChild::ActorDestroy QuickExit, which should not be exploitable in opt builds. It would be nice if we could avoid these to reduce bug reporter frustration.

Currently we make ASan builds NS_FREE_PERMANENT_DATA because we use them for LeakSanitizer, but fuzzing ASan builds are not being used for leak checking (because we already have more test cases for leaks than we're able to fix...), so we should probably not use NS_FREE_PERMANENT_DATA for them. The builds already have to be separate because they define FUZZING so this shouldn't be hard. Maybe we could be smarter and specifically check if LSan is running but there's probably no need to get that fancy.

I was talking to jkratzer about this, and it sounds like when fuzzing a test case gets opened in a new tab and only runs for like 30 seconds, so in addition to reducing reports that aren't very useful, it should also make fuzzing a little faster.

One concern that Jason raised is that we might miss some issues that only show up after the shutdown GC/CC, because they don't always do that themselves while fuzzing. It might be interesting to look back at fuzzing bugs with ASan reports to see how many have XPCOM shutdown or whatever in the stack, which should be doable with a careful bugzilla search.

The idea would be to change the defined(MOZ_ASAN) clause for the definition of NS_FREE_PERMANENT_DATA to be more like (defined(MOZ_ASAN) && !defined(FUZZING)).

I did a search, and I only found a total of 4 sec-high bugs filed by one of our people doing browser fuzzing with ShutdownCollect in the first comment (including bug 1480179, bug 1769739, bug 1798494) so maybe it isn't a super big deal. There are also a few sec-moderates like that, though hard to say if they were really sec-moderate or not.

Blocks: 1870765
See Also: → 1190479
You need to log in before you can comment on or make changes to this bug.