Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1571786

Re: keys: GPF in request_key

Show all headers | View raw

On Wed, Feb 1, 2017 at 5:50 PM, David Howells <dhowells@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.

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

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