linux-kernel - Re: [PATCH] mm: Fix __wp_page_copy_user fallback path for remote mm

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: <20241104194242.2456fbd25cd027b338c07855@linux-foundation.org>
Date: Mon, 4 Nov 2024 19:42:42 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Asahi Lina <lina@...hilina.net>
Cc: Sergio Lopez Pascual <slp@...hat.com>, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org, asahi@...ts.linux.dev, Jia He
 <justin.he@....com>, Yibo Cai <Yibo.Cai@....com>, "Kirill A. Shutemov"
 <kirill.shutemov@...ux.intel.com>, Catalin Marinas
 <catalin.marinas@....com>
Subject: Re: [PATCH] mm: Fix __wp_page_copy_user fallback path for remote mm

On Sat, 2 Nov 2024 06:18:54 +0900 Asahi Lina <lina@...hilina.net> wrote:

> 
> 
> On 11/2/24 4:07 AM, Andrew Morton wrote:
> > On Fri, 01 Nov 2024 21:08:02 +0900 Asahi Lina <lina@...hilina.net> wrote:
> > 
> >> If the source page is a PFN mapping, we copy back from userspace.
> >> However, if this fault is a remote access, we cannot use
> >> __copy_from_user_inatomic. Instead, use access_remote_vm() in this case.
> >>
> >> Fixes WARN and incorrect zero-filling when writing to CoW mappings in
> >> a remote process, such as when using gdb on a binary present on a DAX
> >> filesystem.
> >>
> >> [  143.683782] ------------[ cut here ]------------
> >> [  143.683784] WARNING: CPU: 1 PID: 350 at mm/memory.c:2904 __wp_page_copy_user+0x120/0x2bc
> >>
> >> ...
> >>
> > 
> > Thanks.  I assume we should backport this into earlier kernels?
> > 
> > If so, a Fixes: target is desired, to tell people how far back in time
> > it should be ported.
> 
> I think so? I'm not sure how back the bug goes though, possibly a long
> time...
> 
> > I think it's
> > 
> > 83d116c53058 ("mm: fix double page fault on arm64 if PTE_AF is cleared").
> 
> That doesn't sound right. The old code prior to the patch still had the
> __copy_from_user_inatomic() fallback path so it should still have the
> same problem. That fallback goes back to:
> 
>   6aab341e0a28 ("mm: re-architect the VM_UNPAGED logic")
> 
> But the ptrace code back then doesn't seem to be using that codepath at
> all, so that's meaningless. I think this is the proper tag:
> 
>   3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
> 
> That's when GUP started working for DAX mappings at all, and if my
> reading of the code is correct, at that point do_wp_page() was only
> grabbing the struct page for normal pages to pass to wp_page_copy()
> (triggering the fallback path for DAX mappings). The code has moved
> around a lot today but has the same logic, so I think it's been broken
> since then.

Cool, thanks.

> Should I resend it with the Fixes tag?

That's OK, I edited the mm.git changelog.