From: Peter Zijlstra <peterz@infradead.org>
To: Michal Hocko <mhocko@kernel.org>
Cc: Dan Carpenter <dan.carpenter@oracle.com>,
"David S. Miller" <davem@davemloft.net>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Jens Axboe <axboe@kernel.dk>,
Amritha Nambiar <amritha.nambiar@intel.com>,
Willem de Bruijn <willemb@google.com>,
kernel-janitors@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] cpumask: Introduce possible_cpu_safe()
Date: Thu, 04 Apr 2019 11:28:05 +0000 [thread overview]
Message-ID: <20190404112805.GZ4038@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20190404103528.GG12864@dhcp22.suse.cz>
On Thu, Apr 04, 2019 at 12:35:28PM +0200, Michal Hocko wrote:
> On Thu 04-04-19 13:02:19, Dan Carpenter wrote:
> > There have been two cases recently where we pass user a controlled "cpu"
> > to possible_cpus(). That's not allowed. If it's invalid, it will
> > trigger a WARN_ONCE() and an out of bounds read which could result in an
> > Oops.
> >
> > This patch introduces possible_cpu_safe() which first checks to see if
> > the cpu is valid, turns off speculation and then checks if the cpu is
> > possible.
>
> Why cannot we do the check in possible_cpu directly? Is it used from any
> hot path? I am quite skeptical people will use the new helper
> consistently.
Why only possible? What is to say stop anyone from using garbage (aka.
user input) in any other of the cpumask APIs.
I'd much rather have the explicit validate call and keep assuming @cpu
as used in the rest of the API is sane.
next prev parent reply other threads:[~2019-04-04 11:28 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-04 10:02 [PATCH 1/2] cpumask: Introduce possible_cpu_safe() Dan Carpenter
2019-04-04 10:04 ` [PATCH 2/2] io_uring: Potential Oops in io_sq_offload_start() Dan Carpenter
2019-04-04 10:35 ` [PATCH 1/2] cpumask: Introduce possible_cpu_safe() Michal Hocko
2019-04-04 11:28 ` Peter Zijlstra [this message]
2019-04-04 10:45 ` Peter Zijlstra
2019-04-08 8:09 ` [PATCH v2 " Dan Carpenter
2019-04-08 8:15 ` [PATCH v2 2/2] io_uring: Potential Oops in io_sq_offload_start() Dan Carpenter
2019-04-30 9:26 ` Dan Carpenter
2019-05-03 11:43 ` Dan Carpenter
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=20190404112805.GZ4038@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=amritha.nambiar@intel.com \
--cc=axboe@kernel.dk \
--cc=dan.carpenter@oracle.com \
--cc=davem@davemloft.net \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhocko@kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=willemb@google.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).