[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d8a4e959-f3ee-252c-5d1c-42407a8e29e8@kernel.dk>
Date: Fri, 15 Jul 2022 15:25:36 -0600
From: Jens Axboe <axboe@...nel.dk>
To: Marek Szyprowski <m.szyprowski@...sung.com>,
Dylan Yudaken <dylany@...com>,
Pavel Begunkov <asml.silence@...il.com>, davem@...emloft.net,
edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
io-uring@...r.kernel.org
Cc: netdev@...r.kernel.org, Kernel-team@...com
Subject: Re: [PATCH v3 for-next 2/3] net: copy from user before calling
__get_compat_msghdr
On 7/15/22 2:58 PM, Marek Szyprowski wrote:
> Hi,
>
> On 15.07.2022 22:37, Jens Axboe wrote:
>> On 7/15/22 2:28 PM, Marek Szyprowski wrote:
>>> On 14.07.2022 13:02, Dylan Yudaken wrote:
>>>> this is in preparation for multishot receive from io_uring, where it needs
>>>> to have access to the original struct user_msghdr.
>>>>
>>>> functionally this should be a no-op.
>>>>
>>>> Acked-by: Paolo Abeni <pabeni@...hat.com>
>>>> Signed-off-by: Dylan Yudaken <dylany@...com>
>>> This patch landed in linux next-20220715 as commit 1a3e4e94a1b9 ("net:
>>> copy from user before calling __get_compat_msghdr"). Unfortunately it
>>> causes a serious regression on the ARM64 based Khadas VIM3l board:
>>>
>>> Unable to handle kernel access to user memory outside uaccess routines
>>> at virtual address 00000000ffc4a5c8
>>> Mem abort info:
>>> ESR = 0x000000009600000f
>>> EC = 0x25: DABT (current EL), IL = 32 bits
>>> SET = 0, FnV = 0
>>> EA = 0, S1PTW = 0
>>> FSC = 0x0f: level 3 permission fault
>>> Data abort info:
>>> ISV = 0, ISS = 0x0000000f
>>> CM = 0, WnR = 0
>>> user pgtable: 4k pages, 48-bit VAs, pgdp=0000000001909000
>>> [00000000ffc4a5c8] pgd=0800000001a7b003, p4d=0800000001a7b003,
>>> pud=0800000001a0e003, pmd=0800000001913003, pte=00e800000b9baf43
>>> Internal error: Oops: 9600000f [#1] PREEMPT SMP
>>> Modules linked in:
>>> CPU: 0 PID: 247 Comm: systemd-udevd Not tainted 5.19.0-rc6+ #12437
>>> Hardware name: Khadas VIM3L (DT)
>>> pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
>>> pc : get_compat_msghdr+0xd0/0x1b0
>>> lr : get_compat_msghdr+0xcc/0x1b0
>>> ...
>>> Call trace:
>>> get_compat_msghdr+0xd0/0x1b0
>>> ___sys_sendmsg+0xd0/0xe0
>>> __sys_sendmsg+0x68/0xc4
>>> __arm64_compat_sys_sendmsg+0x28/0x3c
>>> invoke_syscall+0x48/0x114
>>> el0_svc_common.constprop.0+0x60/0x11c
>>> do_el0_svc_compat+0x1c/0x50
>>> el0_svc_compat+0x58/0x100
>>> el0t_32_sync_handler+0x90/0x140
>>> el0t_32_sync+0x190/0x194
>>> Code: d2800382 9100f3e0 97d9be02 b5fffd60 (b9401a60)
>>> ---[ end trace 0000000000000000 ]---
>>>
>>> This happens only on the mentioned board, other my ARM64 test boards
>>> boot fine with next-20220715. Reverting this commit, together with
>>> 2b0b67d55f13 ("fix up for "io_uring: support multishot in recvmsg"") and
>>> a8b38c4ce724 ("io_uring: support multishot in recvmsg") due to compile
>>> dependencies on top of next-20220715 fixes the issue.
>>>
>>> Let me know how I can help fixing this issue.
>> How are you reproducing this?
>
> This happens always during system boot on the mentioned board, when udev
> starts discovering devices. The complete boot log is here:
>
> https://pastebin.com/i8WzFzcx
Does this help?
diff --git a/net/compat.c b/net/compat.c
index 513aa9a3fc64..ed880729d159 100644
--- a/net/compat.c
+++ b/net/compat.c
@@ -89,7 +89,7 @@ int get_compat_msghdr(struct msghdr *kmsg,
if (copy_from_user(&msg, umsg, sizeof(*umsg)))
return -EFAULT;
- err = __get_compat_msghdr(kmsg, umsg, save_addr);
+ err = __get_compat_msghdr(kmsg, &msg, save_addr);
if (err)
return err;
--
Jens Axboe
Powered by blists - more mailing lists