linux-kernel - Re: [PATCH V3] mm: prevent page_frag_alloc() from corrupting the memory

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAKgT0Ud2Dc0Gbeys7Zwhtqr+j5Qghp3JEyK2LmPUKtbZ4dyDqQ@mail.gmail.com>
Date:   Tue, 9 Aug 2022 07:33:46 -0700
From:   Alexander Duyck <alexander.duyck@...il.com>
To:     Maurizio Lombardi <mlombard@...hat.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Jakub Kicinski <kuba@...nel.org>,
        linux-mm <linux-mm@...ck.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Netdev <netdev@...r.kernel.org>,
        愚树 <chen45464546@....com>
Subject: Re: [PATCH V3] mm: prevent page_frag_alloc() from corrupting the memory

On Tue, Aug 9, 2022 at 4:45 AM Maurizio Lombardi <mlombard@...hat.com> wrote:
>
> út 9. 8. 2022 v 2:14 odesílatel Andrew Morton
> <akpm@...ux-foundation.org> napsal:
> >
> > On Fri, 15 Jul 2022 14:50:13 +0200 Maurizio Lombardi <mlombard@...hat.com> wrote:
> >
> > > A number of drivers call page_frag_alloc() with a
> > > fragment's size > PAGE_SIZE.
> > > In low memory conditions, __page_frag_cache_refill() may fail the order 3
> > > cache allocation and fall back to order 0;
> > > In this case, the cache will be smaller than the fragment, causing
> > > memory corruptions.
> > >
> > > Prevent this from happening by checking if the newly allocated cache
> > > is large enough for the fragment; if not, the allocation will fail
> > > and page_frag_alloc() will return NULL.
> >
> > Can we come up with a Fixes: for this?
>
> I think the bug has been introduced in kernel 3.19-rc1
> Fixes: ffde7328a36d16e626bae8468571858d71cd010b

The problem is this patch won't cleanly apply to that since we moved
the function. In addition this issue is a bit more complex since it
isn't necessarily a problem in the code, but the assumption on how it
is can be used by a select few drivers that were using it to allocate
to higher order pages.

It would probably be best to just go with:
Fixes: b63ae8ca096d ("mm/net: Rename and move page fragment handling
from net/ to mm/")

> >
> > Should this fix be backported into -stable kernels?
>
> Yes, IMO this should be backported to -stable

This should be fine for -stable. Basically it just needs to be there
to block the drivers that abused the API to allocate high order pages
instead of fragments of an order 0 page. Ultimately the correct fix
for this is to fix those drivers, but this at least is enough so that
they will fail allocations now instead of corrupting memory by
overflowing an order 0 page.