Re: keys: GPF in request_key

[David Howells <dhowells@redhat.com>]

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.

David