linux-kernel - Re: Regression: NULL pointer dereference after NFS_V4_2_READ

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]

Date:   Sun, 12 Feb 2023 09:05:48 -0500
From:   Anna Schumaker <schumaker.anna@...il.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     Trond Myklebust <trondmy@...merspace.com>,
        Anna Schumaker <Anna.Schumaker@...app.com>,
        linux-nfs <linux-nfs@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "regressions@...ts.linux.dev" <regressions@...ts.linux.dev>
Subject: Re: Regression: NULL pointer dereference after NFS_V4_2_READ_PLUS
 (commit 7fd461c47)

On Sat, Feb 11, 2023 at 6:23 AM Krzysztof Kozlowski
<krzysztof.kozlowski@...aro.org> wrote:
>
> On 10/02/2023 21:55, Anna Schumaker wrote:
> > Hi Krzysztof,
> >
> > On Fri, Feb 10, 2023 at 3:53 AM Krzysztof Kozlowski
> > <krzysztof.kozlowski@...aro.org> wrote:
> >>
> >> On 10/02/2023 09:41, Krzysztof Kozlowski wrote:
> >>>
> >>>
> >>>>
> >>>> I was also wondering if it would be possible to turn on KASAN in your
> >>>> kernel, which should give us a little more info?
> >>>
> >>> I'll try with KASAN.
> >>
> >> Not much from the KASAN, except that kernel
> >> continues to boot and runs:
> >>
> >> [   44.722846] vdd_vmem: disabling
> >> [   44.793465] systemd[1]: Hostname set to <odroidhc1>.
> >> [   45.357929] systemd[1]: bpf-lsm: BPF LSM hook not enabled in the kernel, BPF LSM not supported
> >> [   45.980476] ==================================================================
> >> [   45.986372] BUG: KASAN: null-ptr-deref in xdr_inline_decode+0x140/0x200
> >> [   45.992929] Read of size 4092 at addr 00000004 by task kworker/u16:3/71
> >> [   45.999513]
> >> [   46.000940] CPU: 6 PID: 71 Comm: kworker/u16:3 Not tainted 6.2.0-rc7-00018-g0983f6bf2bfc #222
> >> [   46.009504] Hardware name: Samsung Exynos (Flattened Device Tree)
> >> [   46.015542] Workqueue: rpciod rpc_async_schedule
> >> [   46.020123]  unwind_backtrace from show_stack+0x10/0x14
> >> [   46.025323]  show_stack from dump_stack_lvl+0x58/0x70
> >> [   46.030301]  dump_stack_lvl from kasan_report+0xa8/0xe0
> >> [   46.035501]  kasan_report from kasan_check_range+0x94/0x1a0
> >> [   46.041048]  kasan_check_range from memcpy+0x28/0x68
> >> [   46.045985]  memcpy from xdr_inline_decode+0x140/0x200
> >> [   46.051098]  xdr_inline_decode from nfs4_xdr_dec_read_plus+0x298/0x5b8
> >> [   46.057602]  nfs4_xdr_dec_read_plus from call_decode+0x39c/0x530
> >> [   46.063581]  call_decode from __rpc_execute+0x1f4/0xc5c
> >> [   46.068776]  __rpc_execute from rpc_async_schedule+0x2c/0x4c
> >> [   46.074411]  rpc_async_schedule from process_one_work+0x51c/0xc44
> >> [   46.080478]  process_one_work from worker_thread+0x9c/0x7c0
> >> [   46.086022]  worker_thread from kthread+0x16c/0x1b8
> >> [   46.090872]  kthread from ret_from_fork+0x14/0x2c
> >> [   46.095550] Exception stack(0xf0ba3fb0 to 0xf0ba3ff8)
> >> [   46.100580] 3fa0:                                     00000000 00000000 00000000 00000000
> >> [   46.108740] 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> >> [   46.116885] 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000
> >> [   46.123461] ==================================================================
> >> [   46.130774] Disabling lock debugging due to kernel taint
> >> [   50.848579] systemd[1]: Queued start job for default target Graphical Interface.
> >> [   50.877068] systemd[1]: Created slice Slice /system/getty.
> >>
> >>
> >> Decoded stacktrace is (this is master branch):
> >>
> >> [   46.020123] unwind_backtrace from show_stack (arch/arm/kernel/traps.c:258)
> >> [   46.025323] show_stack from dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4))
> >> [   46.030301] dump_stack_lvl from kasan_report (mm/kasan/report.c:184 mm/kasan/report.c:519)
> >> [   46.035501] kasan_report from kasan_check_range (mm/kasan/generic.c:173 mm/kasan/generic.c:189)
> >> [   46.041048] kasan_check_range from memcpy (mm/kasan/shadow.c:65)
> >> [   46.045985] memcpy from xdr_inline_decode (net/sunrpc/xdr.c:1419 net/sunrpc/xdr.c:1454)
> >
> > Actually, this part is really useful. net/sunrpc/xdr.c:1419 points to
> > the memcpy in xdr_copy_to_scratch(), which has me wondering if I'm
> > incorrectly setting up the xdr scratch buffer that READ_PLUS uses for
> > decoding. Can you try this patch and let me know if it helps?
> >
> > From ac2d6c501dbcdb306480edaee625b5496f1fb4f5 Mon Sep 17 00:00:00 2001
> > From: Anna Schumaker <Anna.Schumaker@...app.com>
> > Date: Fri, 10 Feb 2023 15:50:22 -0500
> > Subject: [PATCH] NFSv4.2: Rework scratch handling for READ_PLUS
> >
>
> Patch is corrupted - maybe mail program reformatted it when sending:
>
> Applying: NFSv4.2: Rework scratch handling for READ_PLUS
> error: corrupt patch at line 12
> Patch failed at 0001 NFSv4.2: Rework scratch handling for READ_PLUS

That's weird. I wasn't expecting gmail to reformat the patch but I
guess it did. I've added it as an attachment so that shouldn't happen
again.

Sorry about that!
Anna

>
>
> Best regards,
> Krzysztof
>

View attachment "0001-NFSv4.2-Rework-scratch-handling-for-READ_PLUS.patch" of type "text/x-patch" (3664 bytes)