On Wed, Feb 1, 2017 at 5:50 PM, David Howells <dhowe...@redhat.com> wrote: > Do you reboot the system between running individual programs? If not, the > programs will be influencing each other. Further, only those calls with valid > type and matching description values are relevant, I think. This means those > that use: > > static const char type_2[] = "user"; > static const char desc_2[] = "syz\1"; > > so: > > r25 = request_key(type_2, desc_2, ...); > ... > r26 = add_key(type_2, desc_2, ...); > ... > r24 = request_key(type_2, desc_2, ...); > ... > r25 = add_key(type_2, desc_2, ...); > ... > r25 = request_key(type_2, desc_2, ...); > ... > r26 = add_key(type_2, desc_2, ...); > > The first request_key() call will fail because it doesn't find anything and > the upcall process, if it is available, has no suitable handler and will > negatively instantiate it. > > The first add_key() call will then update the key to make it positively > instantiated, after which subsequent request_key() calls will return the key > and add_key() calls will update its contents. > > So, it would appear that it's not the first call to request_key() of type_2, > desc_2, but one subsequent to that. The type_4 request_key() calls should get > weeded out very quickly in sys_request_key() by key_get_type_from_user() - > which seems to happen (EPERM is returned). > > Doing: > > keyctl link @us @s > > before running the program on Fedora allows the request_key() to find the > add_key() results. > > Do you run some of these in parallel? Running the combo program 100,000 times > sequentially didn't produce a crash. > >> The OS is debian/wheezy created with: >> $ debootstrap --include=openssh-server,curl,tar,time,strace,sudo,less,psmisc >> wheezy wheezy >> >> I did not do any additional setup. I don't know what is PAM, so I >> guess I did not set it up. >> The machine is GCE VM. > > I would imagine that PAM is part of the core OS - it does things like > controlling login service security. Jessie apparently has it. However, > Debian didn't use to include pam_keyinit.
No, syzkaller does not reboot machines after execution of a single program. That would make the testing process too slow. It relies on process/filesystem/namespace isolation. But keys subsystem has global state and that's the problem. So, yes, most likely there was some accumulated state from previous programs.
