Hello.
We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec. Recently, our team has discovered a issue in Linux kernel 6.7. Attached to the email were a PoC file of the issue.
Stack dump:
general protection fault, probably for non-canonical address 0xdffffc0000001cc6: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: probably user-memory-access in range [0x000000000000e630-0x000000000000e637]
CPU: 0 PID: 8041 Comm: systemd-udevd Not tainted 6.7.0 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
RIP: 0010:__ref_is_percpu include/linux/percpu-refcount.h:174 [inline]
RIP: 0010:percpu_ref_get_many include/linux/percpu-refcount.h:204 [inline]
RIP: 0010:percpu_ref_get include/linux/percpu-refcount.h:222 [inline]
RIP: 0010:obj_cgroup_get include/linux/memcontrol.h:810 [inline]
RIP: 0010:refill_obj_stock+0x135/0x500 mm/memcontrol.c:3535
Code: c7 c7 60 9f 3a 8d e8 fa ca 81 ff e8 d5 4e b2 08 5a 85 c0 0f 85 52 02 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 86 03 00 00 48 8b 45 00 a8 03 0f 85 76 02 00 00
RSP: 0018:ffffc900088bf898 EFLAGS: 00010006
RAX: dffffc0000000000 RBX: 00000000000380a0 RCX: 1ffff92001117edd
RDX: 0000000000001cc6 RSI: 0000000000000001 RDI: ffffffff8cddfa60
RBP: 000000000000e633 R08: 0000000000000000 R09: fffffbfff27147e0
R10: ffffffff938a3f07 R11: 0000000000000000 R12: 0000000000000148
R13: 0000000000000200 R14: ffff88802c6380a0 R15: ffff88802c6380e0
FS: 00007f774934e8c0(0000) GS:ffff88802c600000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005555566127e8 CR3: 0000000048fe8000 CR4: 0000000000750ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
<TASK>
memcg_slab_free_hook+0x157/0x2c0
slab_free_hook mm/slub.c:2075 [inline]
slab_free mm/slub.c:4280 [inline]
kmem_cache_free+0xe1/0x350 mm/slub.c:4344
kfree_skbmem+0xef/0x1b0 net/core/skbuff.c:1159
__kfree_skb net/core/skbuff.c:1217 [inline]
consume_skb net/core/skbuff.c:1432 [inline]
consume_skb+0xdf/0x170 net/core/skbuff.c:1426
netlink_recvmsg+0x5cb/0xf10 net/netlink/af_netlink.c:1983
sock_recvmsg_nosec net/socket.c:1046 [inline]
sock_recvmsg+0x1de/0x240 net/socket.c:1068
____sys_recvmsg+0x216/0x670 net/socket.c:2803
___sys_recvmsg+0xff/0x190 net/socket.c:2845
__sys_recvmsg+0xfb/0x1d0 net/socket.c:2875
current_top_of_stack arch/x86/include/asm/processor.h:532 [inline]
on_thread_stack arch/x86/include/asm/processor.h:537 [inline]
arch_enter_from_user_mode arch/x86/include/asm/entry-common.h:41 [inline]
enter_from_user_mode include/linux/entry-common.h:108 [inline]
syscall_enter_from_user_mode include/linux/entry-common.h:194 [inline]
do_syscall_64+0x43/0x120 arch/x86/entry/common.c:79
entry_SYSCALL_64_after_hwframe+0x6f/0x77
RIP: 0033:0x7f7749601d73
Code: 8b 15 59 a2 00 00 f7 d8 64 89 02 b8 ff ff ff ff eb b7 0f 1f 44 00 00 64 8b 04 25 18 00 00 00 85 c0 75 14 b8 2f 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 55 c3 0f 1f 40 00 48 83 ec 28 89 54 24 1c 48
RSP: 002b:00007fff81586858 EFLAGS: 00000246 ORIG_RAX: 000000000000002f
RAX: ffffffffffffffda RBX: 00007fff81588a20 RCX: 00007f7749601d73
RDX: 0000000000000000 RSI: 00007fff815868f0 RDI: 000000000000000f
RBP: 00007fff815869d0 R08: 00000000000046d4 R09: 00007fff815e5080
R10: 0000000000000007 R11: 0000000000000246 R12: 0000000000000000
R13: 000055824edb2ef0 R14: 0000000000000100 R15: 0000000000000000
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:__ref_is_percpu include/linux/percpu-refcount.h:174 [inline]
RIP: 0010:percpu_ref_get_many include/linux/percpu-refcount.h:204 [inline]
RIP: 0010:percpu_ref_get include/linux/percpu-refcount.h:222 [inline]
RIP: 0010:obj_cgroup_get include/linux/memcontrol.h:810 [inline]
RIP: 0010:refill_obj_stock+0x135/0x500 mm/memcontrol.c:3535
Code: c7 c7 60 9f 3a 8d e8 fa ca 81 ff e8 d5 4e b2 08 5a 85 c0 0f 85 52 02 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 86 03 00 00 48 8b 45 00 a8 03 0f 85 76 02 00 00
RSP: 0018:ffffc900088bf898 EFLAGS: 00010006
RAX: dffffc0000000000 RBX: 00000000000380a0 RCX: 1ffff92001117edd
RDX: 0000000000001cc6 RSI: 0000000000000001 RDI: ffffffff8cddfa60
RBP: 000000000000e633 R08: 0000000000000000 R09: fffffbfff27147e0
R10: ffffffff938a3f07 R11: 0000000000000000 R12: 0000000000000148
R13: 0000000000000200 R14: ffff88802c6380a0 R15: ffff88802c6380e0
FS: 00007f774934e8c0(0000) GS:ffff88802c600000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005555566127e8 CR3: 0000000048fe8000 CR4: 0000000000750ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
----------------
Code disassembly (best guess):
0: c7 c7 60 9f 3a 8d mov $0x8d3a9f60,%edi
6: e8 fa ca 81 ff call 0xff81cb05
b: e8 d5 4e b2 08 call 0x8b24ee5
10: 5a pop %rdx
11: 85 c0 test %eax,%eax
13: 0f 85 52 02 00 00 jne 0x26b
19: 48 b8 00 00 00 00 00 movabs $0xdffffc0000000000,%rax
20: fc ff df
23: 48 89 ea mov %rbp,%rdx
26: 48 c1 ea 03 shr $0x3,%rdx
* 2a: 80 3c 02 00 cmpb $0x0,(%rdx,%rax,1) <-- trapping instruction
2e: 0f 85 86 03 00 00 jne 0x3ba
34: 48 8b 45 00 mov 0x0(%rbp),%rax
38: a8 03 test $0x3,%al
3a: 0f 85 76 02 00 00 jne 0x2b6
Thank you for taking the time to read this email and we look forward to working with you further.
On Mon, Apr 01, 2024 at 03:04:46PM +0800, Ubisectech Sirius wrote:
> Hello.
> We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec. Recently, our team has discovered a issue in Linux kernel 6.7. Attached to the email were a PoC file of the issue.
Thank you for the report!
I tried to compile and run your test program for about half an hour
on a virtual machine running 6.7 with enabled KASAN, but wasn't able
to reproduce the problem.
Can you, please, share a bit more information? How long does it take
to reproduce? Do you mind sharing your kernel config? Is there anything special
about your setup? What are exact steps to reproduce the problem?
Is this problem reproducible on 6.6?
It's interesting that the problem looks like use-after-free for the objcg pointer
but happens in the context of udev-systemd, which I believe should be fairly stable
and it's cgroup is not going anywhere.
Thanks!
> On Mon, Apr 01, 2024 at 03:04:46PM +0800, Ubisectech Sirius wrote:
> Hello.
> We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec. Recently, our team has discovered a issue in Linux kernel 6.7. Attached to the email were a PoC file of the issue.
> Thank you for the report!
> I tried to compile and run your test program for about half an hour
> on a virtual machine running 6.7 with enabled KASAN, but wasn't able
> to reproduce the problem.
> Can you, please, share a bit more information? How long does it take
> to reproduce? Do you mind sharing your kernel config? Is there anything special
> about your setup? What are exact steps to reproduce the problem?
> Is this problem reproducible on 6.6?
Hi.
The .config of linux kernel 6.7 has send to you as attachment. And The problem is reproducible on 6.6.
> It's interesting that the problem looks like use-after-free for the objcg pointer
> but happens in the context of udev-systemd, which I believe should be fairly stable
> and it's cgroup is not going anywhere.
> Thanks!
On Tue, Apr 02, 2024 at 09:50:54AM +0800, Ubisectech Sirius wrote:
> > On Mon, Apr 01, 2024 at 03:04:46PM +0800, Ubisectech Sirius wrote:
> > Hello.
> > We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec. Recently, our team has discovered a issue in Linux kernel 6.7. Attached to the email were a PoC file of the issue.
>
> > Thank you for the report!
>
> > I tried to compile and run your test program for about half an hour
> > on a virtual machine running 6.7 with enabled KASAN, but wasn't able
> > to reproduce the problem.
>
> > Can you, please, share a bit more information? How long does it take
> > to reproduce? Do you mind sharing your kernel config? Is there anything special
> > about your setup? What are exact steps to reproduce the problem?
> > Is this problem reproducible on 6.6?
>
> Hi.
> The .config of linux kernel 6.7 has send to you as attachment.
Thanks!
How long it takes to reproduce a problem? Do you just start your reproducer and wait?
> And The problem is reproducible on 6.6.
Hm, it rules out my recent changes.
Did you try any older kernels? 6.5? 6.0? Did you try to bisect the problem?
If it's fast to reproduce, it might be the best option.
Also, are you running vanilla kernels or you do have some custom changes on top?
Thanks!
On Tue, Apr 02, 2024 at 09:50:54AM +0800, Ubisectech Sirius wrote:
> > On Mon, Apr 01, 2024 at 03:04:46PM +0800, Ubisectech Sirius wrote:
> > Hello.
> > We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec. Recently, our team has discovered a issue in Linux kernel 6.7. Attached to the email were a PoC file of the issue.
>
> > Thank you for the report!
>
> > I tried to compile and run your test program for about half an hour
> > on a virtual machine running 6.7 with enabled KASAN, but wasn't able
> > to reproduce the problem.
>
> > Can you, please, share a bit more information? How long does it take
> > to reproduce? Do you mind sharing your kernel config? Is there anything special
> > about your setup? What are exact steps to reproduce the problem?
> > Is this problem reproducible on 6.6?
>
> Hi.
> The .config of linux kernel 6.7 has send to you as attachment. And The problem is reproducible on 6.6.
Can you please share the reproducer of this issue?
>
> > It's interesting that the problem looks like use-after-free for the objcg pointer
> > but happens in the context of udev-systemd, which I believe should be fairly stable
> > and it's cgroup is not going anywhere.
>
> > Thanks!
>