-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
sys/openbsd: avoid using BIOCSETIF in causes "tun: read failed" #5016
base: master
Are you sure you want to change the base?
Conversation
With luck this should prevent killing the executors with https://syzkaller.appspot.com/bug?extid=682dad6055938e287d19
if request.Val == arch.BIOCSETIF { | ||
// Ideally this should also check Args[2] against "tap" as | ||
// we only want to prevent the following from happening: | ||
// ioctl$BIOCSETIF(-1, 0x8020426c, &(0x...)={'tap', 0x0}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dvyukov could you recommend the incantation to tighten this check?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you interested in how exactly you could check for the tap
string in the third argument or something more general, e.g. if there are other ways to restrict it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just want this ioctl to not happen to tap
interfaces because we rely on them working for packet injection.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAIK there's currently to code that does something similar enough to this, but we could try to construct it from pieces.
- Cast
c.Args[2]
to*prog.PointerArg
. Let it beptrArg
. - Cast
ptrArg.Res
to*prog.GroupArg
. Let it begroupArg
. - Cast
groupArg.Inner[0]
to*prog.DataArg
. Let it bedataArg
. - Verify
dataArg.Data()
and patch it, if necessary. Like here:
Lines 241 to 253 in 32fcf98
dataArg, ok := unionArg.Option.(*prog.DataArg) | |
if !ok { | |
return | |
} | |
if dataArg.Dir() == prog.DirOut { | |
return | |
} | |
// Clear the first 16 bytes to prevent overcoming the limitation by squashing the struct. | |
data := append([]byte{}, dataArg.Data()...) | |
for i := 0; i < 16 && i < len(data); i++ { | |
data[i] = 0 | |
} | |
dataArg.SetData(data) |
One this to watch out for are ANY
types -- in that case, syzkaller has squahed the whole struct into one binary blob. We cannot really build a good tight sanity check in that case, so I think we can check for ANY
and boldly patch it like you've already done it in this PR.
Here's an example of a check for ANY. You can do it for c.Args[2]
.
syzkaller/sys/linux/init_vusb.go
Lines 61 to 63 in 32fcf98
if g.Target().ArgContainsAny(arg) { | |
return | |
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your guidance.
I implemented 1-4 but I'm not sure where to get a *prog.Gen
to call .Target
on.
Also not sure if there's an easy way to test this without pushing it to prod :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also not sure if there's an easy way to test this without pushing it to prod :)
We do have quite a lot of tests for call sanitization in Linux: https://github.com/google/syzkaller/blob/master/sys/linux/init_test.go
I'm not sure where to get a *prog.Gen to call .Target on.
At the very least we could remember it in the struct arch {}
-- the prog.Target
pointer is passed to InitTarget
.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files
|
I stared at https://syzkaller.appspot.com/bug?extid=682dad6055938e287d19 a bit more and came to the conclusion that I may not even be chasing the right problem. The last syz repro was from 2024/02/27. If it is the right problem, then this PR effectively turns off this directive:
If I wanted to do this I might as well remove this line completely, right? |
Yes, that should also work fine if syzkaller is unlikely to guess the |
With luck this should prevent killing the executors with https://syzkaller.appspot.com/bug?extid=682dad6055938e287d19