linux-kernel - Re: [PATCH] mm: mmap: show vm_unmapped

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: <20200308123616.GH31215@bombadil.infradead.org>
Date:   Sun, 8 Mar 2020 05:36:16 -0700
From:   Matthew Wilcox <willy@...radead.org>
To:     Jaewon Kim <jaewon31.kim@...sung.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>, walken@...gle.com,
        bp@...e.de, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        jaewon31.kim@...il.com
Subject: Re: [PATCH] mm: mmap: show vm_unmapped_area error log

On Sun, Mar 08, 2020 at 06:58:47PM +0900, Jaewon Kim wrote:
> On 2020년 03월 08일 10:58, Matthew Wilcox wrote:
> > On Sat, Mar 07, 2020 at 03:47:44PM -0800, Andrew Morton wrote:
> >> On Fri, 6 Mar 2020 15:16:22 +0900 Jaewon Kim <jaewon31.kim@...sung.com> wrote:
> >>> Even on 64 bit kernel, the mmap failure can happen for a 32 bit task.
> >>> Virtual memory space shortage of a task on mmap is reported to userspace
> >>> as -ENOMEM. It can be confused as physical memory shortage of overall
> >>> system.
> > But userspace can trigger this printk.  We don't usually allow printks
> > under those circumstances, even ratelimited.
> Hello thank you your comment.
> 
> Yes, userspace can trigger printk, but this was useful for to know why
> a userspace task was crashed. There seems to be still many userspace
> applications which did not check error of mmap and access invalid address.
> 
> Additionally in my AARCH64 Android environment, display driver tries to
> get userspace address to map its display memory. The display driver
> report -ENOMEM from vm_unmapped_area and but also from GPU related
> address space.
> 
> Please let me know your comment again if this debug is now allowed
> in that userspace triggered perspective.

The scenario that worries us is an attacker being able to fill the log
files and so also fill (eg) the /var partition.  Once it's full, future
kernel messages cannot be stored anywhere and so there will be no traces
of their privilege escalation.

Maybe a tracepoint would be a better idea?  Usually they are disabled,
but they can be enabled by a sysadmin to gain insight into why an
application is crashing.