[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    Re: [oss-security] null pointer dereference in Linux kernel
From:       Rohit Keshri <rkeshri () redhat ! com>
Date:       2023-01-18 20:38:46
Message-ID: CAKx+4-pUdYEKivbsm6WyxDyQ0W4fAiOxRFmBqPxVXhwvicaaYA () mail ! gmail ! com
[Download RAW message or body]


Hello Team,

CVE-2023-0394 assigned.

On Wed, Jan 18, 2023 at 2:02 PM Kyle Zeng <zengyhkyle@gmail.com> wrote:

> Hi there,
> 
> I recently found a null pointer dereference in Linux kernel that
> affects multiple kernel versions. According to the versions that got
> patched, the vulnerability affects 6.1, 5.15, 5.10, 5.4, and 4.19.
> 
> [Root Cause Analysis]
> The bug is in "rawv6_push_pending_frames" function in net/ipv6/raw.c.
> According to Herbert Xu, who fixed the bug, the root cause is that
> "total_len = inet_sk(sk)->cork.base.length" in this function also
> counts the length of the extension header (+ the amount of valid data
> in the socket cork queue). In the vulnerable version of the function,
> it directly uses the length as the amount of data in the cork queue.
> In the following code:
> 
> struct sk_buff *csum_skb = NULL;
> ...
> skb_queue_walk(&sk->sk_write_queue, skb) {
> ...
> if (offset >= len) {
> offset -= len;
> continue;
> }
> csum_skb = skb;
> }
> skb = csum_skb;
> 
> If the `offset` is larger than the amount of data in the socket cork
> queue but smaller than valid data length + extension header length,
> then the loop shown above will always enter the "if (offset >= len)"
> branch. As a result, csum_skb will never be set. Consequently, the
> final skb variable will be set to NULL.
> 
> Null dereference happens in the following "skb_transport_offset(skb);"
> call.
> 
> [Patch]
> I have contacted Linux kernel team and helped them prepare a patch.
> The patch to this bug has been merged into the mainline and stable
> trees:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cb3e9864cdbe35ff6378966660edbcbac955fe17
>  
> This bug does not have a CVE number assigned yet. I'll appreciate it
> if someone from the list can give it a CVE number to notify other
> vendors about its security implication.
> 
> A crash report is attached to the email. And a poc that triggers oops
> can be found here:
> https://lore.kernel.org/netdev/Y7s%2FFofVXLwoVgWt@westworld/
> 
> Best,
> Kyle Zeng
> 
> 
> =====================================
> general protection fault, probably for non-canonical address
> 0xdffffc0000000018: 0000 [#1] SMP KASAN PTI
> KASAN: null-ptr-deref in range [0x00000000000000c0-0x00000000000000c7]
> CPU: 0 PID: 619 Comm: syz-executor390 Not tainted 5.10.140+ #1
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1
> 04/01/2014
> RIP: 0010:skb_transport_header include/linux/skbuff.h:2500 [inline]
> RIP: 0010:skb_transport_offset include/linux/skbuff.h:2606 [inline]
> RIP: 0010:rawv6_push_pending_frames net/ipv6/raw.c:593 [inline]
> RIP: 0010:rawv6_sendmsg+0x4368/0x5db0 net/ipv6/raw.c:956
> Code: e8 cd ca e0 fb e9 51 fe ff ff e8 c3 7b 61 fb 49 89 dd 48 bd 00
> 00 00 00 00 fc ff df 49 8d bd c0 00 00 00 48 89 f8 48 c1 e8 03 <80> 3c
> 28 00 74 05 e8 bd ca e0 fb 49 8b 9d c0 00 00 00 49 8d bd b2
> RSP: 0018:ffff888013ddf7e8 EFLAGS: 00010206
> RAX: 0000000000000018 RBX: 0000000000000000 RCX: ffff888011f05500
> RDX: 0000000000000000 RSI: 0000000000000004 RDI: 00000000000000c0
> RBP: dffffc0000000000 R08: dffffc0000000000 R09: ffffed10027a9afc
> R10: 0000000000000000 R11: 0000000000000000 R12: 00000000479c45b8
> R13: 0000000000000000 R14: ffff888013d4d800 R15: 00000000000000d8
> FS:  00005555560ca3c0(0000) GS:ffff88806b800000(0000)
> knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000020001000 CR3: 000000000eb5a002 CR4: 0000000000170ef0
> Call Trace:
> sock_sendmsg_nosec net/socket.c:651 [inline]
> sock_sendmsg net/socket.c:671 [inline]
> kernel_sendmsg+0x20a/0x230 net/socket.c:691
> sock_no_sendpage+0xde/0x130 net/core/sock.c:2852
> kernel_sendpage+0x4c8/0x530 net/socket.c:3514
> sock_sendpage+0x83/0xb0 net/socket.c:944
> pipe_to_sendpage+0x4c0/0x630 fs/splice.c:364
> splice_from_pipe_feed fs/splice.c:418 [inline]
> __splice_from_pipe+0x655/0xf60 fs/splice.c:562
> splice_from_pipe fs/splice.c:597 [inline]
> generic_splice_sendpage+0x132/0x1a0 fs/splice.c:743
> do_splice_from fs/splice.c:764 [inline]
> do_splice+0x1ea8/0x2da0 fs/splice.c:1057
> __do_splice fs/splice.c:1135 [inline]
> __do_sys_splice fs/splice.c:1341 [inline]
> __se_sys_splice+0x935/0xdc0 fs/splice.c:1323
> do_syscall_64+0x13a/0x160 arch/x86/entry/common.c:46
> entry_SYSCALL_64_after_hwframe+0x61/0xc6
> RIP: 0033:0x7f111d8c47dd
> Code: c3 e8 e7 22 00 00 0f 1f 80 00 00 00 00 f3 0f 1e fa 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 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007fff0105cb48 EFLAGS: 00000246 ORIG_RAX: 0000000000000113
> RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f111d8c47dd
> RDX: 0000000000000005 RSI: 0000000000000000 RDI: 0000000000000003
> RBP: 00007fff0105cb80 R08: 000000000804ffe2 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
> R13: 000000000000bbd1 R14: 00007fff0105cb64 R15: 00007fff0105cb70
> Modules linked in:
> ---[ end trace 66de936c85813c54 ]---
> RIP: 0010:skb_transport_header include/linux/skbuff.h:2500 [inline]
> RIP: 0010:skb_transport_offset include/linux/skbuff.h:2606 [inline]
> RIP: 0010:rawv6_push_pending_frames net/ipv6/raw.c:593 [inline]
> RIP: 0010:rawv6_sendmsg+0x4368/0x5db0 net/ipv6/raw.c:956
> Code: e8 cd ca e0 fb e9 51 fe ff ff e8 c3 7b 61 fb 49 89 dd 48 bd 00
> 00 00 00 00 fc ff df 49 8d bd c0 00 00 00 48 89 f8 48 c1 e8 03 <80> 3c
> 28 00 74 05 e8 bd ca e0 fb 49 8b 9d c0 00 00 00 49 8d bd b2
> RSP: 0018:ffff888013ddf7e8 EFLAGS: 00010206
> RAX: 0000000000000018 RBX: 0000000000000000 RCX: ffff888011f05500
> RDX: 0000000000000000 RSI: 0000000000000004 RDI: 00000000000000c0
> RBP: dffffc0000000000 R08: dffffc0000000000 R09: ffffed10027a9afc
> R10: 0000000000000000 R11: 0000000000000000 R12: 00000000479c45b8
> R13: 0000000000000000 R14: ffff888013d4d800 R15: 00000000000000d8
> FS:  00005555560ca3c0(0000) GS:ffff88806b800000(0000)
> knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000020001000 CR3: 000000000eb5a002 CR4: 0000000000170ef0
> ----------------
> Code disassembly (best guess):
> 0: e8 cd ca e0 fb        call   0xfbe0cad2
> 5: e9 51 fe ff ff        jmp    0xfffffe5b
> a: e8 c3 7b 61 fb        call   0xfb617bd2
> f: 49 89 dd              mov    %rbx,%r13
> 12: 48 bd 00 00 00 00 00 movabs $0xdffffc0000000000,%rbp
> 19: fc ff df
> 1c: 49 8d bd c0 00 00 00 lea    0xc0(%r13),%rdi
> 23: 48 89 f8              mov    %rdi,%rax
> 26: 48 c1 e8 03          shr    $0x3,%rax
> * 2a: 80 3c 28 00          cmpb   $0x0,(%rax,%rbp,1) <-- trapping
> instruction
> 2e: 74 05                je     0x35
> 30: e8 bd ca e0 fb        call   0xfbe0caf2
> 35: 49 8b 9d c0 00 00 00 mov    0xc0(%r13),%rbx
> 3c: 49                    rex.WB
> 3d: 8d                    .byte 0x8d
> 3e: bd                    .byte 0xbd
> 3f: b2                    .byte 0xb2
> 
> 



[prev in list] [next in list] [prev in thread] [next in thread]