From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BE1B4C43381 for ; Thu, 14 Mar 2019 17:22:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8DD522186A for ; Thu, 14 Mar 2019 17:22:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1552584168; bh=ub926B5z9FLQ2XG2G4mX6giJx6LoXNst9lh60N+UsLs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=A5un1QAXFeEVU7NK7U8WgjTq1EDTDYjBP0wQawI8T4YQ7NF0HVimzmaoXke/0liOX cK6akH55bAcuVbvKuzP/io7CWR228jk5EIn3XQaUt88f5TNqDLrP7C2XcASgN/qy5+ vCg0a2SaefPuK/1zTnNHX/O221ttk3IzyNKoLfgI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726753AbfCNRWs (ORCPT ); Thu, 14 Mar 2019 13:22:48 -0400 Received: from mail.kernel.org ([198.145.29.99]:53374 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726157AbfCNRWr (ORCPT ); Thu, 14 Mar 2019 13:22:47 -0400 Received: from localhost (unknown [12.27.65.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id EF6B8217F5; Thu, 14 Mar 2019 17:22:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1552584167; bh=ub926B5z9FLQ2XG2G4mX6giJx6LoXNst9lh60N+UsLs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=iL2TrYwB5stzdeCenhG0knKv7RJdQT+MGW2bGSUP2Vis15fno+W59hJn1rEVBWwV6 zim80aaT6diOoPG6eQNE8rHCU6caEH1BEVN5Sm2il5M7BnM1BCiG+RjvQQop+PB0yB yZtYetoZ/FIxhGtlC5q1c9u71onjAoy8eIrtP0FA= Date: Thu, 14 Mar 2019 10:22:46 -0700 From: Greg KH To: Guenter Roeck Cc: Zubin Mithra , "# v4 . 10+" , Guenter Roeck , ebiggers@google.com, dhowells@redhat.com, jmorris@namei.org, serge@hallyn.com Subject: Re: 4aa68e07d845 ("KEYS: restrict /proc/keys by credentials at open time") Message-ID: <20190314172246.GA28850@kroah.com> References: <20190314163040.GA36815@google.com> <20190314171142.GA25362@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.4 (2019-03-13) Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Thu, Mar 14, 2019 at 10:18:00AM -0700, Guenter Roeck wrote: > On Thu, Mar 14, 2019 at 10:11 AM Greg KH wrote: > > > > On Thu, Mar 14, 2019 at 09:30:42AM -0700, Zubin Mithra wrote: > > > Hello, > > > > > > Syzkaller has triggered a kernel BUG when fuzzing a 4.4 kernel with the following stacktrace. > > > Call Trace: > > > [] construct_alloc_key security/keys/request_key.c:388 [inline] > > > [] construct_key_and_link security/keys/request_key.c:479 [inline] > > > [] request_key_and_link+0x49b/0x8c5 security/keys/request_key.c:594 > > > [] SYSC_request_key security/keys/keyctl.c:213 [inline] > > > [] SyS_request_key+0x1ac/0x2a2 security/keys/keyctl.c:158 > > > [] entry_SYSCALL_64_fastpath+0x31/0xb3 > > > > > > Could the following patches be applied to v4.4.y? > > > * 4aa68e07d845 ("KEYS: restrict /proc/keys by credentials at open time") > > > * ede0fa98a900 ("KEYS: always initialize keyring_index_key::desc_len") > > > > > > Note: queue-4.4 currently has a backport for "keys-always-initialize-keyring_index_key-desc_len.patch". > > > > As the queue already has this second patch, no need to add it, right? > > > > And 4aa68e07d845 doesn't apply cleanly, but your 4.9.y backport did, so > > I'll take that one, is that ok? > > > > This is just a matter of ordering and personal preference. You can > either drop the existing patch from the 4.4 queue and apply both > patches from upstream, or apply the 4.9 backport on top of the > existing queue. Result should be the same. Ok, great, thanks for confirming, all should now be queued up. If I messed something up, please let me know. thanks, greg k-h