netdev - Re: [syzbot] general protection fault in legacy_parse

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: <61bf6b11-80f8-839e-4ae7-54c2c6021ed5@schaufler-ca.com>
Date:   Mon, 30 Aug 2021 07:25:15 -0700
From:   Casey Schaufler <casey@...aufler-ca.com>
To:     Christian Brauner <christian.brauner@...ntu.com>,
        syzbot <syzbot+d1e3b1d92d25abf97943@...kaller.appspotmail.com>
Cc:     andriin@...com, ast@...nel.org, bpf@...r.kernel.org,
        daniel@...earbox.net, dhowells@...hat.com, dvyukov@...gle.com,
        jmorris@...ei.org, kafai@...com, kpsingh@...gle.com,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-security-module@...r.kernel.org, netdev@...r.kernel.org,
        paul@...l-moore.com, selinux@...r.kernel.org,
        songliubraving@...com, stephen.smalley.work@...il.com,
        syzkaller-bugs@...glegroups.com, tonymarislogistics@...dex.com,
        viro@...iv.linux.org.uk, yhs@...com,
        Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [syzbot] general protection fault in legacy_parse_param

On 8/30/2021 5:23 AM, Christian Brauner wrote:
> On Fri, Aug 27, 2021 at 07:11:18PM -0700, syzbot wrote:
>> syzbot has bisected this issue to:
>>
>> commit 54261af473be4c5481f6196064445d2945f2bdab
>> Author: KP Singh <kpsingh@...gle.com>
>> Date:   Thu Apr 30 15:52:40 2020 +0000
>>
>>     security: Fix the default value of fs_context_parse_param hook
>>
>> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=160c5d75300000
>> start commit:   77dd11439b86 Merge tag 'drm-fixes-2021-08-27' of git://ano..
>> git tree:       upstream
>> final oops:     https://syzkaller.appspot.com/x/report.txt?x=150c5d75300000
>> console output: https://syzkaller.appspot.com/x/log.txt?x=110c5d75300000
>> kernel config:  https://syzkaller.appspot.com/x/.config?x=2fd902af77ff1e56
>> dashboard link: https://syzkaller.appspot.com/bug?extid=d1e3b1d92d25abf97943
>> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=126d084d300000
>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=16216eb1300000
>>
>> Reported-by: syzbot+d1e3b1d92d25abf97943@...kaller.appspotmail.com
>> Fixes: 54261af473be ("security: Fix the default value of fs_context_parse_param hook")
>>
>> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
> So ok, this seems somewhat clear now. When smack and 
> CONFIG_BPF_LSM=y
> is selected the bpf LSM will register NOP handlers including
>
> bpf_lsm_fs_context_fs_param()
>
> for the
>
> fs_context_fs_param
>
> LSM hook. The bpf LSM runs last, i.e. after smack according to:
>
> CONFIG_LSM="landlock,lockdown,yama,safesetid,integrity,tomoyo,smack,bpf"
>
> in the appended config. The smack hook runs and sets
>
> param->string = NULL
>
> then the bpf NOP handler runs returning -ENOPARM indicating to the vfs
> parameter parser that this is not a security module option so it should
> proceed processing the parameter subsequently causing the crash because
> param->string is not allowed to be NULL (Which the vfs parameter parser
> verifies early in fsconfig().).

The security_fs_context_parse_param() function is incorrectly
implemented using the call_int_hook() macro. It should return
zero if any of the modules return zero. It does not follow the
usual failure model of LSM hooks. It could be argued that the
code was fine before the addition of the BPF hook, but it was
going to fail as soon as any two security modules provided
mount options.

Regardless, I will have a patch later today. Thank you for
tracking this down.

>
> If you take the appended syzkaller config and additionally select
> kprobes you can observe this by registering bpf kretprobes for:
> security_fs_context_parse_param()
> smack_fs_context_parse_param()
> bpf_lsm_fs_context_parse_param()
> in different terminal windows and then running the syzkaller provided
> reproducer:
>
> root@...vm:~# bpftrace -e 'kretprobe:smack_fs_context_parse_param { printf("returned: %d\n", retval); }'
> Attaching 1 probe...
> returned: 0
>
> root@...vm:~# bpftrace -e 'kretprobe:bpf_lsm_fs_context_parse_param { printf("returned: %d\n", retval); }'
> Attaching 1 probe...
> returned: -519
>
> root@...vm:~# bpftrace -e 'kretprobe:security_fs_context_parse_param { printf("returned: %d\n", retval); }'
> Attaching 1 probe...
> returned: -519
>
> ^^^^^
> This will ultimately tell the vfs to move on causing the crash because
> param->string is null at that point.
>
> Unless I missed something why that can't happen.
>
> Christian