sys/linux: sanitize mount()

[a-nogikh]

Context: https://lore.kernel.org/all/[email protected]/T/

---

If an ext* superblock has a "panic on error" bit set, we may end up with a kernel crash unless it was prohibited via mount options.

For syz_mount_image(), we do ensure that mount options prevent this from happening.

Perform similar sanitization also for plain mount() calls.

[codecov]

Codecov Report

Merging #4143 (4fdba27) into master (d216d8a) will decrease coverage by 4.0%.
The diff coverage is 63.6%.

Files Changed	Coverage Δ
sys/linux/init.go	60.7% <63.6%> (ø)

... and 219 files with indirect coverage changes

[dvyukov]

We do it here:
https://github.com/google/syzkaller/blob/master/executor/common_linux.h#L3044-L3056
because fuzzer generally can't guarantee contents of data in memory (can overlap with other arguments, or be overwritten by concurrent syscall args/results).

[a-nogikh]

Yes, we do sanitize syz_mount_image, but not mount directly, which we also have in the descriptions.

[a-nogikh]

• Use type from the pointer when creating the argument.
• Ensure it's working fine with any types: mutate mount in loop and sanitize it?

[a-nogikh]

We need to refactor the whole call neutralization. It's easy to patch integer values, but to deal with strings/arrays, we need to (re-)allocate memory if the new string size is bigger than the old one.

To perform that, we need a pointer to prog.Prog. And, probably, actually do the sanitization not for individual calls, but for the whole prog itself (at least on the interface level, in the implementation we will of course continue doing it call-by-call) - otherwise by adjusting memory allocations for every call we open the door to many non-obvious bugs.

Also (since we are there anyway), now that we do not sanitize file images, we do not need a distinction between sanitize() and sanitizeFix().

[tarasmadan]

@a-nogikh can we close it?

[a-nogikh]

No, we still have the problem.