[PATCH v2] net: ipv6: fix use-after-free Read in __xfrm6_tunnel_spi_lookup

[PATCH v2] net: ipv6: fix use-after-free Read in __xfrm6_tunnel_spi_lookup

[B K Karthik]

[-- 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 --]

Re: [PATCH v2] net: ipv6: fix use-after-free Read in __xfrm6_tunnel_spi_lookup

[Cong Wang]

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.

Re: [PATCH v2] net: ipv6: fix use-after-free Read in __xfrm6_tunnel_spi_lookup

[B K Karthik]

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

Re: [PATCH v2] net: ipv6: fix use-after-free Read in __xfrm6_tunnel_spi_lookup

[Cong Wang]

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.

Re: [PATCH v2] net: ipv6: fix use-after-free Read in __xfrm6_tunnel_spi_lookup

[B K Karthik]

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

Re: [PATCH v2] net: ipv6: fix use-after-free Read in __xfrm6_tunnel_spi_lookup

[Steffen Klassert]

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.

Re: [PATCH v2] net: ipv6: fix use-after-free Read in __xfrm6_tunnel_spi_lookup

[kernel test robot]

[-- 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 --]

Re: [PATCH v2] net: ipv6: fix use-after-free Read in __xfrm6_tunnel_spi_lookup

[kernel test robot]

[-- 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 --]

Re: [PATCH v2] net: ipv6: fix use-after-free Read in __xfrm6_tunnel_spi_lookup

[David Miller]

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.