Re: 回复：回复：generalprotection fault in refill_obj_stock

On Tue, Apr 02, 2024 at 02:14:58PM +0800, Ubisectech Sirius wrote:

quoted

On Tue, Apr 02, 2024 at 09:50:54AM +0800, Ubisectech Sirius wrote:

quoted

quoted

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.

quoted

Thank you for the report!

quoted

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.

quoted

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?

I just start the reproducer and wait without any other operation. The speed of reproducing this problem is vary fast(Less than 5 seconds). 

quoted

quoted

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.

I have try the 6.0, 6.3, 6.4, 6.5 kernel. The Linux kernel 6.5 will get same error output. But other version will get different output like below:
[ 55.306672][ T7950] KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
[ 55.307259][ T7950] CPU: 1 PID: 7950 Comm: poc Not tainted 6.3.0 #1
[ 55.307714][ T7950] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
[ 55.308363][ T7950] RIP: 0010:tomoyo_check_acl (security/tomoyo/domain.c:173)
[ 55.316475][ T7950] Call Trace:
[ 55.316713][ T7950] <TASK>
[ 55.317353][ T7950] tomoyo_path_permission (security/tomoyo/file.c:170 security/tomoyo/file.c:587 security/tomoyo/file.c:573)
[ 55.317744][ T7950] tomoyo_check_open_permission (security/tomoyo/file.c:779)
[ 55.320152][ T7950] tomoyo_file_open (security/tomoyo/tomoyo.c:332 security/tomoyo/tomoyo.c:327)
[ 55.320495][ T7950] security_file_open (security/security.c:1719 (discriminator 13))
[ 55.320850][ T7950] do_dentry_open (fs/open.c:908)
[ 55.321526][ T7950] path_openat (fs/namei.c:3561 fs/namei.c:3715)
[ 55.322614][ T7950] do_filp_open (fs/namei.c:3743)
[ 55.325086][ T7950] do_sys_openat2 (fs/open.c:1349)
[ 55.326249][ T7950] __x64_sys_openat (fs/open.c:1375)
[ 55.327428][ T7950] do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)
[ 55.327756][ T7950] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)
[ 55.328185][ T7950] RIP: 0033:0x7f1c4a484f29
[ 55.328504][ T7950] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 37 8f 0d 00 f7 d8 64 89 01 48
[ 55.329864][ T7950] RSP: 002b:00007ffd7bfe8398 EFLAGS: 00000246 ORIG_RAX: 0000000000000101
[ 55.330464][ T7950] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1c4a484f29
[ 55.331024][ T7950] RDX: 0000000000141842 RSI: 0000000020000380 RDI: 00000000ffffff9c
[ 55.331585][ T7950] RBP: 00007ffd7bfe83a0 R08: 0000000000000000 R09: 00007ffd7bfe83f0
[ 55.332148][ T7950] R10: 0000000000000000 R11: 0000000000000246 R12: 000055c5e36482d0
[ 55.332707][ T7950] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 55.333268][ T7950] </TASK>
[ 55.333488][ T7950] Modules linked in:
[ 55.340525][ T7950] ---[ end trace 0000000000000000 ]---
[ 55.340936][ T7950] RIP: 0010:tomoyo_check_acl (security/tomoyo/domain.c:173)
It look like other problem?

It does look differently.

I can't reproduce any of those. I run into some build time issues when trying to
build the kernel with your config (I have a fairly old toolchain, maybe it's the reason),
but when running a more minimalistic config I do not see any issues on 6.1, 6.6 and 6.7.
Is this some sort of all-yes config or it's somehow specially crafted? Did you try
to reproduce the problem with other kernel configs?

It all smells a memory corruption, but who knows.

Thanks!