linux-kernel - Re: linux-next: Tree for Nov 7

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: <c52fa249-9583-18a2-cbac-28abfb23d5a5@oracle.com>
Date:   Mon, 13 Nov 2017 09:35:22 -0700
From:   Khalid Aziz <khalid.aziz@...cle.com>
To:     Michal Hocko <mhocko@...nel.org>,
        Michael Ellerman <mpe@...erman.id.au>
Cc:     Joel Stanley <joel@....id.au>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linux-Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Russell King <linux@...linux.org.uk>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Abdul Haleem <abdhalee@...ux.vnet.ibm.com>,
        Ralf Baechle <ralf@...ux-mips.org>,
        "James E.J. Bottomley" <jejb@...isc-linux.org>,
        Helge Deller <deller@....de>,
        Yoshinori Sato <ysato@...rs.sourceforge.jp>,
        Rich Felker <dalias@...c.org>,
        "David S. Miller" <davem@...emloft.net>,
        Chris Zankel <chris@...kel.net>,
        Max Filippov <jcmvbkbc@...il.com>,
        linux-arm-kernel@...ts.infradead.org,
        linuxppc-dev@...ts.ozlabs.org, linux-mips@...ux-mips.org,
        linux-parisc@...r.kernel.org, linux-sh@...r.kernel.org,
        sparclinux@...r.kernel.org, linux-xtensa@...ux-xtensa.org
Subject: Re: linux-next: Tree for Nov 7

On 11/13/2017 09:06 AM, Michal Hocko wrote:
> OK, so this one should take care of the backward compatibility while
> still not touching the arch code
> ---
> commit 39ff9bf8597e79a032da0954aea1f0d77d137765
> Author: Michal Hocko <mhocko@...e.com>
> Date:   Mon Nov 13 17:06:24 2017 +0100
> 
>      mm: introduce MAP_FIXED_SAFE
>      
>      MAP_FIXED is used quite often but it is inherently dangerous because it
>      unmaps an existing mapping covered by the requested range. While this
>      might be might be really desidered behavior in many cases there are
>      others which would rather see a failure than a silent memory corruption.
>      Introduce a new MAP_FIXED_SAFE flag for mmap to achive this behavior.
>      It is a MAP_FIXED extension with a single exception that it fails with
>      ENOMEM if the requested address is already covered by an existing
>      mapping. We still do rely on get_unmaped_area to handle all the arch
>      specific MAP_FIXED treatment and check for a conflicting vma after it
>      returns.
>      
>      Signed-off-by: Michal Hocko <mhocko@...e.com>
> 
> ...... deleted .......
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 680506faceae..aad8d37f0205 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -1358,6 +1358,10 @@ unsigned long do_mmap(struct file *file, unsigned long addr,
>   	if (mm->map_count > sysctl_max_map_count)
>   		return -ENOMEM;
>   
> +	/* force arch specific MAP_FIXED handling in get_unmapped_area */
> +	if (flags & MAP_FIXED_SAFE)
> +		flags |= MAP_FIXED;
> +
>   	/* Obtain the address to map to. we verify (or select) it and ensure
>   	 * that it represents a valid section of the address space.
>   	 */

Do you need to move this code above:

         if (!(flags & MAP_FIXED))
                 addr = round_hint_to_min(addr);

         /* Careful about overflows.. */
         len = PAGE_ALIGN(len);
         if (!len)
                 return -ENOMEM;

Not doing that might mean the hint address will end up being rounded for 
MAP_FIXED_SAFE which would change the behavior from MAP_FIXED.

--
Khalid