syzbot <syzbot+9b82859567f2e50c123e@xxxxxxxxxxxxxxxxxxxxxxxxx> 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?
