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]

Date:   Wed, 01 Feb 2017 14:54:06 +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

Dmitry Vyukov <dvyukov@...gle.com> wrote:

> > Can you disassemble this function for me?  There are several possible paths
> > and without the argument to the syscall and whether there's a key that was
> > matched, it's hard to say which path is being taken - but this might help
> > determine that.
> 
> Here it is:
> https://gist.githubusercontent.com/dvyukov/65efc41d00ef0033f9374853b9265c71/raw/9d8540dfb199b81f3d3534ec4cc6da378d07f5b2/gistfile1.txt

Okay, it's called from here:

ffffffff820490fd:	lea    -0x1b0(%rbp),%rdi
ffffffff82049104:	callq  ffffffff82047800 <construct_get_dest_keyring>
ffffffff82049109:	mov    -0x1b0(%rbp),%rdi
ffffffff82049110:	mov    %r15,%rsi
ffffffff82049113:	callq  ffffffff8203efd0 <key_link>  <---
ffffffff82049118:	mov    -0x1b0(%rbp),%rdi
ffffffff8204911f:	mov    %eax,%r14d
ffffffff82049122:	callq  ffffffff82037ab0 <key_put>

Which should correspond to this:

	key_ref = search_process_keyrings(&ctx);

	if (!IS_ERR(key_ref)) {
		key = key_ref_to_ptr(key_ref);
		if (dest_keyring) {
			construct_get_dest_keyring(&dest_keyring);
			ret = key_link(dest_keyring, key);  <---
			key_put(dest_keyring);
			if (ret < 0) {
				key_put(key);
				key = ERR_PTR(ret);
				goto error_free;
			}
		}

which means that the search was successful, the requested key already exists
and there was a destination keyring nominated by userspace.  The first
conditional clause of construct_get_dest_keyring() must've been true:

	struct key *dest_keyring = *_dest_keyring
	...
	if (dest_keyring) {
		/* the caller supplied one */
		key_get(dest_keyring);
	} else {

because it matches the containing if-condition in the calling function.

> I actually know what were the arguments to the syscall. Since it
> happened in a user process context, I know what syzkaller program it
> was running at the time of the crash. It's just they are not
> reproducible. Here are the 3 programs, and they are almost equivalent
> as far as I can see. It's in syzkaller format, but I hope you can
> decipher it, it's just syscall names, address and data in hex:
> https://gist.githubusercontent.com/dvyukov/19bd59ffa286a74b49ca2371b69d4c5c/raw/004eaaa58a4ca775c008591fbb94eae78f92ef86/gistfile1.txt

add_key(&(0x7f0000d02000)="6465616400", ...

What does the "6465616400" represent?  A string containing only numeric
characters or are these 2-digit hex codes and the string is actually "dead"?

David