Re: keys: GPF in request_key

From	David Howells <dhowells@redhat.com>
Newsgroups	linux.kernel
Subject	Re: keys: GPF in request_key
Date	2017-02-01 18:00 +0100
Message-ID	<t66qf-8ov-37@gated-at.bofh.it> (permalink)
References	(3 earlier) <t63LI-6WZ-15@gated-at.bofh.it> <t64y6-7eg-11@gated-at.bofh.it> <t6518-7DU-9@gated-at.bofh.it> <t65kt-7KL-3@gated-at.bofh.it> <t65ua-7Of-17@gated-at.bofh.it>
Organization	Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903

Show all headers | View raw

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

Thread

keys: GPF in request_key Dmitry Vyukov <dvyukov@google.com> - 2017-02-01 13:30 +0100
  Re: keys: GPF in request_key David Howells <dhowells@redhat.com> - 2017-02-01 14:20 +0100
    Re: keys: GPF in request_key Dmitry Vyukov <dvyukov@google.com> - 2017-02-01 14:30 +0100
  Re: keys: GPF in request_key David Howells <dhowells@redhat.com> - 2017-02-01 14:30 +0100
  Re: keys: GPF in request_key David Howells <dhowells@redhat.com> - 2017-02-01 14:50 +0100
    Re: keys: GPF in request_key Dmitry Vyukov <dvyukov@google.com> - 2017-02-01 15:10 +0100
      Re: keys: GPF in request_key David Howells <dhowells@redhat.com> - 2017-02-01 16:00 +0100
        Re: keys: GPF in request_key Dmitry Vyukov <dvyukov@google.com> - 2017-02-01 16:30 +0100
          Re: keys: GPF in request_key David Howells <dhowells@redhat.com> - 2017-02-01 16:50 +0100
            Re: keys: GPF in request_key Dmitry Vyukov <dvyukov@google.com> - 2017-02-01 17:00 +0100
              Re: keys: GPF in request_key David Howells <dhowells@redhat.com> - 2017-02-01 18:00 +0100
                Re: keys: GPF in request_key Dmitry Vyukov <dvyukov@google.com> - 2017-02-01 18:20 +0100

csiph-web