On Mon 25-01-21 23:20:41, Tetsuo Handa wrote:
> On 2021/01/25 22:32, Michal Hocko wrote:
> > On Fri 22-01-21 19:47:42, Tetsuo Handa wrote:
> >> On 2021/01/22 10:35, Andrew Morton wrote:
> >>> On Wed, 20 Jan 2021 19:34:36 +0900 Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> 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].
> >
> > That is nasty!
>
> That's because -EFAULT will not be detected before memory allocation succeeds.
> Fuzzer is passing huge size without corresponding valid buffer.
>
> syscall(__NR_write, r[0], 0x200000c0ul, 0x200000cbul);
>
> >
> >>>> 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 commit 6c2c97a24f096e32 ("memdup_user(): switch to GFP_USER").
> >
> > No, this is papering over a more troubling underlying problem. Userspace
> > shouldn't be able to trigger an aribitrary higher order allocations.
>
> That requires inserting max size checking before calling memdup_user_nul().
> Oh, scattering around such checking is not nice. Add max length argument
> into memdup_user_nul() like strndup_user() ?
Or simply fallback to the vmalloc based memdump* if the size is larger
than the PAGE_SIZE. It seems that the existing API is much more complex
than necessary.
[...]
> > I do not think we have anything better than the above. GFP_USER is
> > indeed used for userspace controlable allocations. So they can be a
> > subject to a more strict cpu policy. memdup_user_nul looks like a good
> > fit for GFP_USER to me. memdup_user and other variant already does this.
> >
>
> Hmm, Sabyrzhan already proposed a patch that adds size check to the caller, but it seems
> that that patch missed smk_write_ambient()/smk_write_onlycap()/smk_write_unconfined() etc.
> Oh, bug-prone approach. Why not handle at memdup_user_nul() side?
I am sorry I do not follow.
--
Michal Hocko
SUSE Labs
