* [PATCH] xfrm: xfrm_input: fix a possible memory leak in xfrm_input()
@ 2022-05-30 10:20 Hangyu Hua
2022-05-30 10:37 ` Steffen Klassert
0 siblings, 1 reply; 5+ messages in thread
From: Hangyu Hua @ 2022-05-30 10:20 UTC (permalink / raw)
To: steffen.klassert, herbert, davem, edumazet, kuba, pabeni
Cc: netdev, linux-kernel, Hangyu Hua
xfrm_input needs to handle skb internally. But skb is not freed When
xo->flags & XFRM_GRO == 0 and decaps == 0.
Fixes: 7785bba299a8 ("esp: Add a software GRO codepath")
Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
---
net/xfrm/xfrm_input.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
index 144238a50f3d..6f9576352f30 100644
--- a/net/xfrm/xfrm_input.c
+++ b/net/xfrm/xfrm_input.c
@@ -742,7 +742,7 @@ int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type)
gro_cells_receive(&gro_cells, skb);
return err;
}
-
+ kfree_skb(skb);
return err;
}
--
2.25.1
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] xfrm: xfrm_input: fix a possible memory leak in xfrm_input()
2022-05-30 10:20 [PATCH] xfrm: xfrm_input: fix a possible memory leak in xfrm_input() Hangyu Hua
@ 2022-05-30 10:37 ` Steffen Klassert
2022-05-31 2:12 ` Hangyu Hua
0 siblings, 1 reply; 5+ messages in thread
From: Steffen Klassert @ 2022-05-30 10:37 UTC (permalink / raw)
To: Hangyu Hua; +Cc: herbert, davem, edumazet, kuba, pabeni, netdev, linux-kernel
On Mon, May 30, 2022 at 06:20:46PM +0800, Hangyu Hua wrote:
> xfrm_input needs to handle skb internally. But skb is not freed When
> xo->flags & XFRM_GRO == 0 and decaps == 0.
>
> Fixes: 7785bba299a8 ("esp: Add a software GRO codepath")
> Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
> ---
> net/xfrm/xfrm_input.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
> index 144238a50f3d..6f9576352f30 100644
> --- a/net/xfrm/xfrm_input.c
> +++ b/net/xfrm/xfrm_input.c
> @@ -742,7 +742,7 @@ int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type)
> gro_cells_receive(&gro_cells, skb);
> return err;
> }
> -
> + kfree_skb(skb);
> return err;
> }
Did you test this? The function behind the 'afinfo->the transport_finish()'
pointer handles this skb and frees it in that case.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] xfrm: xfrm_input: fix a possible memory leak in xfrm_input()
2022-05-30 10:37 ` Steffen Klassert
@ 2022-05-31 2:12 ` Hangyu Hua
2022-05-31 11:35 ` Steffen Klassert
0 siblings, 1 reply; 5+ messages in thread
From: Hangyu Hua @ 2022-05-31 2:12 UTC (permalink / raw)
To: Steffen Klassert
Cc: herbert, davem, edumazet, kuba, pabeni, netdev, linux-kernel
On 2022/5/30 18:37, Steffen Klassert wrote:
> On Mon, May 30, 2022 at 06:20:46PM +0800, Hangyu Hua wrote:
>> xfrm_input needs to handle skb internally. But skb is not freed When
>> xo->flags & XFRM_GRO == 0 and decaps == 0.
>>
>> Fixes: 7785bba299a8 ("esp: Add a software GRO codepath")
>> Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
>> ---
>> net/xfrm/xfrm_input.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
>> index 144238a50f3d..6f9576352f30 100644
>> --- a/net/xfrm/xfrm_input.c
>> +++ b/net/xfrm/xfrm_input.c
>> @@ -742,7 +742,7 @@ int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type)
>> gro_cells_receive(&gro_cells, skb);
>> return err;
>> }
>> -
>> + kfree_skb(skb);
>> return err;
>> }
>
> Did you test this? The function behind the 'afinfo->the transport_finish()'
> pointer handles this skb and frees it in that case.
int xfrm4_transport_finish(struct sk_buff *skb, int async)
{
struct xfrm_offload *xo = xfrm_offload(skb);
struct iphdr *iph = ip_hdr(skb);
iph->protocol = XFRM_MODE_SKB_CB(skb)->protocol;
#ifndef CONFIG_NETFILTER
if (!async)
return -iph->protocol; <--- [1]
#endif
...
NF_HOOK(NFPROTO_IPV4, NF_INET_PRE_ROUTING,
dev_net(skb->dev), NULL, skb, skb->dev, NULL,
xfrm4_rcv_encap_finish); <--- [2]
return 0;
}
int xfrm6_transport_finish(struct sk_buff *skb, int async)
{
struct xfrm_offload *xo = xfrm_offload(skb);
int nhlen = skb->data - skb_network_header(skb);
skb_network_header(skb)[IP6CB(skb)->nhoff] =
XFRM_MODE_SKB_CB(skb)->protocol;
#ifndef CONFIG_NETFILTER
if (!async)
return 1; <--- [3]
#endif
...
NF_HOOK(NFPROTO_IPV6, NF_INET_PRE_ROUTING,
dev_net(skb->dev), NULL, skb, skb->dev, NULL,
xfrm6_transport_finish2);
return 0; <--- [4]
}
If transport_finish() return in [1] or [3], there will be a memory leak.
If it return return in [2] and [4], there will not be a memory leak. It
look like my patch is incorrect.
How do you think i modify the patch as follows?
gro_cells_receive(&gro_cells, skb);
return err;
}
-
+ if (err != 0)
+ kfree_skb(skb);
return err;
}
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] xfrm: xfrm_input: fix a possible memory leak in xfrm_input()
2022-05-31 2:12 ` Hangyu Hua
@ 2022-05-31 11:35 ` Steffen Klassert
2022-06-01 2:47 ` Hangyu Hua
0 siblings, 1 reply; 5+ messages in thread
From: Steffen Klassert @ 2022-05-31 11:35 UTC (permalink / raw)
To: Hangyu Hua; +Cc: herbert, davem, edumazet, kuba, pabeni, netdev, linux-kernel
On Tue, May 31, 2022 at 10:12:05AM +0800, Hangyu Hua wrote:
> On 2022/5/30 18:37, Steffen Klassert wrote:
> > On Mon, May 30, 2022 at 06:20:46PM +0800, Hangyu Hua wrote:
> > > xfrm_input needs to handle skb internally. But skb is not freed When
> > > xo->flags & XFRM_GRO == 0 and decaps == 0.
> > >
> > > Fixes: 7785bba299a8 ("esp: Add a software GRO codepath")
> > > Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
> > > ---
> > > net/xfrm/xfrm_input.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
> > > index 144238a50f3d..6f9576352f30 100644
> > > --- a/net/xfrm/xfrm_input.c
> > > +++ b/net/xfrm/xfrm_input.c
> > > @@ -742,7 +742,7 @@ int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type)
> > > gro_cells_receive(&gro_cells, skb);
> > > return err;
> > > }
> > > -
> > > + kfree_skb(skb);
> > > return err;
> > > }
> >
> > Did you test this? The function behind the 'afinfo->the transport_finish()'
> > pointer handles this skb and frees it in that case.
>
> int xfrm4_transport_finish(struct sk_buff *skb, int async)
> {
> struct xfrm_offload *xo = xfrm_offload(skb);
> struct iphdr *iph = ip_hdr(skb);
>
> iph->protocol = XFRM_MODE_SKB_CB(skb)->protocol;
>
> #ifndef CONFIG_NETFILTER
> if (!async)
> return -iph->protocol; <--- [1]
> #endif
> ...
> NF_HOOK(NFPROTO_IPV4, NF_INET_PRE_ROUTING,
> dev_net(skb->dev), NULL, skb, skb->dev, NULL,
> xfrm4_rcv_encap_finish); <--- [2]
> return 0;
> }
>
> int xfrm6_transport_finish(struct sk_buff *skb, int async)
> {
> struct xfrm_offload *xo = xfrm_offload(skb);
> int nhlen = skb->data - skb_network_header(skb);
>
> skb_network_header(skb)[IP6CB(skb)->nhoff] =
> XFRM_MODE_SKB_CB(skb)->protocol;
>
> #ifndef CONFIG_NETFILTER
> if (!async)
> return 1; <--- [3]
> #endif
> ...
> NF_HOOK(NFPROTO_IPV6, NF_INET_PRE_ROUTING,
> dev_net(skb->dev), NULL, skb, skb->dev, NULL,
> xfrm6_transport_finish2);
> return 0; <--- [4]
> }
>
> If transport_finish() return in [1] or [3], there will be a memory leak.
No, even in that case there is no memleak. Look for instance at the
IPv4 case, we return -iph->protocol here.
Then look at ip_protocol_deliver_rcu(). If the ipprot->handler (xfrm)
returns a negative value, this is interpreted as the protocol number
and the packet is resubmitted to the next protocol handler.
Please test your patches before you submit them in the future.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] xfrm: xfrm_input: fix a possible memory leak in xfrm_input()
2022-05-31 11:35 ` Steffen Klassert
@ 2022-06-01 2:47 ` Hangyu Hua
0 siblings, 0 replies; 5+ messages in thread
From: Hangyu Hua @ 2022-06-01 2:47 UTC (permalink / raw)
To: Steffen Klassert
Cc: herbert, davem, edumazet, kuba, pabeni, netdev, linux-kernel
On 2022/5/31 19:35, Steffen Klassert wrote:
> On Tue, May 31, 2022 at 10:12:05AM +0800, Hangyu Hua wrote:
>> On 2022/5/30 18:37, Steffen Klassert wrote:
>>> On Mon, May 30, 2022 at 06:20:46PM +0800, Hangyu Hua wrote:
>>>> xfrm_input needs to handle skb internally. But skb is not freed When
>>>> xo->flags & XFRM_GRO == 0 and decaps == 0.
>>>>
>>>> Fixes: 7785bba299a8 ("esp: Add a software GRO codepath")
>>>> Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
>>>> ---
>>>> net/xfrm/xfrm_input.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
>>>> index 144238a50f3d..6f9576352f30 100644
>>>> --- a/net/xfrm/xfrm_input.c
>>>> +++ b/net/xfrm/xfrm_input.c
>>>> @@ -742,7 +742,7 @@ int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type)
>>>> gro_cells_receive(&gro_cells, skb);
>>>> return err;
>>>> }
>>>> -
>>>> + kfree_skb(skb);
>>>> return err;
>>>> }
>>>
>>> Did you test this? The function behind the 'afinfo->the transport_finish()'
>>> pointer handles this skb and frees it in that case.
>>
>> int xfrm4_transport_finish(struct sk_buff *skb, int async)
>> {
>> struct xfrm_offload *xo = xfrm_offload(skb);
>> struct iphdr *iph = ip_hdr(skb);
>>
>> iph->protocol = XFRM_MODE_SKB_CB(skb)->protocol;
>>
>> #ifndef CONFIG_NETFILTER
>> if (!async)
>> return -iph->protocol; <--- [1]
>> #endif
>> ...
>> NF_HOOK(NFPROTO_IPV4, NF_INET_PRE_ROUTING,
>> dev_net(skb->dev), NULL, skb, skb->dev, NULL,
>> xfrm4_rcv_encap_finish); <--- [2]
>> return 0;
>> }
>>
>> int xfrm6_transport_finish(struct sk_buff *skb, int async)
>> {
>> struct xfrm_offload *xo = xfrm_offload(skb);
>> int nhlen = skb->data - skb_network_header(skb);
>>
>> skb_network_header(skb)[IP6CB(skb)->nhoff] =
>> XFRM_MODE_SKB_CB(skb)->protocol;
>>
>> #ifndef CONFIG_NETFILTER
>> if (!async)
>> return 1; <--- [3]
>> #endif
>> ...
>> NF_HOOK(NFPROTO_IPV6, NF_INET_PRE_ROUTING,
>> dev_net(skb->dev), NULL, skb, skb->dev, NULL,
>> xfrm6_transport_finish2);
>> return 0; <--- [4]
>> }
>>
>> If transport_finish() return in [1] or [3], there will be a memory leak.
>
> No, even in that case there is no memleak. Look for instance at the
> IPv4 case, we return -iph->protocol here.
> Then look at ip_protocol_deliver_rcu(). If the ipprot->handler (xfrm)
> returns a negative value, this is interpreted as the protocol number
> and the packet is resubmitted to the next protocol handler.
>
> Please test your patches before you submit them in the future.
Thanks for your explanation. I will be more careful in the future.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-06-01 2:47 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-05-30 10:20 [PATCH] xfrm: xfrm_input: fix a possible memory leak in xfrm_input() Hangyu Hua
2022-05-30 10:37 ` Steffen Klassert
2022-05-31 2:12 ` Hangyu Hua
2022-05-31 11:35 ` Steffen Klassert
2022-06-01 2:47 ` Hangyu Hua
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).