vm_map.c: plug several more places which might modify entry->offset

[kib]

Summary

for the GUARD entries protecting stacks gaps.

syzkaller: https://syzkaller.appspot.com/bug?extid=c325d6a75e4fd0a68714

[dougm]

sys/vm/vm_map.c

1418

Have you tested this change with INVARIANTS set?

It seems that if you don't change root->offset, then you'll have two elements overlap, and that will violate invariants.

[kib]

sys/vm/vm_map.c

1418

Peter is doing the full test right now. offset is overloaded for stack gap entries, this is the main point of the change.

Are you saying that overloading entry->offset cannot work in principle?

[dougm]

sys/vm/vm_map.c

1418

No, I'm not saying that. I withdraw my question.

Where is the overloading of entry->offset documented?

[kib]

sys/vm/vm_map.c

1418

The comment above the struct vm_map_entry definition in vm_map.h, and duplicated in vm_map_stack_locked() in the KERN_SUCCESS branch of the last if().

[markj]

Does the second loop in vm_map_sync() also need a check for stack guards?

[kib]

In D41475#944878, @markj wrote:

Does the second loop in vm_map_sync() also need a check for stack guards?

vm_object_reference()/dereference()/sync() all accept and do nothing if passed obj is NULL.

[dougm]

sys/vm/vm_map.c

1466

Do you need a check here?

[kib]

sys/vm/vm_map.c

1466

I do not believe so because stack guards are not merge-able. I can add assert.