__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: [email protected]
Reported-by: kernel test robot <[email protected]>
Signed-off-by: B K Karthik <[email protected]>
---
v1 -> v2:
added cast in arguement from u32 to (const xfrm_address_t *)
added Reported-by: kernel test robot <[email protected]>
removed Reported-by: [email protected]
added Reported-and-tested-by: [email protected]
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
On Sat, Jul 25, 2020 at 8:09 PM B K Karthik <[email protected]> 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.
On Sun, Jul 26, 2020 at 11:05 AM Cong Wang <[email protected]> wrote:
>
> On Sat, Jul 25, 2020 at 8:09 PM B K Karthik <[email protected]> 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 <[email protected]> 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
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 <[email protected]>
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/[email protected]
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 <[email protected]>
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/[email protected]
On Sat, Jul 25, 2020 at 11:12 PM B K Karthik <[email protected]> wrote:
>
> On Sun, Jul 26, 2020 at 11:05 AM Cong Wang <[email protected]> wrote:
> >
> > On Sat, Jul 25, 2020 at 8:09 PM B K Karthik <[email protected]> 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 <[email protected]> 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.
On Mon, Jul 27, 2020 at 1:37 AM Cong Wang <[email protected]> wrote:
>
> On Sat, Jul 25, 2020 at 11:12 PM B K Karthik <[email protected]> wrote:
> >
> > On Sun, Jul 26, 2020 at 11:05 AM Cong Wang <[email protected]> wrote:
> > >
> > > On Sat, Jul 25, 2020 at 8:09 PM B K Karthik <[email protected]> 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 <[email protected]> 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 <[email protected]> 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
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 <[email protected]> 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.
From: B K Karthik <[email protected]>
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.