linux-kernel - Re: [syzbot] [mm?] WARNING in unmap_page

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: <a8349273-c512-4d23-bf85-5812d2a007d1@redhat.com>
Date:   Thu, 16 Nov 2023 10:19:13 +0100
From:   David Hildenbrand <david@...hat.com>
To:     Andrew Morton <akpm@...ux-foundation.org>,
        syzbot <syzbot+7ca4b2719dc742b8d0a4@...kaller.appspotmail.com>,
        Muhammad Usama Anjum <usama.anjum@...labora.com>
Cc:     linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, syzkaller-bugs@...glegroups.com,
        usama.anjum@...labora.com, wangkefeng.wang@...wei.com,
        Peter Xu <peterx@...hat.com>
Subject: Re: [syzbot] [mm?] WARNING in unmap_page_range (2)

On 15.11.23 23:00, Andrew Morton wrote:
> On Wed, 15 Nov 2023 05:32:19 -0800 syzbot <syzbot+7ca4b2719dc742b8d0a4@...kaller.appspotmail.com> wrote:
> 
>> Hello,
>>
>> syzbot found the following issue on:
>>
>> HEAD commit:    ac347a0655db Merge tag 'arm64-fixes' of git://git.kernel.o..
>> git tree:       upstream
>> console+strace: https://syzkaller.appspot.com/x/log.txt?x=15ff3057680000
>> kernel config:  https://syzkaller.appspot.com/x/.config?x=287570229f5c0a7c
>> dashboard link: https://syzkaller.appspot.com/bug?extid=7ca4b2719dc742b8d0a4
>> compiler:       gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
>> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=162a25ff680000
>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=13d62338e80000
>>
>> Downloadable assets:
>> disk image: https://storage.googleapis.com/syzbot-assets/00e30e1a5133/disk-ac347a06.raw.xz
>> vmlinux: https://storage.googleapis.com/syzbot-assets/07c43bc37935/vmlinux-ac347a06.xz
>> kernel image: https://storage.googleapis.com/syzbot-assets/c6690c715398/bzImage-ac347a06.xz
>>
>> The issue was bisected to:
>>
>> commit 12f6b01a0bcbeeab8cc9305673314adb3adf80f7
>> Author: Muhammad Usama Anjum <usama.anjum@...labora.com>
>> Date:   Mon Aug 21 14:15:15 2023 +0000
>>
>>      fs/proc/task_mmu: add fast paths to get/clear PAGE_IS_WRITTEN flag
> 
> Thanks.  The bisection is surprising, but the mentioned patch does
> mess with pagemap.
> 
> How about we add this?
> 
> From: Andrew Morton <akpm@...ux-foundation.org>
> Subject: mm/memory.c:zap_pte_range() print bad swap entry
> Date: Wed Nov 15 01:54:18 PM PST 2023
> 
> We have a report of this WARN() triggering.  Let's print the offending
> swp_entry_t to help diagnosis.
> 
> Link: https://lkml.kernel.org/r/000000000000b0e576060a30ee3b@google.com
> Cc: Muhammad Usama Anjum <usama.anjum@...labora.com>
> Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
> ---
> 
>   mm/memory.c |    1 +
>   1 file changed, 1 insertion(+)
> 
> --- a/mm/memory.c~a
> +++ a/mm/memory.c
> @@ -1521,6 +1521,7 @@ static unsigned long zap_pte_range(struc
>   				continue;
>   		} else {
>   			/* We should have covered all the swap entry types */
> +			pr_alert("unrecognized swap entry 0x%lx\n", entry.val);
>   			WARN_ON_ONCE(1);
>   		}
>   		pte_clear_not_present_full(mm, addr, pte, tlb->fullmm);
> _
> 

I'm curious if

1) make_uffd_wp_pte() won't end up overwriting existing pte markers, for
    example, if PTE_MARKER_POISONED is set. [unrelated to this bug]

2) We get the error on arm64, which does *not* support uffd-wp. Do we
    maybe end up calling make_uffd_wp_pte() and place a pte marker, even
    though we don't have CONFIG_PTE_MARKER_UFFD_WP?


static inline bool pte_marker_entry_uffd_wp(swp_entry_t entry)
{
#ifdef CONFIG_PTE_MARKER_UFFD_WP
	return is_pte_marker_entry(entry) &&
	    (pte_marker_get(entry) & PTE_MARKER_UFFD_WP);
#else
	return false;
#endif
}

Will always return false without CONFIG_PTE_MARKER_UFFD_WP.

But make_uffd_wp_pte() might just happily place an entry. Hm.


The following might fix the problem:

diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 51e0ec658457..ae1cf19918d3 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -1830,8 +1830,10 @@ static void make_uffd_wp_pte(struct 
vm_area_struct *vma,
                 ptent = pte_swp_mkuffd_wp(ptent);
                 set_pte_at(vma->vm_mm, addr, pte, ptent);
         } else {
+#ifdef CONFIG_PTE_MARKER_UFFD_WP
                 set_pte_at(vma->vm_mm, addr, pte,
                            make_pte_marker(PTE_MARKER_UFFD_WP));
+#endif
         }
  }


But I am *pretty* sure that that whole machinery should be fenced off. 
It does make 0 sense to mess with uffd-wp if there is no uffd-wp support.

-- 
Cheers,

David / dhildenb