linux-kernel - Re: keys: GPF in request

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <25638.1485967824@warthog.procyon.org.uk>
Date:   Wed, 01 Feb 2017 16:50:24 +0000
From:   David Howells <dhowells@...hat.com>
To:     Dmitry Vyukov <dvyukov@...gle.com>
Cc:     dhowells@...hat.com, james.l.morris@...cle.com, serge@...lyn.com,
        keyrings@...r.kernel.org, linux-security-module@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>,
        syzkaller <syzkaller@...glegroups.com>
Subject: Re: keys: GPF in request_key

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