netdev - Re: [PATCH net] ipv6: don't get lwtstate twice in ip6_rt_copy

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e5d5c37d-2ae7-3f35-22ea-eaddd763c9c4@oracle.com>
Date:   Fri, 31 Aug 2018 16:44:04 +0300
From:   Alexey Kodanev <alexey.kodanev@...cle.com>
To:     David Ahern <dsahern@...il.com>, netdev@...r.kernel.org
Cc:     David Miller <davem@...emloft.net>
Subject: Re: [PATCH net] ipv6: don't get lwtstate twice in ip6_rt_copy_init()

On 30.08.2018 19:10, David Ahern wrote:
> On 8/30/18 10:11 AM, Alexey Kodanev wrote:
...
>> unreferenced object 0xffff880b6aaa14e0 (size 64):
>>   comm "ip", pid 10577, jiffies 4295149341 (age 1273.903s)
>>   hex dump (first 32 bytes):
>>     01 00 04 00 04 00 00 00 10 00 00 00 00 00 00 00  ................
>>     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>>   backtrace:
>>     [<0000000018664623>] lwtunnel_build_state+0x1bc/0x420
>>     [<00000000b73aa29a>] ip6_route_info_create+0x9f7/0x1fd0
>>     [<00000000ee2c5d1f>] ip6_route_add+0x14/0x70
>>     [<000000008537b55c>] inet6_rtm_newroute+0xd9/0xe0
>>     [<000000002acc50f5>] rtnetlink_rcv_msg+0x66f/0x8e0
>>     [<000000008d9cd381>] netlink_rcv_skb+0x268/0x3b0
>>     [<000000004c893c76>] netlink_unicast+0x417/0x5a0
>>     [<00000000f2ab1afb>] netlink_sendmsg+0x70b/0xc30
>>     [<00000000890ff0aa>] sock_sendmsg+0xb1/0xf0
>>     [<00000000a2e7b66f>] ___sys_sendmsg+0x659/0x950
>>     [<000000001e7426c8>] __sys_sendmsg+0xde/0x170
>>     [<00000000fe411443>] do_syscall_64+0x9f/0x4a0
>>     [<000000001be7b28b>] entry_SYSCALL_64_after_hwframe+0x49/0xbe
>>     [<000000006d21f353>] 0xffffffffffffffff
> 
> What test did you run to uncover this? Curious as to why my testing that
> found the need for 80f1a0f4e0cd did not hit this.

I was using IPv6 route with MPLS. Will submit MPLS tests to LTP soon,
they will include that test as well.

Meanwhile, these commands below are able to trigger it:

  ip route add $new_route encap mpls 50 via inet6 $ip_rhost
  ping6 $ip_new_route
  ip route del $new_route

Thanks,
Alexey