From: Hillf Danton <hdanton@sina.com>
To: David Howells <dhowells@redhat.com>
Cc: "dhowells@redhat.com" <dhowells@redhat.com>,
Sachin Sant <sachinp@linux.vnet.ibm.com>,
"keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linuxppc-dev@ozlabs.org" <linuxppc-dev@ozlabs.org>
Subject: Re: Oops (request_key_auth_describe) while running cve-2016-7042 from LTP
Date: Fri, 30 Aug 2019 22:54:37 +0800 [thread overview]
Message-ID: <46L6yC2ywBzDr5y@lists.ozlabs.org> (raw)
In-Reply-To: <4384.1567174383@warthog.procyon.org.uk>
[-- Attachment #1: Type: text/plain, Size: 887 bytes --]
David Howells <dhowells@redhat.com> wrote:
>
> Hillf Danton <hdanton@sina.com> wrote:
>
> > - struct request_key_auth *rka = dereference_key_rcu(key);
> > + struct request_key_auth *rka;
> > +
> > + rcu_read_lock();
> > + rka = dereference_key_rcu(key);
>
> This shouldn't help as the caller, proc_keys_show(), is holding the RCU read
> 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
[-- Attachment #2: Type: text/html, Size: 4276 bytes --]
next prev parent reply other threads:[~2019-08-31 7:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190830145454.B91DF125411@zmta02.collab.prod.int.phx2.redhat.com>
2019-08-30 8:56 ` Oops (request_key_auth_describe) while running cve-2016-7042 from LTP Hillf Danton
2019-08-30 10:32 ` Sachin Sant
2019-08-30 14:13 ` David Howells
2019-08-30 14:54 ` Hillf Danton [this message]
2019-08-30 15:12 ` David Howells
2019-08-31 1:20 ` Hillf Danton
2019-08-30 6:48 Sachin Sant
2019-08-30 15:13 ` David Howells
2019-08-31 4:57 ` Sachin Sant
2019-09-02 7:14 ` David Howells
2019-09-02 11:40 ` Hillf Danton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46L6yC2ywBzDr5y@lists.ozlabs.org \
--to=hdanton@sina.com \
--cc=dhowells@redhat.com \
--cc=keyrings@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=sachinp@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).