linux-kernel - Re: [syzbot] BUG: unable to handle kernel paging request in percpu_counter_add

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>] [day] [month] [year] [list]

Message-ID: <6283cbe8-06ff-c355-2028-bd35087a7a32@intel.com>
Date:   Fri, 21 Oct 2022 11:31:48 +0800
From:   "Sun, Jiebin" <jiebin.sun@...el.com>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com,
        tim.c.chen@...ux.intel.com, jiebin.sun@...el.com
Subject: Re: [syzbot] BUG: unable to handle kernel paging request in
 percpu_counter_add_batch


On 1/1/1970 8:00 AM, Andrew Morton wrote:
> On Thu, 20 Oct 2022 19:24:40 -0700 syzbot
> <syzbot+96e659d35b9d6b541152@...kaller.appspotmail.com> wrote:
>
>> Hello,
>>
>> syzbot found the following issue on:
>>
>> HEAD commit:    aae703b02f92 Merge tag 'for-6.1-rc1-tag' of git://git.kern..
>> git tree:       upstream
>> console output:
>> https://syzkaller.appspot.com/x/log.txt?x=1686e478880000
>> kernel config:
>> https://syzkaller.appspot.com/x/.config?x=883de36878e6d869
>> dashboard link: https://syzkaller.appspot.com/bug?extid=96e659d35b9d6b541152
>> compiler:       aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for
> Debian) 2.35.2
>> userspace arch: arm
>>
>> Unfortunately, I don't have any reproducer for this issue yet.
>>
>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>> Reported-by: syzbot+96e659d35b9d6b541152@...kaller.appspotmail.com
>>
>> Unable to handle kernel paging request at virtual address
>> ffff70000b978a00
>> KASAN: maybe wild-memory-access in range
>> [0xffff80005cbc5000-0xffff80005cbc5007]
>> Mem abort info:
>>    ESR = 0x0000000096000006
>>    EC = 0x25: DABT (current EL), IL = 32 bits
>>    SET = 0, FnV = 0
>>    EA = 0, S1PTW = 0
>>    FSC = 0x06: level 2 translation fault Data abort info:
>>    ISV = 0, ISS = 0x00000006
>>    CM = 0, WnR = 0
>> swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000045dfb000
>> [ffff70000b978a00] pgd=00000000bfbeb003, p4d=00000000bfbeb003,
>> pud=00000000bfbea003, pmd=0000000000000000 Internal error: Oops:
>> 0000000096000006 [#1] PREEMPT SMP Modules linked in:
>> CPU: 0 PID: 2820 Comm: kworker/0:3 Tainted: G        W          6.1.0-rc1-syzkaller-00025-gaae703b02f92
> #0
>> Hardware name: linux,dummy-virt (DT)
>> Workqueue: events free_ipc
>> pstate: 10000005 (nzcV daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc :
>> percpu_counter_add_batch+0x78/0x2f0 lib/percpu_counter.c:87 lr :
>> percpu_counter_add_batch+0x44/0x2f0 lib/percpu_counter.c:87 sp :
>> ffff8000120979c0
>> x29: ffff8000120979c0 x28: ffff0000151ff800 x27: 1fffe00002a3ff24
>> x26: ffff80005cbc5000 x25: ffff00000eeac7b0 x24: 1fffe00001dd58f6
>> x23: 000000007fffffff x22: ffff80000cc4e800 x21: 0000000000000000
>> x20: 0000000000000000 x19: ffff00000eeac758 x18: ffff00006a9cbbc0
>> x17: 0000000000000000 x16: 0000000000000000 x15: ffff800008d9c830
>> x14: ffff800008d78ecc x13: ffff800008d752d4 x12: ffff600002a3ff01
>> x11: 1fffe00002a3ff00 x10: ffff600002a3ff00 x9 : dfff800000000000
>> x8 : ffff0000151ff800 x7 : 00000000f1f1f1f1 x6 : dfff800000000000
>> x5 : ffff700002412f32 x4 : 1ffff000020ef1ac x3 : 1ffff0000b978a00
>> x2 : dfff800000000000 x1 : 0000000000000003 x0 : ffff80005cbc5000 Call
>> trace:
>>   percpu_counter_add_batch+0x78/0x2f0 lib/percpu_counter.c:87
>> percpu_counter_add_local include/linux/percpu_counter.h:75 [inline]
>> percpu_counter_sub_local include/linux/percpu_counter.h:225 [inline]
>>   freeque+0x20c/0x364 ipc/msg.c:292
>>   free_ipcs+0xa0/0x160 ipc/namespace.c:125
>>   msg_exit_ns+0x38/0x60 ipc/msg.c:1334
>>   free_ipc_ns ipc/namespace.c:138 [inline]
>>   free_ipc+0xd0/0x1c0 ipc/namespace.c:157
>> process_one_work+0x780/0x184c kernel/workqueue.c:2289
>>   worker_thread+0x3cc/0xc40 kernel/workqueue.c:2436
>>   kthread+0x23c/0x2a0 kernel/kthread.c:376
>>   ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860
> Well.  freeque() messes with ns->percpu_msg_hdrs but msg_exit_ns() already did
> percpu_counter_destroy(&ns->percpu_msg_hdrs);
>
> I'm thinking something like this?
>
> --- a/ipc/msg.c~a
> +++ a/ipc/msg.c
> @@ -1329,11 +1329,11 @@ fail_msg_bytes:
>   #ifdef CONFIG_IPC_NS
>   void msg_exit_ns(struct ipc_namespace *ns)  {
> -	percpu_counter_destroy(&ns->percpu_msg_bytes);
> -	percpu_counter_destroy(&ns->percpu_msg_hdrs);
>   	free_ipcs(ns, &msg_ids(ns), freeque);
>   	idr_destroy(&ns->ids[IPC_MSG_IDS].ipcs_idr);
>   	rhashtable_destroy(&ns->ids[IPC_MSG_IDS].key_ht);
> +	percpu_counter_destroy(&ns->percpu_msg_bytes);
> +	percpu_counter_destroy(&ns->percpu_msg_hdrs);
>   }
>   #endif
>   
> _

Hi Andrew,

The quick fix looks good to me. There is protection in 
percpu_counter_destroy if the it has been released in freeque. Thanks.