Hacker News Reader

Comment by tremon | Hacker News Reader

> While the vulnerability was found by code auditing, it was also detected once by https://syzkaller.appspot.com/bug?id=a53b68e5178eec469534aca..., however not with a reproducible C code.

This made me pause. I had naively assumed (well, actually, never thought about it) that fuzzing would always expose a clear and obvious error path, but apparently there's a lot of manual digging required to find the error mode?

View on HN

It depends on the bug. syzkaller does an excellent job finding race conditions, but it can be difficult to generate a reliable reproducer for them. It often succeeds nonetheless. In other cases there can be a wide gap between the proximate and root causes of a crash. For instance some system call bug might corrupt memory in a way that only results in a crash some time later, when some asynchronous task runs, in which case it's also difficult to find a reproducer. Sanitizers can help identify such bugs earlier and so reduce the amount of manual analysis needed in the absence of a reproducer.

I'm not sure what happened in this case. The linked report does indeed have an associated reproducer.

Perhaps the difference between merely observing a crash while fuzzing and being able to exploit it for RCE or whatever?

Did this line get removed from the blog post?

Sorry, it's from [0] linked further down in the comments. I didn't notice that when posting, or I would have made my comment a reply to that post [1].

[0] https://github.com/google/security-research/security/advisor...

[1] https://news.ycombinator.com/item?id=27842381

Reply on news.ycombinator.com