pkg/csource: sandbox="" causes false positives

[dvyukov]

There are at least 2 known false positives with sandbox="":

1. Test process can kill init causing kernel panic.
2. Test process can shutdown network causing connection loss.

sandbox=none does not have these problems as it unshares most namespaces. To prevent this we need at least CLONE_NEWNET and CLONE_NEWPID. Two options:

1. Drop sandbox="" and just use sandbox=none.
2. Do at least some minimal sandboxing even with sandbox="" (note: CLONE_NEWPID also requires fork, so it won't be just 2 unshare calls, and will be closer to what we do for sandbox=none anyway).

[dvyukov]

FTR, program that causes connection loss:

#{Threaded:false Collide:false Repeat:true Procs:1 Sandbox: Fault:false FaultCall:-1 FaultNth:0 EnableTun:false UseTmpDir:true HandleSegv:false WaitRepeat:true Debug:false Repro:false}
mmap(&(0x7f0000000000/0xfff000)=nil, 0xfff000, 0x3, 0x32, 0xffffffffffffffff, 0x0)
mkdir(&(0x7f0000632000)='./file0\x00', 0x0)
mount(&(0x7f000000a000)='./file1\x00', &(0x7f0000fd2000-0x8)='./file0\x00', &(0x7f0000014000)='proc\x00', 0x0, &(0x7f0000fd1000)="")
r0 = socket$netlink(0x10, 0x3, 0xc)
sendmsg$netlink(r0, &(0x7f0000109000-0x38)={0x0, 0x0, &(0x7f0000c8e000)=[{&(0x7f0000009000-0x1118)=[{0x10, 0x10, 0x0, 0x0, 0x0, ""}], 0x3cdb}], 0x1, 0x0, 0x0, 0x0}, 0x0)

[dvyukov]

And this one causes "kernel panic: Attempted to kill init!":

#{"repeat":true,"procs":1,"sandbox":"","fault_call":-1,"waitrepeat":true}
r0 = inotify_init1(0x0)
fcntl$setown(r0, 0x8, 0xffffffffffffffff)
fcntl$getownex(r0, 0x10, &(0x7f000045fff8)={0x0, <r1=>0x0})
ptrace$setopts(0x4206, r1, 0x0, 0x0)
ptrace(0x4207, r1)
ptrace$cont(0x20, r1, 0x0, 0x0)
r2 = socket$key(0xf, 0x3, 0x2)
sendmsg$key(r2, &(0x7f0000f56000)={0x0, 0x0, &(0x7f00008feff0)={&(0x7f0000000040)={0x2, 0x3, 0x0, 0x9, 0x10, 0x0, 0x0, 0x0, [@sadb_x_sa2={0x2, 0x13, 0x2}, @sadb_address={0x5, 0x6, 0x0, 0x0, 0x0, @in6={0xa}}, @sadb_sa={0x2, 0x1, 0x0, 0x0, 0x0, 0x0, 0x2}, @sadb_address={0x5, 0x5, 0x0, 0x0, 0x0, @in6={0xa, 0x0, 0x0, @mcast1={0xff, 0x1, [], 0x1}}}]}, 0x80}, 0x1}, 0x0)

[dvyukov]

Another case where removing sandboxing causes problems (presumably):
INFO: task hung in fuse_simple_request
https://groups.google.com/g/syzkaller-bugs/c/zFlW0iSR7vs/m/BjtpQh5HBQAJ

The reproducer is:

# https://syzkaller.appspot.com/bug?id=5b958512cfd271399fd6c2f6cd9817279098103b
# See https://goo.gl/kgGztJ for information about syzkaller reproducers.
#{"threaded":true,"repeat":true,"procs":6,"slowdown":1,"sandbox":"none","fault_call":-1,"close_fds":true}
mkdir(&(0x7f0000000400)='./file0\x00', 0x0)
r0 = openat$fuse(0xffffffffffffff9c, &(0x7f0000002080), 0x42, 0x0)
mount$fuse(0x0, &(0x7f00000042c0)='./file0\x00', &(0x7f0000002000), 0x0, &(0x7f0000002140)={{'fd', 0x3d, r0}, 0x2c, {'rootmode', 0x3d, 0x4000}})
read$FUSE(r0, &(0x7f0000004340)={0x2020, 0x0, <r1=>0x0}, 0x2020)
clone(0x80000100, 0x0, 0xfffffffffffffffe, 0x0, 0xffffffffffffffff)
read$FUSE(r0, &(0x7f00000021c0)={0x2020}, 0x2020)
newfstatat(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00', 0x0, 0x0)
write$FUSE_INIT(r0, &(0x7f0000004200)={0x50, 0x0, r1}, 0x50)

The problem is that it contains clone that creates some kind of fork bomb.
The syzbot reproducer is produced with:

syz-prog2c -prog prog -threaded -repeat=0 -procs=6 -sandbox=none -enable=close_fds

running it in a VM and doing ps afxu | grep a.out | wc -l shows up to 2900 processes. This may DoS the kernel and lead to various hangs/stalls. This mode omits our cgroup restriction on max number of processes:

	// Restrict number of pids per test process to prevent fork bombs.
	// We have up to 16 threads + main process + loop.
	// 32 pids should be enough for everyone.
	snprintf(file, sizeof(file), "%s/pids.max", cgroupdir);
	write_file(file, "32");

A reproducer produces with:

syz-prog2c -prog prog -threaded -repeat=0 -procs=6 -sandbox=none -enable=close_fds,cgroups,sysctl -tmpdir

shows at most 190 processes (6 test processes x 32 limit).

I am not sure what exactly is the solution here. Maybe not removing particular csource options for particular bug types (HANGS in this case)?
CC @a-nogikh

[dvyukov]

This may be another case of a false-positive caused by no sandboxing:
https://groups.google.com/g/syzkaller-bugs/c/S9uHOBxSfho/m/hjK2TWhrBQAJ

The reproducer contains clone and results in "task hung" report:

# https://syzkaller.appspot.com/bug?id=da80594d26723b42e24501b4540ae0ad0489ab00
# See https://goo.gl/kgGztJ for information about syzkaller reproducers.
#{"threaded":true,"repeat":true,"procs":1,"slowdown":1,"sandbox":"","fault_call":-1,"close_fds":false}
clone(0x80100900, 0x0, 0xfffffffffffffffe, 0x0, 0xffffffffffffffff)
wait4(0x0, 0x0, 0x80000002, 0x0)
clone(0x100, 0x0, 0xfffffffffffffffe, 0x0, 0xffffffffffffffff)
io_setup(0x9, &(0x7f0000000040)=<r0=>0x0)
pipe2(&(0x7f0000000080)={<r1=>0xffffffffffffffff}, 0x0)
io_submit(r0, 0x1, &(0x7f0000000340)=[&(0x7f0000000280)={0x0, 0x0, 0x0, 0x0, 0x0, r1, &(0x7f00000000c0)='\t', 0x1, 0x0, 0x0, 0x2}])
io_destroy(r0)

[a-nogikh]

This should now be (at least partially) solved in 9085be7 -- if the sandbox simplification results in a crash title that has not yet been seen during the reproduction process, we don't do the simplification.

A sample repro log where it helped: https://syzkaller.appspot.com/text?tag=ReproLog&x=11d57c63980000

[dvyukov]

This should fix all/most problems, right? Should we close this issue then? Do you see any other potential improvements for this?

[a-nogikh]

I don't immediately see further improvements, let's close.