netdev - Re: Regarding _skb_refdst memory alloc/dealloc

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: <e70f459d-10d3-f91c-d087-d62daa1446b7@alliedtelesis.co.nz>
Date:   Tue, 3 May 2022 03:52:19 +0000
From:   Lokesh Dhoundiyal <Lokesh.Dhoundiyal@...iedtelesis.co.nz>
To:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: Regarding _skb_refdst memory alloc/dealloc

Hi,

Sorry for my repeated emails.

To add some background to my earlier message and get some advise on things.

While testing the scenario of GRE over IPsec with routing table learned 
via dynamic protocol (OSPF) we have observed the below mentioned leak.

Kmemleak output:
unreferenced object 0x8000000044bebb00 (size 256):
   comm "softirq", pid 0, jiffies 4294985356 (age 126.810s)
   hex dump (first 32 bytes):
     00 00 00 00 00 00 00 00 80 00 00 00 05 13 74 80 ..............t.
     80 00 00 00 04 9b bf f9 00 00 00 00 00 00 00 00 ................
   backtrace:
     [<00000000f83947e0>] __kmalloc+0x1e8/0x300
     [<00000000b7ed8dca>] metadata_dst_alloc+0x24/0x58
     [<0000000081d32c20>] __ipgre_rcv+0x100/0x2b8
     [<00000000824f6cf1>] gre_rcv+0x178/0x540
     [<00000000ccd4e162>] gre_rcv+0x7c/0xd8
     [<00000000c024b148>] ip_protocol_deliver_rcu+0x124/0x350
     [<000000006a483377>] ip_local_deliver_finish+0x54/0x68
     [<00000000d9271b3a>] ip_local_deliver+0x128/0x168
     [<00000000bd4968ae>] xfrm_trans_reinject+0xb8/0xf8
     [<0000000071672a19>] tasklet_action_common.isra.16+0xc4/0x1b0
     [<0000000062e9c336>] __do_softirq+0x1fc/0x3e0
     [<00000000013d7914>] irq_exit+0xc4/0xe0
     [<00000000a4d73e90>] plat_irq_dispatch+0x7c/0x108
     [<000000000751eb8e>] handle_int+0x16c/0x178
     [<000000001668023b>] _raw_spin_unlock_irqrestore+0x1c/0x28

Investigation indicated that the change to the "if" statement in the 
commit c0d59da79534 results in the allocation and assignment happening 
for the tunnel destination which then later gets overwritten by 
skb_dst_set in ip_route_input_mc without freeing the original buffer. I 
am trying to free this skb->_skb_refdst buffer before the new buffer is set.

Could you please advise the api to use for it. I am assuming that it is 
skb_dst_drop, Is that correct?

Cheers,

Lokesh

On 3/05/22 3:10 pm, lokeshd wrote:
> Hi,
>
> I have the tunnel destination entry set via skb_dst_set inside 
> ip_tunnel_rcv. I wish to release the memory referenced by 
> skb->_skb_refdst after use.
>
> Could you please advise the api to use for it. I am assuming that it 
> is skb_dst_drop, Is that correct?
>
> Cheers,
> Lokesh