linux-kernel - Re: [GIT PULL] MM updates for 6.5-rc1

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:   Wed, 28 Jun 2023 12:19:42 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Andrew Morton <akpm@...ux-foundation.org>,
        Lorenzo Stoakes <lstoakes@...il.com>
Cc:     linux-mm@...ck.org, mm-commits@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] MM updates for 6.5-rc1

On Mon, 26 Jun 2023 at 08:50, Andrew Morton <akpm@...ux-foundation.org> wrote:
>
> Linus, please merge the MM updates for the 6.5-rc cycle.

Hmm. I have merged this, as pr-tracker-bot already noticed, but I
found a bug after merging it.

mm/memory.c: __access_remote_vm() is entirely broken for the
HAVE_IOREMAP_PROT case (ie all normal architectures), because it does
(skipping the non-HAVE_IOREMAP_PROT case):

        struct vm_area_struct *vma = NULL;
        struct page *page = get_user_page_vma_remote(mm, addr,
                                                     gup_flags, &vma);

        if (IS_ERR_OR_NULL(page)) {
                [ ... ]
                if (!vma)
                        break;
                if (vma->vm_ops && vma->vm_ops->access)
                        res = vma->vm_ops->access(vma, addr, buf, ...

but get_user_page_vma_remote() doesn't even set vma if it fails!

So that "if (!vma)" case will always trigger, and the whole ->access()
thing is never done.

So that __access_remote_vm() conversion in commit ca5e863233e8
("mm/gup: remove vmas parameter from get_user_pages_remote()") is
entirely broken.

Now, I don't disagree with removing the vmas parameter. I just
disagree with the get_user_page_vma_remote() helper use here.

I think the minimal fix is to just put the vma_lookup() back in the error case:

    --- a/mm/memory.c
    +++ b/mm/memory.c
    @@ -5592,6 +5592,7 @@ int __access_remote_vm(struct mm_struct *mm,
                 * Check if this is a VM_IO | VM_PFNMAP VMA, which
                 * we can access using slightly different code.
                 */
    +           vma = vma_lookup(mm, addr);
                if (!vma)
                        break;
                if (vma->vm_ops && vma->vm_ops->access)

and I'll commit that fix for now. Anybody who disagrees, please holler.

                 Linus