* [PATCH v2] net: ipv6: fix use-after-free Read in __xfrm6_tunnel_spi_lookup @ 2020-07-26 3:08 B K Karthik 2020-07-26 5:35 ` Cong Wang ` (3 more replies) 0 siblings, 4 replies; 9+ messages in thread From: B K Karthik @ 2020-07-26 3:08 UTC (permalink / raw) To: Steffen Klassert, Herbert Xu, David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI, Jakub Kicinski, netdev, linux-kernel, gregkh, skhan, linux-kernel-mentees [-- Attachment #1: Type: text/plain, Size: 7017 bytes --] __xfrm_tunnel_spi_check used xfrm6_tunnel_spi_has_byspi which returns spi % XFRM6_TUNNEL_SPI_BYSPI_HSIZE. whereas xfrm6_tunnel_spi_hash_byaddr makes a call to ipv6_addr_hash. netdevsim netdevsim0 netdevsim1: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim0 netdevsim2: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim0 netdevsim3: set [1, 0] type 2 family 0 port 6081 - 0 ================================================================== BUG: KASAN: use-after-free in __xfrm6_tunnel_spi_lookup+0x3a9/0x3b0 net/ipv6/xfrm6_tunnel.c:79 Read of size 8 at addr ffff8880934578a8 by task syz-executor437/6811 CPU: 0 PID: 6811 Comm: syz-executor437 Not tainted 5.8.0-rc5-next-20200715-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x18f/0x20d lib/dump_stack.c:118 print_address_description.constprop.0.cold+0xae/0x497 mm/kasan/report.c:383 __kasan_report mm/kasan/report.c:513 [inline] kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530 __xfrm6_tunnel_spi_lookup+0x3a9/0x3b0 net/ipv6/xfrm6_tunnel.c:79 xfrm6_tunnel_spi_lookup+0x8a/0x1d0 net/ipv6/xfrm6_tunnel.c:95 xfrmi6_rcv_tunnel+0xb9/0x100 net/xfrm/xfrm_interface.c:824 tunnel6_rcv+0xef/0x2b0 net/ipv6/tunnel6.c:148 ip6_protocol_deliver_rcu+0x2e8/0x1670 net/ipv6/ip6_input.c:433 ip6_input_finish+0x7f/0x160 net/ipv6/ip6_input.c:474 NF_HOOK include/linux/netfilter.h:307 [inline] NF_HOOK include/linux/netfilter.h:301 [inline] ip6_input+0x9c/0xd0 net/ipv6/ip6_input.c:483 dst_input include/net/dst.h:449 [inline] ip6_rcv_finish net/ipv6/ip6_input.c:76 [inline] NF_HOOK include/linux/netfilter.h:307 [inline] NF_HOOK include/linux/netfilter.h:301 [inline] ipv6_rcv+0x28e/0x3c0 net/ipv6/ip6_input.c:307 __netif_receive_skb_one_core+0x114/0x180 net/core/dev.c:5287 __netif_receive_skb+0x27/0x1c0 net/core/dev.c:5401 netif_receive_skb_internal net/core/dev.c:5503 [inline] netif_receive_skb+0x159/0x990 net/core/dev.c:5562 tun_rx_batched.isra.0+0x460/0x720 drivers/net/tun.c:1518 tun_get_user+0x23b2/0x35b0 drivers/net/tun.c:1972 tun_chr_write_iter+0xba/0x151 drivers/net/tun.c:2001 call_write_iter include/linux/fs.h:1879 [inline] new_sync_write+0x422/0x650 fs/read_write.c:515 vfs_write+0x59d/0x6b0 fs/read_write.c:595 ksys_write+0x12d/0x250 fs/read_write.c:648 do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x403d50 Code: Bad RIP value. RSP: 002b:00007ffe8fe93368 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000403d50 RDX: 000000000000005e RSI: 00000000200007c0 RDI: 00000000000000f0 RBP: 00007ffe8fe93390 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe8fe93380 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Allocated by task 6811: kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48 kasan_set_track mm/kasan/common.c:56 [inline] __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:461 __do_kmalloc mm/slab.c:3655 [inline] __kmalloc+0x1a8/0x320 mm/slab.c:3664 kmalloc include/linux/slab.h:559 [inline] kzalloc include/linux/slab.h:666 [inline] tomoyo_init_log+0x1335/0x1e50 security/tomoyo/audit.c:275 tomoyo_supervisor+0x32f/0xeb0 security/tomoyo/common.c:2097 tomoyo_audit_path_number_log security/tomoyo/file.c:235 [inline] tomoyo_path_number_perm+0x3ed/0x4d0 security/tomoyo/file.c:734 security_file_ioctl+0x50/0xb0 security/security.c:1489 ksys_ioctl+0x50/0x180 fs/ioctl.c:747 __do_sys_ioctl fs/ioctl.c:762 [inline] __se_sys_ioctl fs/ioctl.c:760 [inline] __x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:760 do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Freed by task 6811: kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48 kasan_set_track+0x1c/0x30 mm/kasan/common.c:56 kasan_set_free_info+0x1b/0x30 mm/kasan/generic.c:355 __kasan_slab_free+0xd8/0x120 mm/kasan/common.c:422 __cache_free mm/slab.c:3418 [inline] kfree+0x103/0x2c0 mm/slab.c:3756 tomoyo_supervisor+0x350/0xeb0 security/tomoyo/common.c:2149 tomoyo_audit_path_number_log security/tomoyo/file.c:235 [inline] tomoyo_path_number_perm+0x3ed/0x4d0 security/tomoyo/file.c:734 security_file_ioctl+0x50/0xb0 security/security.c:1489 ksys_ioctl+0x50/0x180 fs/ioctl.c:747 __do_sys_ioctl fs/ioctl.c:762 [inline] __se_sys_ioctl fs/ioctl.c:760 [inline] __x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:760 do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384 entry_SYSCALL_64_after_hwframe+0x44/0xa9 The buggy address belongs to the object at ffff888093457800 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 168 bytes inside of 512-byte region [ffff888093457800, ffff888093457a00) The buggy address belongs to the page: page:000000005c2b5911 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x93457 flags: 0xfffe0000000200(slab) raw: 00fffe0000000200 ffffea00028d4308 ffffea0002834c88 ffff8880aa000600 raw: 0000000000000000 ffff888093457000 0000000100000004 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888093457780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff888093457800: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888093457880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888093457900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888093457980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== Reported-and-tested-by: syzbot+72ff2fa98097767b5a27@syzkaller.appspotmail.com Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: B K Karthik <bkkarthik@pesu.pes.edu> --- v1 -> v2: added cast in arguement from u32 to (const xfrm_address_t *) added Reported-by: kernel test robot <lkp@intel.com> removed Reported-by: syzbot+72ff2fa98097767b5a27@syzkaller.appspotmail.com added Reported-and-tested-by: syzbot+72ff2fa98097767b5a27@syzkaller.appspotmail.com net/ipv6/xfrm6_tunnel.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/ipv6/xfrm6_tunnel.c b/net/ipv6/xfrm6_tunnel.c index 25b7ebda2fab..a0e18be2145f 100644 --- a/net/ipv6/xfrm6_tunnel.c +++ b/net/ipv6/xfrm6_tunnel.c @@ -103,10 +103,10 @@ static int __xfrm6_tunnel_spi_check(struct net *net, u32 spi) { struct xfrm6_tunnel_net *xfrm6_tn = xfrm6_tunnel_pernet(net); struct xfrm6_tunnel_spi *x6spi; - int index = xfrm6_tunnel_spi_hash_byspi(spi); + int index = xfrm6_tunnel_spi_hash_byaddr((const xfrm_address_t *)spi); hlist_for_each_entry(x6spi, - &xfrm6_tn->spi_byspi[index], + &xfrm6_tn->spi_byaddr[index], list_byspi) { if (x6spi->spi == spi) return -1; -- 2.20.1 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 659 bytes --] ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH v2] net: ipv6: fix use-after-free Read in __xfrm6_tunnel_spi_lookup 2020-07-26 3:08 [PATCH v2] net: ipv6: fix use-after-free Read in __xfrm6_tunnel_spi_lookup B K Karthik @ 2020-07-26 5:35 ` Cong Wang 2020-07-26 6:12 ` B K Karthik 2020-07-27 9:50 ` Steffen Klassert 2020-07-26 7:20 ` kernel test robot ` (2 subsequent siblings) 3 siblings, 2 replies; 9+ messages in thread From: Cong Wang @ 2020-07-26 5:35 UTC (permalink / raw) To: B K Karthik Cc: Steffen Klassert, Herbert Xu, David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI, Jakub Kicinski, Linux Kernel Network Developers, LKML, Greg KH, skhan, linux-kernel-mentees On Sat, Jul 25, 2020 at 8:09 PM B K Karthik <bkkarthik@pesu.pes.edu> wrote: > @@ -103,10 +103,10 @@ static int __xfrm6_tunnel_spi_check(struct net *net, u32 spi) > { > struct xfrm6_tunnel_net *xfrm6_tn = xfrm6_tunnel_pernet(net); > struct xfrm6_tunnel_spi *x6spi; > - int index = xfrm6_tunnel_spi_hash_byspi(spi); > + int index = xfrm6_tunnel_spi_hash_byaddr((const xfrm_address_t *)spi); > > hlist_for_each_entry(x6spi, > - &xfrm6_tn->spi_byspi[index], > + &xfrm6_tn->spi_byaddr[index], > list_byspi) { > if (x6spi->spi == spi) How did you convince yourself this is correct? This lookup is still using spi. :) More importantly, can you explain how UAF happens? Apparently the syzbot stack traces you quote make no sense at all. I also looked at other similar reports, none of them makes sense to me. Thanks. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2] net: ipv6: fix use-after-free Read in __xfrm6_tunnel_spi_lookup 2020-07-26 5:35 ` Cong Wang @ 2020-07-26 6:12 ` B K Karthik 2020-07-26 20:07 ` Cong Wang 2020-07-27 9:50 ` Steffen Klassert 1 sibling, 1 reply; 9+ messages in thread From: B K Karthik @ 2020-07-26 6:12 UTC (permalink / raw) To: Cong Wang Cc: Steffen Klassert, Herbert Xu, David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI, Jakub Kicinski, Linux Kernel Network Developers, LKML, Greg KH, Shuah Khan, linux-kernel-mentees On Sun, Jul 26, 2020 at 11:05 AM Cong Wang <xiyou.wangcong@gmail.com> wrote: > > On Sat, Jul 25, 2020 at 8:09 PM B K Karthik <bkkarthik@pesu.pes.edu> wrote: > > @@ -103,10 +103,10 @@ static int __xfrm6_tunnel_spi_check(struct net *net, u32 spi) > > { > > struct xfrm6_tunnel_net *xfrm6_tn = xfrm6_tunnel_pernet(net); > > struct xfrm6_tunnel_spi *x6spi; > > - int index = xfrm6_tunnel_spi_hash_byspi(spi); > > + int index = xfrm6_tunnel_spi_hash_byaddr((const xfrm_address_t *)spi); > > > > hlist_for_each_entry(x6spi, > > - &xfrm6_tn->spi_byspi[index], > > + &xfrm6_tn->spi_byaddr[index], > > list_byspi) { > > if (x6spi->spi == spi) > > How did you convince yourself this is correct? This lookup is still > using spi. :) I'm sorry, but my intention behind writing this patch was not to fix the UAF, but to fix a slab-out-of-bound. If required, I can definitely change the subject line and resend the patch, but I figured this was correct for https://syzkaller.appspot.com/bug?id=058d05f470583ab2843b1d6785fa8d0658ef66ae . since that particular report did not have a reproducer, Dmitry Vyukov <dvyukov@google.com> suggested that I test this patch on other reports for xfrm/spi . Forgive me if this was the wrong way to send a patch for that particular report, but I guessed since the reproducer did not trigger the crash for UAF, I would leave the subject line as 'fix UAF' :) xfrm6_spi_hash_by_hash seemed more convincing because I had to prevent a slab-out-of-bounds because it uses ipv6_addr_hash. It would be of great help if you could help me understand how this was able to fix a UAF. > > More importantly, can you explain how UAF happens? Apparently > the syzbot stack traces you quote make no sense at all. I also > looked at other similar reports, none of them makes sense to me. Forgive me, but I do not understand what you mean by the stack traces (this or other similar reports) "make no sense". I apologise if this message was hurtful / disrespectful in any manner. thanks, karthik ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2] net: ipv6: fix use-after-free Read in __xfrm6_tunnel_spi_lookup 2020-07-26 6:12 ` B K Karthik @ 2020-07-26 20:07 ` Cong Wang 2020-07-27 5:19 ` B K Karthik 0 siblings, 1 reply; 9+ messages in thread From: Cong Wang @ 2020-07-26 20:07 UTC (permalink / raw) To: B K Karthik Cc: Steffen Klassert, Herbert Xu, David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI, Jakub Kicinski, Linux Kernel Network Developers, LKML, Greg KH, Shuah Khan, linux-kernel-mentees On Sat, Jul 25, 2020 at 11:12 PM B K Karthik <bkkarthik@pesu.pes.edu> wrote: > > On Sun, Jul 26, 2020 at 11:05 AM Cong Wang <xiyou.wangcong@gmail.com> wrote: > > > > On Sat, Jul 25, 2020 at 8:09 PM B K Karthik <bkkarthik@pesu.pes.edu> wrote: > > > @@ -103,10 +103,10 @@ static int __xfrm6_tunnel_spi_check(struct net *net, u32 spi) > > > { > > > struct xfrm6_tunnel_net *xfrm6_tn = xfrm6_tunnel_pernet(net); > > > struct xfrm6_tunnel_spi *x6spi; > > > - int index = xfrm6_tunnel_spi_hash_byspi(spi); > > > + int index = xfrm6_tunnel_spi_hash_byaddr((const xfrm_address_t *)spi); > > > > > > hlist_for_each_entry(x6spi, > > > - &xfrm6_tn->spi_byspi[index], > > > + &xfrm6_tn->spi_byaddr[index], > > > list_byspi) { > > > if (x6spi->spi == spi) > > > > How did you convince yourself this is correct? This lookup is still > > using spi. :) > > I'm sorry, but my intention behind writing this patch was not to fix > the UAF, but to fix a slab-out-of-bound. Odd, your $subject is clearly UAF, so is the stack trace in your changelog. :) > If required, I can definitely change the subject line and resend the > patch, but I figured this was correct for > https://syzkaller.appspot.com/bug?id=058d05f470583ab2843b1d6785fa8d0658ef66ae > . since that particular report did not have a reproducer, > Dmitry Vyukov <dvyukov@google.com> suggested that I test this patch on > other reports for xfrm/spi . You have to change it to avoid misleading. > > Forgive me if this was the wrong way to send a patch for that > particular report, but I guessed since the reproducer did not trigger > the crash > for UAF, I would leave the subject line as 'fix UAF' :) > > xfrm6_spi_hash_by_hash seemed more convincing because I had to prevent > a slab-out-of-bounds because it uses ipv6_addr_hash. > It would be of great help if you could help me understand how this was > able to fix a UAF. Sure, you just avoid a pointer deref, which of course can fix the UAF, but I still don't think it is correct in any aspect. Even if it is a OOB, you still have to explain why it happened. Once again, I can't see how it could happen either. > > > > > More importantly, can you explain how UAF happens? Apparently > > the syzbot stack traces you quote make no sense at all. I also > > looked at other similar reports, none of them makes sense to me. > > Forgive me, but I do not understand what you mean by the stack traces > (this or other similar reports) "make no sense". Because the stack trace in your changelog clearly shows it is allocated in tomoyo_init_log(), which is a buffer in struct tomoyo_query, but none of xfrm paths uses it. Or do you see anything otherwise? Thanks. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2] net: ipv6: fix use-after-free Read in __xfrm6_tunnel_spi_lookup 2020-07-26 20:07 ` Cong Wang @ 2020-07-27 5:19 ` B K Karthik 0 siblings, 0 replies; 9+ messages in thread From: B K Karthik @ 2020-07-27 5:19 UTC (permalink / raw) To: Cong Wang Cc: Steffen Klassert, Herbert Xu, David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI, Jakub Kicinski, Linux Kernel Network Developers, LKML, Greg KH, Shuah Khan, linux-kernel-mentees On Mon, Jul 27, 2020 at 1:37 AM Cong Wang <xiyou.wangcong@gmail.com> wrote: > > On Sat, Jul 25, 2020 at 11:12 PM B K Karthik <bkkarthik@pesu.pes.edu> wrote: > > > > On Sun, Jul 26, 2020 at 11:05 AM Cong Wang <xiyou.wangcong@gmail.com> wrote: > > > > > > On Sat, Jul 25, 2020 at 8:09 PM B K Karthik <bkkarthik@pesu.pes.edu> wrote: > > > > @@ -103,10 +103,10 @@ static int __xfrm6_tunnel_spi_check(struct net *net, u32 spi) > > > > { > > > > struct xfrm6_tunnel_net *xfrm6_tn = xfrm6_tunnel_pernet(net); > > > > struct xfrm6_tunnel_spi *x6spi; > > > > - int index = xfrm6_tunnel_spi_hash_byspi(spi); > > > > + int index = xfrm6_tunnel_spi_hash_byaddr((const xfrm_address_t *)spi); > > > > > > > > hlist_for_each_entry(x6spi, > > > > - &xfrm6_tn->spi_byspi[index], > > > > + &xfrm6_tn->spi_byaddr[index], > > > > list_byspi) { > > > > if (x6spi->spi == spi) > > > > > > How did you convince yourself this is correct? This lookup is still > > > using spi. :) > > > > I'm sorry, but my intention behind writing this patch was not to fix > > the UAF, but to fix a slab-out-of-bound. > > Odd, your $subject is clearly UAF, so is the stack trace in your changelog. > :) > > > > If required, I can definitely change the subject line and resend the > > patch, but I figured this was correct for > > https://syzkaller.appspot.com/bug?id=058d05f470583ab2843b1d6785fa8d0658ef66ae > > . since that particular report did not have a reproducer, > > Dmitry Vyukov <dvyukov@google.com> suggested that I test this patch on > > other reports for xfrm/spi . > > You have to change it to avoid misleading. I will do that once somebody tells me this patch is reasonable to avoid wasting people's time. > > > > > Forgive me if this was the wrong way to send a patch for that > > particular report, but I guessed since the reproducer did not trigger > > the crash > > for UAF, I would leave the subject line as 'fix UAF' :) > > > > xfrm6_spi_hash_by_hash seemed more convincing because I had to prevent > > a slab-out-of-bounds because it uses ipv6_addr_hash. > > It would be of great help if you could help me understand how this was > > able to fix a UAF. > > Sure, you just avoid a pointer deref, which of course can fix the UAF, > but I still don't think it is correct in any aspect. I saw a function call being made to tomoyo_check_acl(). the next thing happening is a kfree(). Also, spi_hash_byspi just returns spi % XFRM6_TUNNEL_SPI_BYSPI_HSIZE . I'm a mentee, hence I would say my knowledge is very limited, please let me know if I am making a horrible mistake somewhere, but return (__force u32)(a->s6_addr32[0] ^ a->s6_addr32[1] ^ a->s6_addr32[2] ^ a->s6_addr32[3]); seems like a better because as David S. Miller <davem@davemloft.net> said "It is doing a XOR on all bits of an IPv6 address, it is doing more bit shifting which the existing hash was ignoring" . Please help me understand this better if I am going wrong. > > Even if it is a OOB, you still have to explain why it happened. Once > again, I can't see how it could happen either. > > > > > > > > > More importantly, can you explain how UAF happens? Apparently > > > the syzbot stack traces you quote make no sense at all. I also > > > looked at other similar reports, none of them makes sense to me. > > > > Forgive me, but I do not understand what you mean by the stack traces > > (this or other similar reports) "make no sense". > > Because the stack trace in your changelog clearly shows it is allocated > in tomoyo_init_log(), which is a buffer in struct tomoyo_query, but > none of xfrm paths uses it. Or do you see anything otherwise? Aren't there indirect inet calls and netfilter hooks? I'm sorry I do not see anything otherwise. Please help me understand. thanks, karthik ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2] net: ipv6: fix use-after-free Read in __xfrm6_tunnel_spi_lookup 2020-07-26 5:35 ` Cong Wang 2020-07-26 6:12 ` B K Karthik @ 2020-07-27 9:50 ` Steffen Klassert 1 sibling, 0 replies; 9+ messages in thread From: Steffen Klassert @ 2020-07-27 9:50 UTC (permalink / raw) To: Cong Wang Cc: B K Karthik, Herbert Xu, David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI, Jakub Kicinski, Linux Kernel Network Developers, LKML, Greg KH, skhan, linux-kernel-mentees On Sat, Jul 25, 2020 at 10:35:12PM -0700, Cong Wang wrote: > On Sat, Jul 25, 2020 at 8:09 PM B K Karthik <bkkarthik@pesu.pes.edu> wrote: > > @@ -103,10 +103,10 @@ static int __xfrm6_tunnel_spi_check(struct net *net, u32 spi) > > { > > struct xfrm6_tunnel_net *xfrm6_tn = xfrm6_tunnel_pernet(net); > > struct xfrm6_tunnel_spi *x6spi; > > - int index = xfrm6_tunnel_spi_hash_byspi(spi); > > + int index = xfrm6_tunnel_spi_hash_byaddr((const xfrm_address_t *)spi); > > > > hlist_for_each_entry(x6spi, > > - &xfrm6_tn->spi_byspi[index], > > + &xfrm6_tn->spi_byaddr[index], > > list_byspi) { > > if (x6spi->spi == spi) > > How did you convince yourself this is correct? This lookup is still > using spi. :) This can not be correct, it takes a u32 spi value and casts it to a pointer to an IP address. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2] net: ipv6: fix use-after-free Read in __xfrm6_tunnel_spi_lookup 2020-07-26 3:08 [PATCH v2] net: ipv6: fix use-after-free Read in __xfrm6_tunnel_spi_lookup B K Karthik 2020-07-26 5:35 ` Cong Wang @ 2020-07-26 7:20 ` kernel test robot 2020-07-26 10:37 ` kernel test robot 2020-07-29 0:36 ` David Miller 3 siblings, 0 replies; 9+ messages in thread From: kernel test robot @ 2020-07-26 7:20 UTC (permalink / raw) To: B K Karthik, Steffen Klassert, Herbert Xu, David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI, Jakub Kicinski, linux-kernel, gregkh, skhan Cc: kbuild-all, netdev [-- Attachment #1: Type: text/plain, Size: 2144 bytes --] Hi K, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on ipsec/master] [also build test WARNING on ipsec-next/master sparc-next/master net-next/master net/master v5.8-rc6 next-20200724] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/B-K-Karthik/net-ipv6-fix-use-after-free-Read-in-__xfrm6_tunnel_spi_lookup/20200726-111019 base: https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec.git master config: alpha-allyesconfig (attached as .config) compiler: alpha-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=alpha If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot <lkp@intel.com> All warnings (new ones prefixed by >>): net/ipv6/xfrm6_tunnel.c: In function '__xfrm6_tunnel_spi_check': >> net/ipv6/xfrm6_tunnel.c:106:43: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] 106 | int index = xfrm6_tunnel_spi_hash_byaddr((const xfrm_address_t *)spi); | ^ vim +106 net/ipv6/xfrm6_tunnel.c 101 102 static int __xfrm6_tunnel_spi_check(struct net *net, u32 spi) 103 { 104 struct xfrm6_tunnel_net *xfrm6_tn = xfrm6_tunnel_pernet(net); 105 struct xfrm6_tunnel_spi *x6spi; > 106 int index = xfrm6_tunnel_spi_hash_byaddr((const xfrm_address_t *)spi); 107 108 hlist_for_each_entry(x6spi, 109 &xfrm6_tn->spi_byaddr[index], 110 list_byspi) { 111 if (x6spi->spi == spi) 112 return -1; 113 } 114 return index; 115 } 116 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org [-- Attachment #2: .config.gz --] [-- Type: application/gzip, Size: 65029 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2] net: ipv6: fix use-after-free Read in __xfrm6_tunnel_spi_lookup 2020-07-26 3:08 [PATCH v2] net: ipv6: fix use-after-free Read in __xfrm6_tunnel_spi_lookup B K Karthik 2020-07-26 5:35 ` Cong Wang 2020-07-26 7:20 ` kernel test robot @ 2020-07-26 10:37 ` kernel test robot 2020-07-29 0:36 ` David Miller 3 siblings, 0 replies; 9+ messages in thread From: kernel test robot @ 2020-07-26 10:37 UTC (permalink / raw) To: B K Karthik, Steffen Klassert, Herbert Xu, David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI, Jakub Kicinski, linux-kernel, gregkh, skhan Cc: kbuild-all, clang-built-linux, netdev [-- Attachment #1: Type: text/plain, Size: 2569 bytes --] Hi K, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on ipsec/master] [also build test WARNING on ipsec-next/master sparc-next/master net-next/master net/master v5.8-rc6 next-20200724] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/B-K-Karthik/net-ipv6-fix-use-after-free-Read-in-__xfrm6_tunnel_spi_lookup/20200726-111019 base: https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec.git master config: x86_64-randconfig-a001-20200726 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 8bf4c1f4fb257774f66c8cda07adc6c5e8668326) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install x86_64 cross compiling tool for clang build # apt-get install binutils-x86-64-linux-gnu # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot <lkp@intel.com> All warnings (new ones prefixed by >>): >> net/ipv6/xfrm6_tunnel.c:106:43: warning: cast to 'const xfrm_address_t *' from smaller integer type 'u32' (aka 'unsigned int') [-Wint-to-pointer-cast] int index = xfrm6_tunnel_spi_hash_byaddr((const xfrm_address_t *)spi); ^~~~~~~~~~~~~~~~~~~~~~~~~~~ net/ipv6/xfrm6_tunnel.c:69:28: warning: unused function 'xfrm6_tunnel_spi_hash_byspi' [-Wunused-function] static inline unsigned int xfrm6_tunnel_spi_hash_byspi(u32 spi) ^ 2 warnings generated. vim +106 net/ipv6/xfrm6_tunnel.c 101 102 static int __xfrm6_tunnel_spi_check(struct net *net, u32 spi) 103 { 104 struct xfrm6_tunnel_net *xfrm6_tn = xfrm6_tunnel_pernet(net); 105 struct xfrm6_tunnel_spi *x6spi; > 106 int index = xfrm6_tunnel_spi_hash_byaddr((const xfrm_address_t *)spi); 107 108 hlist_for_each_entry(x6spi, 109 &xfrm6_tn->spi_byaddr[index], 110 list_byspi) { 111 if (x6spi->spi == spi) 112 return -1; 113 } 114 return index; 115 } 116 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org [-- Attachment #2: .config.gz --] [-- Type: application/gzip, Size: 37075 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2] net: ipv6: fix use-after-free Read in __xfrm6_tunnel_spi_lookup 2020-07-26 3:08 [PATCH v2] net: ipv6: fix use-after-free Read in __xfrm6_tunnel_spi_lookup B K Karthik ` (2 preceding siblings ...) 2020-07-26 10:37 ` kernel test robot @ 2020-07-29 0:36 ` David Miller 3 siblings, 0 replies; 9+ messages in thread From: David Miller @ 2020-07-29 0:36 UTC (permalink / raw) To: bkkarthik Cc: steffen.klassert, herbert, kuznet, yoshfuji, kuba, netdev, linux-kernel, gregkh, skhan, linux-kernel-mentees From: B K Karthik <bkkarthik@pesu.pes.edu> Date: Sun, 26 Jul 2020 08:38:55 +0530 > @@ -103,10 +103,10 @@ static int __xfrm6_tunnel_spi_check(struct net *net, u32 spi) > { > struct xfrm6_tunnel_net *xfrm6_tn = xfrm6_tunnel_pernet(net); > struct xfrm6_tunnel_spi *x6spi; > - int index = xfrm6_tunnel_spi_hash_byspi(spi); > + int index = xfrm6_tunnel_spi_hash_byaddr((const xfrm_address_t *)spi); We can cast this a thousand times to make the compiler quiet, but the fact is that this function does not expect an integer SPI as an argument. It expects a protocol address. Please stop forcing this fix, I fear you don't understand how this code works. Come back to us when you do. Thank you. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-07-29 0:36 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-07-26 3:08 [PATCH v2] net: ipv6: fix use-after-free Read in __xfrm6_tunnel_spi_lookup B K Karthik 2020-07-26 5:35 ` Cong Wang 2020-07-26 6:12 ` B K Karthik 2020-07-26 20:07 ` Cong Wang 2020-07-27 5:19 ` B K Karthik 2020-07-27 9:50 ` Steffen Klassert 2020-07-26 7:20 ` kernel test robot 2020-07-26 10:37 ` kernel test robot 2020-07-29 0:36 ` David Miller
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).