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

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: <yt9d8rb44cbe.fsf@linux.ibm.com>
Date:   Tue, 25 Jul 2023 10:36:53 +0200
From:   Sven Schnelle <svens@...ux.ibm.com>
To:     syzbot <syzbot+9b82859567f2e50c123e@...kaller.appspotmail.com>
Cc:     akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, syzkaller-bugs@...glegroups.com,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>,
        David Howells <dhowells@...hat.com>,
        linux-crypto@...r.kernel.org
Subject: Re: [syzbot] [mm?] WARNING in try_grab_page

syzbot <syzbot+9b82859567f2e50c123e@...kaller.appspotmail.com> writes:

> [..]
> ------------[ cut here ]------------
> WARNING: CPU: 1 PID: 20384 at mm/gup.c:229 __lse_atomic_add arch/arm64/include/asm/atomic_lse.h:27 [inline]
> WARNING: CPU: 1 PID: 20384 at mm/gup.c:229 arch_atomic_add arch/arm64/include/asm/atomic.h:28 [inline]
> WARNING: CPU: 1 PID: 20384 at mm/gup.c:229 raw_atomic_add include/linux/atomic/atomic-arch-fallback.h:537 [inline]
> WARNING: CPU: 1 PID: 20384 at mm/gup.c:229 atomic_add include/linux/atomic/atomic-instrumented.h:105 [inline]
> WARNING: CPU: 1 PID: 20384 at mm/gup.c:229 try_grab_page+0x108/0x160 mm/gup.c:252
> Modules linked in:
> CPU: 1 PID: 20384 Comm: syz-executor.1 Not tainted 6.4.0-syzkaller-04247-g3a8a670eeeaa #0
> Hardware name: linux,dummy-virt (DT)
> pstate: a0400009 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> pc : try_grab_page+0x108/0x160 mm/gup.c:229
> lr : follow_page_pte+0x174/0x3e4 mm/gup.c:651
> [..]
> Call trace:
>  __lse_atomic_add arch/arm64/include/asm/atomic_lse.h:27 [inline]
>  arch_atomic_add arch/arm64/include/asm/atomic.h:28 [inline]
>  raw_atomic_add include/linux/atomic/atomic-arch-fallback.h:537 [inline]
>  atomic_add include/linux/atomic/atomic-instrumented.h:105 [inline]
>  try_grab_page+0x108/0x160 mm/gup.c:252
>  follow_pmd_mask mm/gup.c:734 [inline]
>  follow_pud_mask mm/gup.c:765 [inline]
>  follow_p4d_mask mm/gup.c:782 [inline]
>  follow_page_mask+0x12c/0x2e4 mm/gup.c:839
>  __get_user_pages+0x174/0x30c mm/gup.c:1217
>  __get_user_pages_locked mm/gup.c:1448 [inline]
>  __gup_longterm_locked+0x94/0x8f4 mm/gup.c:2142
>  internal_get_user_pages_fast+0x970/0xb60 mm/gup.c:3140
>  pin_user_pages_fast+0x4c/0x60 mm/gup.c:3246
>  iov_iter_extract_user_pages lib/iov_iter.c:1768 [inline]
>  iov_iter_extract_pages+0xc8/0x54c lib/iov_iter.c:1831
>  extract_user_to_sg lib/scatterlist.c:1123 [inline]
>  extract_iter_to_sg lib/scatterlist.c:1349 [inline]
>  extract_iter_to_sg+0x26c/0x6fc lib/scatterlist.c:1339
>  hash_sendmsg+0xc0/0x43c crypto/algif_hash.c:117
>  sock_sendmsg_nosec net/socket.c:725 [inline]
>  sock_sendmsg+0x54/0x60 net/socket.c:748
>  ____sys_sendmsg+0x270/0x2ac net/socket.c:2494
>  ___sys_sendmsg+0x80/0xdc net/socket.c:2548
>  __sys_sendmsg+0x68/0xc4 net/socket.c:2577
>  __do_sys_sendmsg net/socket.c:2586 [inline]
>  __se_sys_sendmsg net/socket.c:2584 [inline]
>  __arm64_sys_sendmsg+0x24/0x30 net/socket.c:2584
>  __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]
>  invoke_syscall+0x48/0x114 arch/arm64/kernel/syscall.c:52
>  el0_svc_common.constprop.0+0x44/0xe4 arch/arm64/kernel/syscall.c:142
>  do_el0_svc+0x38/0xa4 arch/arm64/kernel/syscall.c:191
>  el0_svc+0x2c/0xb0 arch/arm64/kernel/entry-common.c:647
>  el0t_64_sync_handler+0xc0/0xc4 arch/arm64/kernel/entry-common.c:665
>  el0t_64_sync+0x19c/0x1a0 arch/arm64/kernel/entry.S:591
> ---[ end trace 0000000000000000 ]---

I looked into this issue. What syzkaller is doing is opening an AF_ALG
socket, and sending a large message which will eventually end in -EFAULT.
Looking at the code in crypto/algif_hash.c i see that hash_sendmsg is
calling extract_iter_to_sg() -> extract_user_to_sg(). In the -EFAULT
case, this function is calling put_page(), which looks like a leftover
from the old pinning interface. I think this should be a
unpin_user_page() call now.

However, hash_sendmsg() also unpins via af_alg_free_sg() in the error
path. From an API perspective, i would prefer if extract_user_to_sg()
does the unpinning on error. Any thoughts?