linux-kernel - Re: [PATCH] mm/hugetlb: fix null ptr defer in hugetlb_vma_lock

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]

Date:   Thu, 02 Nov 2023 23:15:50 -0400
From:   Rik van Riel <riel@...riel.com>
To:     Mike Kravetz <mike.kravetz@...cle.com>
Cc:     Edward Adam Davis <eadavis@...com>, akpm@...ux-foundation.org,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        llvm@...ts.linux.dev, muchun.song@...ux.dev, nathan@...nel.org,
        ndesaulniers@...gle.com,
        syzbot+6ada951e7c0f7bc8a71e@...kaller.appspotmail.com,
        syzkaller-bugs@...glegroups.com, trix@...hat.com
Subject: Re: [PATCH] mm/hugetlb: fix null ptr defer in hugetlb_vma_lock_write

On Thu, 2023-11-02 at 19:37 -0700, Mike Kravetz wrote:
> On 11/02/23 19:24, Mike Kravetz wrote:
> > 
> > In the specific case causing the null-ptr-deref, the resv_map
> > pointer
> > (vm_private_data) is NULL.
> 
> Hi Rik,
> 
> In commit bf4916922c60 hugetlbfs: extend hugetlb_vma_lock to private
> VMAs,
> it correctly says:
> 
>     Extend the locking scheme used to protect shared hugetlb mappings
> from
>     truncate vs page fault races, in order to protect private hugetlb
> mappings
>     (with resv_map) against MADV_DONTNEED.
> 
> That qualification '(with resv_map)' caught my attention originally,
> and
> I thought about it again while looking into this.  We now cover the
> common
> cases, but there are still quite a few cases where resv_map is NULL
> for
> private mappings.  In such cases, the race between MADV_DONTNEED and
> page
> fault still exists.  Is that a concern?

Honestly, I'm not sure. In hugetlb_dup_vma_private, which is
called at fork time, we have this comment:

         * - For MAP_PRIVATE mappings, this is the reserve map which
does
         *   not apply to children.  Faults generated by the children
are
         *   not guaranteed to succeed, even if read-only.

That suggests we already have no guarantee of faults
succeeding after fork.

> 
> With a bit more work we 'could' make sure every hugetlb vma has a
> lock
> to participate in this scheme.
> 
> Any thhoughts?

We can certainly close the race between MADV_DONTNEED
and page faults for MAP_PRIVATE mappings in child processes,
but that does not guarantee that we actually have hugetlb
pages for those processes.

In short, I'm not sure :)

-- 
All Rights Reversed.