Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

executor: fix cover_protect() on FreeBSD #5799

Merged
merged 1 commit into from
Feb 21, 2025
Merged

Conversation

markjdb
Copy link
Collaborator

@markjdb markjdb commented Feb 18, 2025

I think the OpenBSD version has the same problem, but didn't want to modify it as I'm not set up to test. Perhaps @blackgnezdo can confirm?

a-nogikh
a-nogikh previously approved these changes Feb 21, 2025
Copy link
Collaborator

@a-nogikh a-nogikh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

During machine checks, syzkaller will execute calls with coverage
disabled, in which case per-thread coverage structures are zeroed out.
write_output() will temporarily map the coverage data as writeable via
CoverAccessScope, whether or not cover is enabled.  In effect,
write_output() may trigger a call mprotect(0, kCoverSize, PROT_RW).

On FreeBSD, mprotect() silently ignores unmapped regions, so this does
not result in an error.  In fact, kCoverSize is now large enough that
this ends up removing the eXecute bit from part of syz-executor's text
region.

Make CoverAccessScope a no-op if coverage is not enabled.  Modify BSD
cover_protect() and cover_unprotect() to fail if invoked when coverage
is disabled.
@a-nogikh a-nogikh enabled auto-merge February 21, 2025 17:18
@a-nogikh a-nogikh added this pull request to the merge queue Feb 21, 2025
Merged via the queue into google:master with commit d34966d Feb 21, 2025
17 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants