[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANn89iJTtmdT0HsUtVMBdWeuj8pNY-FN6hkv0Z3QYr8_Yt_3Rg@mail.gmail.com>
Date: Mon, 9 Jan 2023 09:45:14 +0100
From: Eric Dumazet <edumazet@...gle.com>
To: Kyle Zeng <zengyhkyle@...il.com>,
Herbert Xu <herbert@...dor.apana.org.au>
Cc: Jakub Kicinski <kuba@...nel.org>, davem@...emloft.net,
yoshfuji@...ux-ipv6.org, dsahern@...nel.org, pabeni@...hat.com,
netdev@...r.kernel.org
Subject: Re: net: ipv6: raw: fixes null pointer deference in rawv6_push_pending_frames
On Sat, Jan 7, 2023 at 12:13 AM Kyle Zeng <zengyhkyle@...il.com> wrote:
>
> Hi Jakub,
>
> The null dereference can happen if every execution in the loop enters
> the `if (offset >= len) {`branch and directly `continue` without
> running `csum_skb = skb`.
> A crash report is attached to this email.
OK, but it seems we would be in an error condition, and would need to
purge sk_write_queue ?
(ie call ip6_flush_pending_frames(), and return some error, instead of 0
Also please add a
Fixes: 357b40a18b04 ("[IPV6]: IPV6_CHECKSUM socket option can corrupt
kernel memory")
Cc: Herbert Xu <herbert@...dor.apana.org.au>
>
> Best,
> Kyle Zeng
>
> =============================================
> [ 7.203616] BUG: kernel NULL pointer dereference, address: 00000000000000b2
> [ 7.205204] #PF: supervisor read access in kernel mode
> [ 7.206448] #PF: error_code(0x0000) - not-present page
> [ 7.207630] PGD 88d0067 P4D 88d0067 PUD 79af067 PMD 0
> [ 7.208060] Oops: 0000 [#1] SMP NOPTI
> [ 7.208343] CPU: 1 PID: 1846 Comm: poc Not tainted 5.10.133 #39
> [ 7.208816] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS 1.15.0-1 04/01/2014
> [ 7.209489] RIP: 0010:rawv6_push_pending_frames+0x96/0x1e0
> [ 7.209934] Code: 00 00 8d 57 ff 39 d0 0f 8d bc 00 00 00 48 89 7c
> 24 08 41 83 bc 24 d0 01 00 00 01 0f 85 b8 00 00 00 8b a9 88 00 00 00
> 48 89 cb <44> 0f b7 ab b2 00 00 00 44 03 ab c0 00 00 00 44 2b ab c8 00
> 00 00
> [ 7.211433] RSP: 0018:ffffc90003487b10 EFLAGS: 00010246
> [ 7.211859] RAX: 00000000000000d8 RBX: 0000000000000000 RCX: ffff8880064101c0
> [ 7.212410] RDX: 00000000000003c0 RSI: ffff8880064101c0 RDI: 00000000090e5840
> [ 7.212992] RBP: 00000000479c45b8 R08: 0000000000000000 R09: ffff8880064101a4
> [ 7.213559] R10: ffff8880064103d0 R11: ffff888006524b00 R12: ffff888006410000
> [ 7.214106] R13: ffffc90003487c10 R14: ffffc90003487c10 R15: 0000000000000000
> [ 7.214653] FS: 00000000017e03c0(0000) GS:ffff88803ec80000(0000)
> knlGS:0000000000000000
> [ 7.215272] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 7.215769] CR2: 00000000000000b2 CR3: 0000000009068006 CR4: 0000000000770ee0
> [ 7.216318] PKRU: 55555554
> [ 7.216532] Call Trace:
> [ 7.216744] rawv6_sendmsg+0x72c/0x7d0
> [ 7.217041] kernel_sendmsg+0x7a/0x90
> [ 7.217325] sock_no_sendpage+0xc1/0xe0
> [ 7.217644] kernel_sendpage+0xa3/0xe0
> [ 7.217945] sock_sendpage+0x23/0x30
> [ 7.218224] pipe_to_sendpage+0x76/0xa0
> [ 7.218529] __splice_from_pipe+0xe5/0x200
> [ 7.218870] ? generic_splice_sendpage+0xa0/0xa0
> [ 7.219263] generic_splice_sendpage+0x72/0xa0
> [ 7.219650] do_splice+0x4ad/0x780
> [ 7.219928] __se_sys_splice+0x162/0x210
> [ 7.220231] do_syscall_64+0x31/0x40
> [ 7.220518] entry_SYSCALL_64_after_hwframe+0x61/0xc6
> [ 7.220944] RIP: 0033:0x47656d
> [ 7.221189] Code: c3 e8 47 28 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 b0 ff ff ff f7 d8 64 89
> 01 48
> [ 7.222645] RSP: 002b:00007ffd36d11668 EFLAGS: 00000216 ORIG_RAX:
> 0000000000000113
> [ 7.223266] RAX: ffffffffffffffda RBX: 000000002000102f RCX: 000000000047656d
> [ 7.223860] RDX: 0000000000000007 RSI: 0000000000000000 RDI: 0000000000000005
> [ 7.224414] RBP: 00007ffd36d116a0 R08: 000000000804ffe2 R09: 0000000000000000
> [ 7.224986] R10: 0000000000000000 R11: 0000000000000216 R12: 0000000000000001
> [ 7.225546] R13: 00007ffd36d118d8 R14: 00000000005026c0 R15: 0000000000000002
> [ 7.226112] Modules linked in:
> [ 7.226350] CR2: 00000000000000b2
> [ 7.226613] ---[ end trace 5d56aba11d09b665 ]---
> [ 7.226993] RIP: 0010:rawv6_push_pending_frames+0x96/0x1e0
> [ 7.227442] Code: 00 00 8d 57 ff 39 d0 0f 8d bc 00 00 00 48 89 7c
> 24 08 41 83 bc 24 d0 01 00 00 01 0f 85 b8 00 00 00 8b a9 88 00 00 00
> 48 89 cb <44> 0f b7 ab b2 00 00 00 44 03 ab c0 00 00 00 44 2b ab c8 00
> 00 00
> [ 7.228918] RSP: 0018:ffffc90003487b10 EFLAGS: 00010246
> [ 7.229322] RAX: 00000000000000d8 RBX: 0000000000000000 RCX: ffff8880064101c0
> [ 7.229880] RDX: 00000000000003c0 RSI: ffff8880064101c0 RDI: 00000000090e5840
> [ 7.230516] RBP: 00000000479c45b8 R08: 0000000000000000 R09: ffff8880064101a4
> [ 7.231112] R10: ffff8880064103d0 R11: ffff888006524b00 R12: ffff888006410000
> [ 7.231687] R13: ffffc90003487c10 R14: ffffc90003487c10 R15: 0000000000000000
> [ 7.232250] FS: 00000000017e03c0(0000) GS:ffff88803ec80000(0000)
> knlGS:0000000000000000
> [ 7.232912] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 7.233376] CR2: 00000000000000b2 CR3: 0000000009068006 CR4: 0000000000770ee0
> [ 7.233958] PKRU: 55555554
> [ 7.234170] Kernel panic - not syncing: Fatal exception
> [ 7.234762] Kernel Offset: disabled
> [ 7.235062] Rebooting in 1000 seconds..
>
> On Fri, Jan 6, 2023 at 3:55 PM Jakub Kicinski <kuba@...nel.org> wrote:
> >
> > On Fri, 6 Jan 2023 14:19:52 -0700 Kyle Zeng wrote:
> > > It is posible that the skb_queue_walkloop does not assign csum_skb to a real skb.
> >
> > Not immediately obvious to me how that could happen given prior checks
> > in this function.
Powered by blists - more mailing lists