From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753014AbdBAQud (ORCPT ); Wed, 1 Feb 2017 11:50:33 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37736 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752994AbdBAQua (ORCPT ); Wed, 1 Feb 2017 11:50:30 -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> <23619.1485960846@warthog.procyon.org.uk> <24434.1485963750@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: <25637.1485967824.1@warthog.procyon.org.uk> Date: Wed, 01 Feb 2017 16:50:24 +0000 Message-ID: <25638.1485967824@warthog.procyon.org.uk> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Wed, 01 Feb 2017 16:50:31 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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