All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Reisner <reisner.marc@gmail.com>
To: "Liam R. Howlett" <Liam.Howlett@oracle.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>,
	Paul Moore <paul@paul-moore.com>,
	akpm@linux-foundation.org, david@redhat.com, linux-mm@kvack.org,
	omosnace@redhat.com, peterz@infradead.org,
	selinux@vger.kernel.org, Vlastimil Babka <vbabka@suse.cz>,
	Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Subject: Re: [PATCH v3 3/4] selinux: use vma_is_initial_stack() and vma_is_initial_heap()
Date: Thu, 8 Aug 2024 19:35:21 +0000	[thread overview]
Message-ID: <ZrUd-ZUe12FahKIc@marcreisner.com> (raw)
In-Reply-To: <zk5ffj6otbixbnppw4shxgz4tjulagm7du457gzi4qg7zrtdkk@e7mbwyzhdtrx>

On Thu, Aug 08, 2024 at 02:00:09PM -0400, Liam R. Howlett wrote:
> Have a look at the mmapstress 3 test in ltp [1].  The tests pokes holes
> and mmaps into those holes throughout the brk range.
> 
> [1]. https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/mem/mmapstress/mmapstress03.c

In investigating this further, with additional reproducers, I believe
that the whole bug is in vma_is_initial_heap(). Here is what I have
tested so far:

1. Use only sbrk to allocate heap memory - sbrk(0) returns the start_brk
before calling sbrk(increment). Afterwards, sbrk(0) returns start_brk +
increment.
2. Use sbrk(0) to obtain start_brk, then request 512 MB of address space
from mmap starting at start_brk. mmap allocates 512 MB of address space
starting at start_brk and ending at start_brk + 0x20000000. sbrk(0)
still returns start_brk. However, /proc/PID/maps flags the mmapped
address space with "[heap]"
3. Use sbrk(0) to obtain start_brk, then request 512 MB of address space
from mmap starting at start_brk + _SC_PAGESIZE. mmap allocates 512 MB of
address space starting at start_brk + _SC_PAGESIZE and ending at
start_brk + _SC_PAGESIZE + 0x20000000. sbrk(0) still returns start_brk,
and /proc/PID/maps does NOT flag the mmapped address space with
"[heap]".

I believe that the entire bug may reside in vma_is_initial_heap because
/proc/PID/maps also uses vma_is_initial_heap to flag entries with
"[heap]" [1]. Also, sbrk(0) is not actually getting updated after a call
to mmap, so mmap is not actually allocating heap memory.

What do you all think about this patch? If it doesn't have any obvious
flaws I can submit it (along with a revert for the revert).

diff --git a/include/linux/mm.h b/include/linux/mm.h
index c4b238a20b76..1dd588833af8 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -918,7 +918,8 @@ static inline bool vma_is_anonymous(struct vm_area_struct *vma)
  */
 static inline bool vma_is_initial_heap(const struct vm_area_struct *vma)
 {
-       return vma->vm_start < vma->vm_mm->brk &&
+       return vma->vm_mm->brk != vma->vm_mm->start_brk &&
+               vma->vm_start < vma->vm_mm->brk &&
                vma->vm_end > vma->vm_mm->start_brk;
 }

--


[1]. https://github.com/torvalds/linux/blob/6a0e38264012809afa24113ee2162dc07f4ed22b/fs/proc/task_mmu.c#L287

  reply	other threads:[~2024-08-08 19:35 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-28  5:00 [PATCH v3 0/4] mm: convert to vma_is_initial_heap/stack() Kefeng Wang
2023-07-28  5:00 ` Kefeng Wang
2023-07-28  5:00 ` Kefeng Wang
2023-07-28  5:00 ` [PATCH v3 1/4] mm: factor out VMA stack and heap checks Kefeng Wang
2023-07-28  5:00   ` Kefeng Wang
2023-07-28  5:00   ` Kefeng Wang
2023-07-28  5:00 ` [PATCH v3 2/4] drm/amdkfd: use vma_is_initial_stack() and vma_is_initial_heap() Kefeng Wang
2023-07-28  5:00   ` Kefeng Wang
2023-07-28  5:00   ` Kefeng Wang
2023-07-28  5:00 ` [PATCH v3 3/4] selinux: " Kefeng Wang
2023-07-28  5:00   ` Kefeng Wang
2023-07-28  5:00   ` Kefeng Wang
2023-07-31 14:26   ` Fwd: " Stephen Smalley
2023-07-31 16:19     ` Paul Moore
     [not found]       ` <CAEjxPJ6iFRZUetSvMgZvq_327U_JZ_w9s=gFccKgJhfCt8bqNg@mail.gmail.com>
     [not found]         ` <CAHC9VhRB1uVVWFUgnMZ1iwCD_A0mEX2Xhn79qTxuNKTzisWULg@mail.gmail.com>
2023-12-06 14:22           ` Ondrej Mosnacek
2023-12-06 20:47             ` Paul Moore
2023-12-07  4:50               ` Kefeng Wang
2023-12-07  8:37                 ` Ondrej Mosnacek
2023-12-07  9:23                   ` Kefeng Wang
2024-08-07 21:26                     ` Marc Reisner
2024-08-08  1:10                       ` Paul Moore
2024-08-08  6:43                         ` Kefeng Wang
2024-08-08 11:09                           ` Kefeng Wang
2024-08-08 11:41                             ` Stephen Smalley
2024-08-08 13:12                               ` Kefeng Wang
2024-08-08 15:03                                 ` Marc Reisner
2024-08-08 18:00                                   ` Liam R. Howlett
2024-08-08 19:35                                     ` Marc Reisner [this message]
2024-08-08 20:40                                       ` Paul Moore
2023-07-28  5:00 ` [PATCH v3 4/4] perf/core: " Kefeng Wang
2023-07-28  5:00   ` Kefeng Wang
2023-07-28  5:00   ` Kefeng Wang
2023-07-31 13:47 ` [PATCH v3 0/4] mm: convert to vma_is_initial_heap/stack() Peter Zijlstra
2023-07-31 13:47   ` Peter Zijlstra
2023-07-31 13:47   ` Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZrUd-ZUe12FahKIc@marcreisner.com \
    --to=reisner.marc@gmail.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=omosnace@redhat.com \
    --cc=paul@paul-moore.com \
    --cc=peterz@infradead.org \
    --cc=selinux@vger.kernel.org \
    --cc=vbabka@suse.cz \
    --cc=wangkefeng.wang@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.