All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: alvalan9@foxmail.com
Cc: stable@vger.kernel.org, david@redhat.com,
	Liam.Howlett@oracle.com, cl@linux.com, akpm@linux-foundation.org
Subject: Re: [PATCH 6.1.y] mm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MM
Date: Sun, 12 Jan 2025 11:09:43 +0100	[thread overview]
Message-ID: <2025011245-playset-transform-d82f@gregkh> (raw)
In-Reply-To: <tencent_A6390C6B4311AD460DE2C7BDE489B515CE06@qq.com>

On Sat, Jan 11, 2025 at 10:15:20PM +0800, alvalan9@foxmail.com wrote:
> From: David Hildenbrand <david@redhat.com>
> 
> [ Upstream commit 091c1dd2d4df6edd1beebe0e5863d4034ade9572 ]
> 
> We currently assume that there is at least one VMA in a MM, which isn't
> true.
> 
> So we might end up having find_vma() return NULL, to then de-reference
> NULL.  So properly handle find_vma() returning NULL.
> 
> This fixes the report:
> 
> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI
> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
> CPU: 1 UID: 0 PID: 6021 Comm: syz-executor284 Not tainted 6.12.0-rc7-syzkaller-00187-gf868cd251776 #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024
> RIP: 0010:migrate_to_node mm/mempolicy.c:1090 [inline]
> RIP: 0010:do_migrate_pages+0x403/0x6f0 mm/mempolicy.c:1194
> Code: ...
> RSP: 0018:ffffc9000375fd08 EFLAGS: 00010246
> RAX: 0000000000000000 RBX: ffffc9000375fd78 RCX: 0000000000000000
> RDX: ffff88807e171300 RSI: dffffc0000000000 RDI: ffff88803390c044
> RBP: ffff88807e171428 R08: 0000000000000014 R09: fffffbfff2039ef1
> R10: ffffffff901cf78f R11: 0000000000000000 R12: 0000000000000003
> R13: ffffc9000375fe90 R14: ffffc9000375fe98 R15: ffffc9000375fdf8
> FS:  00005555919e1380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00005555919e1ca8 CR3: 000000007f12a000 CR4: 00000000003526f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
>  <TASK>
>  kernel_migrate_pages+0x5b2/0x750 mm/mempolicy.c:1709
>  __do_sys_migrate_pages mm/mempolicy.c:1727 [inline]
>  __se_sys_migrate_pages mm/mempolicy.c:1723 [inline]
>  __x64_sys_migrate_pages+0x96/0x100 mm/mempolicy.c:1723
>  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
>  do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> 
> [akpm@linux-foundation.org: add unlikely()]
> Link: https://lkml.kernel.org/r/20241120201151.9518-1-david@redhat.com
> Fixes: 39743889aaf7 ("[PATCH] Swap Migration V5: sys_migrate_pages interface")
> Signed-off-by: David Hildenbrand <david@redhat.com>
> Reported-by: syzbot+3511625422f7aa637f0d@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/lkml/673d2696.050a0220.3c9d61.012f.GAE@google.com/T/
> Reviewed-by: Liam R. Howlett <Liam.Howlett@Oracle.com>
> Reviewed-by: Christoph Lameter <cl@linux.com>
> Cc: Liam R. Howlett <Liam.Howlett@Oracle.com>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> [ Remove mmap_read_unlock() because mmap_read_lock() is not called before find_vma() ]
> Signed-off-by: Alva Lan <alvalan9@foxmail.com>
> ---
>  mm/mempolicy.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/mm/mempolicy.c b/mm/mempolicy.c
> index 399d8cb48813..d67dd0f503fa 100644
> --- a/mm/mempolicy.c
> +++ b/mm/mempolicy.c
> @@ -1068,6 +1068,9 @@ static int migrate_to_node(struct mm_struct *mm, int source, int dest,
>  	 * space range and MPOL_MF_DISCONTIG_OK, this call can not fail.
>  	 */
>  	vma = find_vma(mm, 0);
> +	if (unlikely(!vma)) {
> +		return 0;
> +	}	

Please follow the proper kernel coding style when doing backports, you
have {} here where not needed, AND you have trailing whitespace :(

Also, I'd like for someone on the reviewed-by chain to review that this
backport actually is ok before applying it (after you fix it up...)

thanks,

greg k-h

      parent reply	other threads:[~2025-01-12 10:09 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-11 14:15 [PATCH 6.1.y] mm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MM alvalan9
2025-01-11 19:04 ` Sasha Levin
2025-01-12 10:09 ` Greg KH [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2025011245-playset-transform-d82f@gregkh \
    --to=greg@kroah.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=alvalan9@foxmail.com \
    --cc=cl@linux.com \
    --cc=david@redhat.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.