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=-0.5 required=3.0 tests=FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no 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 CF179C3A59F for ; Sat, 31 Aug 2019 07:13:26 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D645B23774 for ; Sat, 31 Aug 2019 07:13:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D645B23774 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=sina.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 46L6yC2ywBzDr5y for ; Sat, 31 Aug 2019 17:13:23 +1000 (AEST) Received: from ozlabs.org (bilbo.ozlabs.org [IPv6:2401:3900:2:1::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 46KjFF00mGzDqPG for ; Sat, 31 Aug 2019 00:54:56 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=sina.com Received: from ozlabs.org (bilbo.ozlabs.org [203.11.71.1]) by bilbo.ozlabs.org (Postfix) with ESMTP id 46KjFD3d9nz8t79 for ; Sat, 31 Aug 2019 00:54:56 +1000 (AEST) Received: by ozlabs.org (Postfix) id 46KjFD2sZKz9sBp; Sat, 31 Aug 2019 00:54:56 +1000 (AEST) Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=sina.com (client-ip=202.108.3.162; helo=mail3-162.sinamail.sina.com.cn; envelope-from=hdanton@sina.com; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=sina.com Received: from mail3-162.sinamail.sina.com.cn (mail3-162.sinamail.sina.com.cn [202.108.3.162]) by ozlabs.org (Postfix) with SMTP id 46KjFC1zKbz9s5b for ; Sat, 31 Aug 2019 00:54:45 +1000 (AEST) Received: from unknown (HELO [IPv6:::ffff:192.168.199.155])([114.254.173.51]) by sina.com with ESMTP id 5D6938AC000124E4; Fri, 30 Aug 2019 22:54:39 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 10726449326101 MIME-Version: 1.0 To: David Howells From: Hillf Danton Subject: Re: Oops (request_key_auth_describe) while running cve-2016-7042 from LTP Date: Fri, 30 Aug 2019 22:54:37 +0800 Importance: normal X-Priority: 3 In-Reply-To: <4384.1567174383@warthog.procyon.org.uk> References: <20190830085646.14740-1-hdanton@sina.com> <4384.1567174383@warthog.procyon.org.uk> Content-Type: multipart/alternative; boundary="_12CB79AF-0B70-49E2-8B3F-06A5A6969988_" X-Mailman-Approved-At: Sat, 31 Aug 2019 17:11:34 +1000 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "dhowells@redhat.com" , Sachin Sant , "keyrings@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linuxppc-dev@ozlabs.org" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Message-Id: <46L6yC2ywBzDr5y@lists.ozlabs.org> --_12CB79AF-0B70-49E2-8B3F-06A5A6969988_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" David Howells wrote: > > Hillf Danton wrote: > > > - struct request_key_auth *rka =3D dereference_key_rcu(key); > > + struct request_key_auth *rka; > > + > > + rcu_read_lock(); > > + rka =3D dereference_key_rcu(key); > > This shouldn't help as the caller, proc_keys_show(), is holding the RCU r= ead > lock across the call. The end of the function reads: > and the documentation says "This method will be called with the RCU read = lock > held". > 1, callee has no pre defined duty to help caller in general; they should not try to do anything, however, to help their callers in principle due to limited info on their hands IMO. 2, uses of rcu can be nested. 3, no comment can be found in security/keys/request_key_auth.c about the rcu already documented. 4, the newly added rcu can avoid incidental messup anywhere else. Hillf --_12CB79AF-0B70-49E2-8B3F-06A5A6969988_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

David Howells <dhowells@redhat.com> wrote:

>=  

> Hillf D= anton <hdanton@sina.com> wrote:

> 

> > -=C2=A0=C2=A0=C2=A0=C2=A0 struct request_key_auth *rka = =3D dereference_key_rcu(key);

> > +=C2=A0=C2=A0=C2=A0=C2=A0 struct request_key_auth *rka;

> > +

> > +=C2=A0=C2=A0=C2=A0=C2=A0 rcu_re= ad_lock();

> > +=C2= =A0=C2=A0=C2=A0=C2=A0 rka =3D dereference_key_rcu(key);

> 

> This shouldn't help as the caller, proc_k= eys_show(), is holding the RCU read

> lock across the call.=C2=A0 The end of the function reads:<= /span>

> and the documentatio= n says "This method will be called with the RCU read lock

> held".

> 

1, callee has no pre defined duty to help call= er in general; they should

not try to do anything, however, to help their callers in principle due t= o

limited info on their h= ands IMO.

2, uses of rcu = can be nested.

3, no comm= ent can be found in security/keys/request_key_auth.c about

the rcu already documented.

4, the newly added rcu can avoid incid= ental messup anywhere else.

 

Hill= f

= --_12CB79AF-0B70-49E2-8B3F-06A5A6969988_--