All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, Sabyrzhan Tasbolatov <snovitoll@gmail.com>
Subject: Re: [PATCH v3] mm: memdup_user*() should use same gfp flags
Date: Wed, 27 Jan 2021 13:17:11 +0100	[thread overview]
Message-ID: <YBFZx3UjSfHOIbjx@dhcp22.suse.cz> (raw)
In-Reply-To: <YBFVnk0wxN2opYEc@dhcp22.suse.cz>

On Wed 27-01-21 12:59:28, Michal Hocko wrote:
> On Wed 27-01-21 19:55:38, Tetsuo Handa wrote:
> > syzbot is reporting that memdup_user_nul() which receives user-controlled
> > size (which can be up to (INT_MAX & PAGE_MASK)) via vfs_write() will hit
> > order >= MAX_ORDER path [1].
> > 
> > Making costly allocations (order > PAGE_ALLOC_COSTLY_ORDER) naturally fail
> > should be better than trying to enforce PAGE_SIZE upper limit, for some of
> > callers accept space-delimited list arguments.
> > 
> > Therefore, let's add __GFP_NOWARN to memdup_user_nul() as with
> > commit 6c8fcc096be9d02f ("mm: don't let userspace spam allocations
> > warnings"). Also use GFP_USER as with other userspace-controllable
> > allocations like memdup_user().
> 
> I absolutely detest hiding this behind __GFP_NOWARN. There should be no
> reason to even try hard for memdup_user_nul. Can you explain why this

this should have been "try hard to get a physicaly contiguous memory for memdup_user_nul"

> cannot use kvmalloc instead?

-- 
Michal Hocko
SUSE Labs


  reply	other threads:[~2021-01-27 12:17 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-20  4:18 [PATCH] mm: add __GFP_NOWARN to memdup_user_nul() Tetsuo Handa
2021-01-20 10:34 ` [PATCH v2] mm: memdup_user*() should use same gfp flags Tetsuo Handa
2021-01-22  1:35   ` Andrew Morton
2021-01-22 10:47     ` Tetsuo Handa
2021-01-25 13:32       ` Michal Hocko
2021-01-25 14:20         ` Tetsuo Handa
2021-01-25 15:44           ` Michal Hocko
2021-01-26 11:13             ` Sabyrzhan Tasbolatov
2021-01-27 10:55               ` [PATCH v3] " Tetsuo Handa
2021-01-27 11:59                 ` Michal Hocko
2021-01-27 12:17                   ` Michal Hocko [this message]
     [not found]                     ` <3e01b180-0a5b-f2aa-6247-1c3bbcabe1ed@i-love.sakura.ne.jp>
2021-01-27 23:19                       ` Andrew Morton
2021-01-27 23:27                         ` Casey Schaufler
2021-01-28  7:42                           ` Tetsuo Handa
2021-01-28  8:06                         ` Michal Hocko

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=YBFZx3UjSfHOIbjx@dhcp22.suse.cz \
    --to=mhocko@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-mm@kvack.org \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --cc=snovitoll@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.