From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0ED1BE77188 for ; Thu, 2 Jan 2025 17:32:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9B21D6B00E3; Thu, 2 Jan 2025 12:32:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 962226B00E4; Thu, 2 Jan 2025 12:32:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 851516B00E5; Thu, 2 Jan 2025 12:32:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 679156B00E3 for ; Thu, 2 Jan 2025 12:32:11 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 2BCBB1201D5 for ; Thu, 2 Jan 2025 17:32:11 +0000 (UTC) X-FDA: 82963204254.04.0CC78AA Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf13.hostedemail.com (Postfix) with ESMTP id 6170620006 for ; Thu, 2 Jan 2025 17:31:19 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="wYIf7nV/"; spf=none (imf13.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1735839082; a=rsa-sha256; cv=none; b=yKR/MxPYUs0a8u9q2L0I8r3YySIZUKYyLyGzzdguvub9vPcIKUU7UAnVB0oJctqiQkx+KI lg6k0wpkgK3BGXqWkhGJJVKT2ZI1Ap55tAs2csLZ+roEKzywnj5NizJ8evYdV4YXoRqLPe ef8sjHkXwNim1YoEUJWR1R94J3XFpWo= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="wYIf7nV/"; spf=none (imf13.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1735839082; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=EFnZ4kmuWDqgG86ivXX1otK3X65vd27IqMmKMPjvFgg=; b=IYp2RlIL6xGKFpSiF60AVznT/iauRX6bM8leHM0B6Nr4D9u1W/6afNFkQ1L1vQs1p9dT/4 K3Jup+i14e6kd/cGJMrfvsancCxt67ODcUiLlE+U6IRZ0qXR7s8oKBfNEDISFQZaMJBX8+ Srg5qMifn6otoFvXI3I0+pyt7fuLJk8= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=EFnZ4kmuWDqgG86ivXX1otK3X65vd27IqMmKMPjvFgg=; b=wYIf7nV/8U4h1KKvn39J+PmCv5 lgGnsByqA2y9pGDbN6sSqpKtC27ZOqDmCb6xFD2wCYs6jmjQ33Kfj3vT6w7i7q3h7VfOjjwNyCGAn Jpx607gdv1sofPw9p6gd/dCYZEJJLI2m/BzVpH+sHEpMH6AOfYtfo5wlu7a0nUMI12uvgdCMzb78y zlqbV10o5ibsq/0eSaAzAicw99lawI47sTNxM5iv4/Tq+Kq5a5uWzn3LXN14lp4okgZ2aOgA5l15F 5YDOi+s1cJMf/xnE2HAU/hyYjizn6l36kkfGdAhp1bHmQGRFGGxL4c9Y3H+Ze5IhqPQMeJBahNPqe a31SezuA==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1tTP2z-000000015hv-2CMq; Thu, 02 Jan 2025 17:31:50 +0000 Date: Thu, 2 Jan 2025 17:31:48 +0000 From: Matthew Wilcox To: Lorenzo Stoakes Cc: syzbot , Liam.Howlett@oracle.com, akpm@linux-foundation.org, jannh@google.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, syzkaller-bugs@googlegroups.com, vbabka@suse.cz Subject: Re: [syzbot] [mm?] WARNING in vma_merge_existing_range Message-ID: References: <6774c98f.050a0220.25abdd.0991.GAE@google.com> <11dee0ef-1707-4b90-be2e-56f484642a7a@lucifer.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11dee0ef-1707-4b90-be2e-56f484642a7a@lucifer.local> X-Rspamd-Queue-Id: 6170620006 X-Stat-Signature: funz4mb46in57rts85rucwnnr1or4wju X-Rspam-User: X-Rspamd-Server: rspam09 X-HE-Tag: 1735839079-53515 X-HE-Meta: U2FsdGVkX1+eruCXXz5G4i8X4oU/ecuTwB8psK3cQ4bzObU7PG1nV0gc1C00hiXuv+6TQT6wqnuio1c8qdWWM0wcW5+hQHLS0PhoDISIzMP5DpEaQvuMGrxOlIL7yap9xNaQLfO3PQ6R7VRvamvH67Cy9L83LgA+YaCWi7hs8OvJPbc2pCdViZpqIRetbbgeqOhYTJCtf8ymJP5c7yPRTQK5NSo5tR2BrZ8FpQqwpvdMrAWPnChIjgCl6QGRXpp1VX3v/HTArahIDAEE/qNgPv4Ed9LILHFXIchyqbglucqGwYCtt4egD1o0UcsReP5RbnCmb5UQmZJxLf+0ykkIT1ESz/krbAPv1AgdKzmFdQDToItGmnPag/m9/IF0ix+3/JBBys/tqFIVqTurKiy3hW4fz6z+vn7/ykB+oGwX8f/SNOzAy1DeoGnu5P8wN0H6gUVDUEM6KKudlNaN3Y0NiWJsQXM6VEe58/AnP4ieYCdYbirPk79qZwlS4tcDpMfQ8rUOajweUafgjyeky1QXCiRbV9NjP4tG6+CgnD3xXNsT58WmPIyDpqZj/EVt5UMbThlZeX2qocgvDFUal01gQ9uSqNQMppWvjdUyRHOIaOcZRekW1b6CzG6AFIuArn+EPwRq63VjTNmckaLj8vgyyRIKl0dp3mn2sYXERA1tOKfOg6uStZhSWBv9RVxlqdtvZQqnUYrhgY+1ENnmH7fCIV3n4qPdr0gcQG/3Qb3bG9HuBAXHnQjdASdv+dVHmGwS+12qappdgAmlVryH57TF+xWGZhZbTehZHgfn1tOLWQv8Vra2HYOBDYTZQS2c0rF3WNIRy4z80FxHX7JC4l6Mm8GezWhq5/qTkturxSJnOxv5K+VeVNkLM9I7kZ9ztlVqWzCyeOeYAR7aKZVyXxUoS2EQahGCfIpU5pYWnZuj8q57DAFLnbobtRYZvEcBYCjQlUPBBlxTRLXk4nSB8fp 4m9/n1u+ kshRJRkL3p/1PZwhVL2WTRGoG2dV1Yu+NaFbjg3NjS5mePwfjnu0PasjGwg8uMM+KElh/J5lh0IGXkmFS9xrDvqqZH1Hk/Q+QA9WGkBzW+e92CzN1mZx7MmunLKVxJWdufQuC/IxXIUAXMhXFKWudXUHbFDfF+ihTpdOxD4xpe8vPlrIRzqBfU9sX7ROEINBfj8hqAhoiXd6QBxFOdl3vlPxMVEVXfOe5kqhvsZgWftf1B8daKjluQsfUcGummKFwqzXWJbT1++OruYe28eLBo6kVbkv2rH0q3KAHc+PUkAN3NpyEPNtLKCfCBwTdFHHaGVOUkAoGiE3yjPsJ2ucQyButNq/cMnUzBeXOjrMhpMfNWGWOEKwkzewj2F9BBkr8bis5OFZZ9GU6xOtigekqBbI2xSNVTOJPCH+brYyRD8IPnKcEABbCw1h/HIKMLYK0ADYqZa+EW4taZ8EQmUdui6YilR1Sl9KXkQoOu/fLLysk/LAFKjRN1kiMHkiKzbXZmlqUIbB+2rADT8F6VVIsyNWpBFIUbBjDuYc3xiPMLjmUMn/r0Gcfi3WtsfClo4V0vKD2kNRfU+ue8ufvl4nFL+lEIITRrAz8Nel+God3/q2iJ2NKbE74a/1D610kaffkLluwh1/veZMR8Ns= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, Jan 02, 2025 at 10:25:49AM +0000, Lorenzo Stoakes wrote: > It'd be nice if syzbot could actually print the code that generates the > warning :) a nice-to-have perhaps. > > This is: > > VM_WARN_ON(start >= end); > > I suspect start == end, because start > end would be some drastic and > god-awful bug. > > > Modules linked in: > > CPU: 1 UID: 0 PID: 20504 Comm: syz.6.5485 Not tainted 6.13.0-rc4-syzkaller-00069-g8379578b11d5 #0 > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 > > RIP: 0010:vma_merge_existing_range+0x1145/0x16f0 mm/vma.c:734 > > Code: e8 20 24 0f 00 4d 2b 7d 00 4d 89 ec 48 8b 7c 24 38 e9 7f 01 00 00 e8 3a bc a8 ff 90 0f 0b 90 e9 a8 f1 ff ff e8 2c bc a8 ff 90 <0f> 0b 90 e9 0e f2 ff ff e8 1e bc a8 ff 90 0f 0b 90 4d 85 ed 0f 85 > > Be useful to get the kernel disassembly too :) > > Best guess wranging a python script and objdump: > > 0: e8 20 24 0f 00 call 0xf2425 > 5: 4d 2b 7d 00 sub 0x0(%r13),%r15 > 9: 4d 89 ec mov %r13,%r12 > c: 48 8b 7c 24 38 mov 0x38(%rsp),%rdi > 11: e9 7f 01 00 00 jmp 0x195 > 16: e8 3a bc a8 ff call 0xffffffffffa8bc55 > 1b: 90 nop > 1c: 0f 0b ud2 > 1e: 90 nop > 1f: e9 a8 f1 ff ff jmp 0xfffffffffffff1cc > 24: e8 2c bc a8 ff call 0xffffffffffa8bc55 > 29: 90 nop > 2a: <0f> 0b ud2 <-- presumably here? This is an undefined instruction... > 2c: 90 nop > 2d: e9 0e f2 ff ff jmp 0xfffffffffffff240 > 32: e8 1e bc a8 ff call 0xffffffffffa8bc55 > 37: 90 nop > 38: 0f 0b ud2 > 3a: 90 nop > 3b: 4d 85 ed test %r13,%r13 > 3e: 0f .byte 0xf > 3f: 85 .byte 0x85 > > Yeah this might be a mix of data and code somehow or just garbage? Not sure > there's anything discernable there unfortunately. There's scripts/decodecode which agrees with your hacky script. Indeed, ud2 is the trapping instruction, but that's expected because that's how BUG_ON / WARN_ON is implemented. > > RSP: 0018:ffffc9000ba274a0 EFLAGS: 00010293 > > RAX: ffffffff81f6b804 RBX: 0000000020c25000 RCX: ffff888060ad1e00 > > RDX: 0000000000000000 RSI: 0000000020c25000 RDI: 0000000020c25000 > > RBP: ffffc9000ba275f8 R08: ffffffff81f6aa0d R09: 00000000280000fa > > R10: ffffc9000ba27810 R11: fffff52001744f07 R12: 0000000020c25000 > > R13: ffff888069b666c8 R14: ffffc9000ba276a0 R15: ffff888068d0b1f0 > > FS: 0000000000000000(0000) GS:ffff8880b8700000(0063) knlGS:00000000f5116b40 > > CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 > > CR2: 00007fa9de2c0018 CR3: 000000006b562000 CR4: 00000000003526f0 I note that RBX, RSI, RDI and R12 all have the same value. That gives credence to your start == end hypothesis. And it's a plausible userspace VMA address. > > Call Trace: > > > > vma_modify+0x41/0x330 mm/vma.c:1514 > > Just passes through start, end (in vmg). > > > vma_modify_flags_name+0x3a6/0x430 mm/vma.c:1563 > > Just passes through start, end. > > > madvise_update_vma+0x2fe/0xc10 mm/madvise.c:159 > > Just passes through start, end. > > This means it was one of MADV_NORMAL, MADV_RANDOM, MADV_DONTFORK, > MADV_DOFORK, MADV_WIPEONFORK, MADV_KEEPONFORK, MADV_DONTDUMP, MADV_DODUMP, > MADV_MERGEABLE, MADV_UNMERGEABLE, MADV_HUGEPAGE, MADV_NOHUGEPAGE. > > Yeah we need better error handling here, because this report is just giving > us very little to go on especially for a non-repro. Will add to TODO. > > > madvise_vma_behavior mm/madvise.c:1325 [inline] > > Just passes through start, end. > > > madvise_walk_vmas mm/madvise.c:1497 [inline] > > OK here we find VMAs and walk them. > > We explicitly check for start >= send if start < vma->vm_start. > > I wonder if the visit() call is splitting the VMA which confuses the logic > here. > > s e > | | > v v > |-------------| > | | > |-------------| > > Split: > > s e > | | > v v > |--------|----| > | | | > |--------|----| > > prev = this VMA. > > if (prev && start < prev->vm_end) > start = prev->vm_end; > > So we end up with: > > > s,e > | > v > |--------|----| > | | | > |--------|----| > > tmp = vma->vm_end; > if (end < tmp) > tmp = end; > > That tmp assignment will reinstate the broken end > > And... boom. > > Let me check this out and see if I can trigger it. > > I may be missing some safeguard that prevents this... > > > > do_madvise+0x1e64/0x4d10 mm/madvise.c:1684 > > Here we explicitly check for start >= end: > > end = start + len; > if (end < start) > return -EINVAL; > > if (end == start) > return 0; > > So overflow is accounted for also. But since this is a 64-bit kernel not > really a concern. > > > __do_sys_madvise mm/madvise.c:1700 [inline] > > __se_sys_madvise mm/madvise.c:1698 [inline] > > __ia32_sys_madvise+0xa6/0xc0 mm/madvise.c:1698 > > do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] > > __do_fast_syscall_32+0xb4/0x110 arch/x86/entry/common.c:386 > > do_fast_syscall_32+0x34/0x80 arch/x86/entry/common.c:411 > > entry_SYSENTER_compat_after_hwframe+0x84/0x8e > > RIP: 0023:0xf7fc2579 > > Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 > > RSP: 002b:00000000f511655c EFLAGS: 00000206 ORIG_RAX: 00000000000000db > > RAX: ffffffffffffffda RBX: 0000000020c00000 RCX: 0000000000400000 > > RDX: 000000000000000e RSI: 0000000000000000 RDI: 0000000000000000 > > RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 > > R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000 > > R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 > > > > ---------------- > > Code disassembly (best guess), 2 bytes skipped: > > 0: 10 06 adc %al,(%rsi) > > 2: 03 74 b4 01 add 0x1(%rsp,%rsi,4),%esi > > 6: 10 07 adc %al,(%rdi) > > 8: 03 74 b0 01 add 0x1(%rax,%rsi,4),%esi > > c: 10 08 adc %cl,(%rax) > > e: 03 74 d8 01 add 0x1(%rax,%rbx,8),%esi > > 1e: 00 51 52 add %dl,0x52(%rcx) > > 21: 55 push %rbp > > 22: 89 e5 mov %esp,%ebp > > 24: 0f 34 sysenter > > 26: cd 80 int $0x80 > > * 28: 5d pop %rbp <-- trapping instruction > > 29: 5a pop %rdx > > 2a: 59 pop %rcx > > 2b: c3 ret > > 2c: 90 nop > > 2d: 90 nop > > 2e: 90 nop > > 2f: 90 nop > > 30: 90 nop > > 31: 90 nop > > 32: 90 nop > > 33: 90 nop > > 34: 90 nop > > 35: 90 nop > > 36: 90 nop > > 37: 90 nop > > 38: 90 nop > > 39: 90 nop > > 3a: 90 nop > > 3b: 90 nop > > 3c: 90 nop > > 3d: 90 nop > > > > > > --- > > This report is generated by a bot. It may contain errors. > > See https://goo.gl/tpsmEJ for more information about syzbot. > > syzbot engineers can be reached at syzkaller@googlegroups.com. > > > > syzbot will keep track of this issue. See: > > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. > > > > If the report is already addressed, let syzbot know by replying with: > > #syz fix: exact-commit-title > > > > If you want to overwrite report's subsystems, reply with: > > #syz set subsystems: new-subsystem > > (See the list of subsystem names on the web dashboard) > > > > If the report is a duplicate of another one, reply with: > > #syz dup: exact-subject-of-another-report > > > > If you want to undo deduplication, reply with: > > #syz undup >