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 for Android: free password hash cracker in your pocket
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <tencent_09B453F1CA31CD732DB841EC0B992BC87009@qq.com>
Date: Thu, 13 Mar 2025 22:31:26 -0400
From: "ffhgfv" <744439878@...com>
To: "davem" <davem@...emloft.net>, "edumazet" <edumazet@...gle.com>, "kuba" <kuba@...nel.org>, "pabeni" <pabeni@...hat.com>, "horms" <horms@...nel.org>, "lucien.xin" <lucien.xin@...il.com>
Cc: "netdev" <netdev@...r.kernel.org>, "linux-kernel" <linux-kernel@...r.kernel.org>
Subject: Linux6.14-rc5: BUG- general protection fault in dst_dev_put 

Hello, I found a bug titled "     general protection fault in dst_dev_put  " with modified syzkaller in the Linux6.14-rc5.
If you fix this issue, please add the following tag to the commit:  Reported-by: Jianzhou Zhao <xnxc22xnxc22@...com>,    xingwei lee <xrivendell7@...il.com>, Zhizhuo Tang <strforexctzzchange@...mail.com>

------------[ cut here ]-----------------------------------------
 TITLE: general protection fault in dst_dev_put 
==================================================================
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 1 UID: 0 PID: 25 Comm: ksoftirqd/1 Not tainted 6.14.0-rc5-dirty #11
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
RIP: 0010:dst_dev_put+0x26/0x330 net/core/dst.c:146
Code: 90 90 90 90 f3 0f 1e fa 41 57 41 56 49 89 fe 41 55 41 54 55 e8 eb 56 8a f8 4c 89 f2 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 &lt;80&gt; 3c 02 00 0f 85 da 02 00 00 49 8d 7e 3a 4d 8b 26 48 b8 00 00 00
RSP: 0018:ffffc900004cfbc0 EFLAGS: 00010246
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff89d2de58
RDX: 0000000000000000 RSI: ffff888040af8000 RDI: 0000000000000002
RBP: dffffc0000000000 R08: 0000000000000000 R09: ffffed100f9714c1
R10: ffffed100f9714c0 R11: ffff88807cb8a603 R12: fffffbfff1b6b491
R13: 0000607f80e31eb8 R14: 0000000000000003 R15: 0000000000000003
FS:  0000000000000000(0000) GS:ffff88807ee00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f4e9da0f000 CR3: 0000000000f04000 CR4: 0000000000752ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
 <task>
 rt_fibinfo_free_cpus.part.0+0xe2/0x1a0 net/ipv4/fib_semantics.c:201
 rt_fibinfo_free_cpus net/ipv4/fib_semantics.c:193 [inline]
 fib_nh_common_release+0x11d/0x290 net/ipv4/fib_semantics.c:212
 fib6_info_destroy_rcu+0x182/0x1e0 net/ipv6/ip6_fib.c:177
 rcu_do_batch kernel/rcu/tree.c:2546 [inline]
 rcu_core+0x7c2/0x16b0 kernel/rcu/tree.c:2802
 handle_softirqs+0x1c1/0x8a0 kernel/softirq.c:561
 run_ksoftirqd kernel/softirq.c:950 [inline]
 run_ksoftirqd+0x3a/0x60 kernel/softirq.c:942
 smpboot_thread_fn+0x639/0xa00 kernel/smpboot.c:164
 kthread+0x427/0x880 kernel/kthread.c:464
 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:148
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
 </task>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:dst_dev_put+0x26/0x330 net/core/dst.c:146
Code: 90 90 90 90 f3 0f 1e fa 41 57 41 56 49 89 fe 41 55 41 54 55 e8 eb 56 8a f8 4c 89 f2 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 &lt;80&gt; 3c 02 00 0f 85 da 02 00 00 49 8d 7e 3a 4d 8b 26 48 b8 00 00 00
RSP: 0018:ffffc900004cfbc0 EFLAGS: 00010246
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff89d2de58
RDX: 0000000000000000 RSI: ffff888040af8000 RDI: 0000000000000002
RBP: dffffc0000000000 R08: 0000000000000000 R09: ffffed100f9714c1
R10: ffffed100f9714c0 R11: ffff88807cb8a603 R12: fffffbfff1b6b491
R13: 0000607f80e31eb8 R14: 0000000000000003 R15: 0000000000000003
FS:  0000000000000000(0000) GS:ffff88807ee00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f4e9da0f000 CR3: 0000000000f04000 CR4: 0000000000752ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
----------------
Code disassembly (best guess):
   0:	90                   	nop
   1:	90                   	nop
   2:	90                   	nop
   3:	90                   	nop
   4:	f3 0f 1e fa          	endbr64
   8:	41 57                	push   %r15
   a:	41 56                	push   %r14
   c:	49 89 fe             	mov    %rdi,%r14
   f:	41 55                	push   %r13
  11:	41 54                	push   %r12
  13:	55                   	push   %rbp
  14:	e8 eb 56 8a f8       	call   0xf88a5704
  19:	4c 89 f2             	mov    %r14,%rdx
  1c:	48 b8 00 00 00 00 00 	movabs $0xdffffc0000000000,%rax
  23:	fc ff df
  26:	48 c1 ea 03          	shr    $0x3,%rdx
* 2a:	80 3c 02 00          	cmpb   $0x0,(%rdx,%rax,1) &lt;-- trapping instruction
  2e:	0f 85 da 02 00 00    	jne    0x30e
  34:	49 8d 7e 3a          	lea    0x3a(%r14),%rdi
  38:	4d 8b 26             	mov    (%r14),%r12
  3b:	48                   	rex.W
  3c:	b8                   	.byte 0xb8
  3d:	00 00                	add    %al,(%rax)

==================================================================
I use the same kernel as syzbot instance upstream: 7eb172143d5508b4da468ed59ee857c6e5e01da6
kernel config: https://syzkaller.appspot.com/text?tag=KernelConfig&amp;x=da4b04ae798b7ef6
compiler: gcc version 11.4.0
===============================================================================
Unfortunately, the modified syzkaller does not generate an effective repeat program.
The following is my analysis of the bug and repair suggestions, hoping to help with the repair of the bug:
1. The reference count of the dev pointer may not be maintained correctly when the fib_nh_common structure is released, causing dst_dev_put to access the released memory.
2. During the RCU callback processing, another thread may be modifying the routing table, resulting in inconsistent access status.
3. dst-&gt;dev may not be initialized correctly (for example, it is not set to NULL or a valid pointer), resulting in access to random addresses.
=========================================================================
I hope it helps.
Best regards
Jianzhou Zhao
xingwei lee
Zhizhuo Tang</strforexctzzchange@...mail.com></xrivendell7@...il.com></xnxc22xnxc22@...com>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ