From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752013AbdBAOyP convert rfc822-to-8bit (ORCPT ); Wed, 1 Feb 2017 09:54:15 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56710 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751084AbdBAOyN (ORCPT ); Wed, 1 Feb 2017 09:54:13 -0500 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 From: David Howells In-Reply-To: References: <22035.1485956899@warthog.procyon.org.uk> To: Dmitry Vyukov Cc: dhowells@redhat.com, james.l.morris@oracle.com, serge@hallyn.com, keyrings@vger.kernel.org, linux-security-module@vger.kernel.org, LKML , syzkaller Subject: Re: keys: GPF in request_key MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23618.1485960846.1@warthog.procyon.org.uk> Content-Transfer-Encoding: 8BIT Date: Wed, 01 Feb 2017 14:54:06 +0000 Message-ID: <23619.1485960846@warthog.procyon.org.uk> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 01 Feb 2017 14:54:13 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dmitry Vyukov 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 ffffffff82049109: mov -0x1b0(%rbp),%rdi ffffffff82049110: mov %r15,%rsi ffffffff82049113: callq ffffffff8203efd0 <--- ffffffff82049118: mov -0x1b0(%rbp),%rdi ffffffff8204911f: mov %eax,%r14d ffffffff82049122: callq ffffffff82037ab0 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