linux-kernel - Re: [PATCH 4/6] mm: remove free_unmap_vmap_area

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20161021125828.17b8960e@roar.ozlabs.ibm.com>
Date:   Fri, 21 Oct 2016 12:58:28 +1100
From:   Nicholas Piggin <npiggin@...il.com>
To:     Joel Fernandes <joelaf@...gle.com>
Cc:     Christoph Hellwig <hch@....de>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Jisheng Zhang <jszhang@...vell.com>,
        Chris Wilson <chris@...is-wilson.co.uk>,
        John Dias <joaodias@...gle.com>,
        "open list:MEMORY MANAGEMENT" <linux-mm@...ck.org>,
        linux-rt-users@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/6] mm: remove free_unmap_vmap_area_addr

On Thu, 20 Oct 2016 17:46:36 -0700
Joel Fernandes <joelaf@...gle.com> wrote:

> > @@ -1100,10 +1091,14 @@ void vm_unmap_ram(const void *mem, unsigned int count)
> >         debug_check_no_locks_freed(mem, size);
> >         vmap_debug_free_range(addr, addr+size);
> >
> > -       if (likely(count <= VMAP_MAX_ALLOC))
> > +       if (likely(count <= VMAP_MAX_ALLOC)) {
> >                 vb_free(mem, size);
> > -       else
> > -               free_unmap_vmap_area_addr(addr);
> > +               return;
> > +       }
> > +
> > +       va = find_vmap_area(addr);
> > +       BUG_ON(!va);  
> 
> Considering recent objections to BUG_ON [1], lets make this a WARN_ON
> while we're moving the code?

If you lost track of your kernel memory mappings, you are in big trouble
and fail stop is really the best course of action for containing the
problem, which could have security and data corruption implications. This
is covered by Linus' last paragraph in that commit.

Thanks,
Nick