* [PATCH] net: ipv6: fix wrong start position when receive hop-by-hop fragment
@ 2024-04-22 1:10 gaoxingwang
2024-04-22 9:19 ` [PATCH v2] " gaoxingwang
0 siblings, 1 reply; 3+ messages in thread
From: gaoxingwang @ 2024-04-22 1:10 UTC (permalink / raw)
To: davem, dsahern; +Cc: netdev, linux-kernel, edumazet, kuba, pabeni, yanan
In IPv6, ipv6_rcv_core will parse the hop-by-hop type extension header and increase skb->transport_header by one extension header length.
But if there are more other extension headers like fragment header at this time, the skb->transport_header points to the second extension header,
not the transport layer header or the first extension header.
This will result in the start and nexthdrp variable not pointing to the same position in ipv6frag_thdr_trunced,
and ipv6_skip_exthdr returning incorrect offset and frag_off.Sometimes, the length of the last sharded packet is smaller than the calculated incorrect offset, resulting in packet loss.
We can use network header to offset and calculate the correct position to solve this problem.
Fixes: 9d9e937b1c8b (ipv6/netfilter: Discard first fragment not including all headers)
Signed-off-by: Gao Xingwang <gaoxingwang1@huawei.com>
---
net/ipv6/reassembly.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/reassembly.c b/net/ipv6/reassembly.c
index 5ebc47da1000..b3fc3a53cbbe 100644
--- a/net/ipv6/reassembly.c
+++ b/net/ipv6/reassembly.c
@@ -369,7 +369,7 @@ static int ipv6_frag_rcv(struct sk_buff *skb)
* the source of the fragment, with the Pointer field set to zero.
*/
nexthdr = hdr->nexthdr;
- if (ipv6frag_thdr_truncated(skb, skb_transport_offset(skb), &nexthdr)) {
+ if (ipv6frag_thdr_truncated(skb, skb_network_offset(skb) + siezof(struct ipv6hdr), &nexthdr)) {
__IP6_INC_STATS(net, __in6_dev_get_safely(skb->dev),
IPSTATS_MIB_INHDRERRORS);
icmpv6_param_prob(skb, ICMPV6_HDR_INCOMP, 0);
--
2.27.0
^ permalink raw reply related [flat|nested] 3+ messages in thread
* [PATCH v2] net: ipv6: fix wrong start position when receive hop-by-hop fragment
2024-04-22 1:10 [PATCH] net: ipv6: fix wrong start position when receive hop-by-hop fragment gaoxingwang
@ 2024-04-22 9:19 ` gaoxingwang
2024-04-25 2:51 ` Jakub Kicinski
0 siblings, 1 reply; 3+ messages in thread
From: gaoxingwang @ 2024-04-22 9:19 UTC (permalink / raw)
To: gaoxingwang1
Cc: davem, dsahern, edumazet, kuba, linux-kernel, netdev, pabeni,
yanan
In IPv6, ipv6_rcv_core will parse the hop-by-hop type extension header and increase skb->transport_header by one extension header length.
But if there are more other extension headers like fragment header at this time, the skb->transport_header points to the second extension header,
not the transport layer header or the first extension header.
This will result in the start and nexthdrp variable not pointing to the same position in ipv6frag_thdr_trunced,
and ipv6_skip_exthdr returning incorrect offset and frag_off.Sometimes,the length of the last sharded packet is smaller than the calculated incorrect offset, resulting in packet loss.
We can use network header to offset and calculate the correct position to solve this problem.
Fixes: 9d9e937b1c8b (ipv6/netfilter: Discard first fragment not including all headers)
Signed-off-by: Gao Xingwang <gaoxingwang1@huawei.com>
---
net/ipv6/reassembly.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/reassembly.c b/net/ipv6/reassembly.c
index 5ebc47da1000..2af98edef87e 100644
--- a/net/ipv6/reassembly.c
+++ b/net/ipv6/reassembly.c
@@ -369,7 +369,7 @@ static int ipv6_frag_rcv(struct sk_buff *skb)
* the source of the fragment, with the Pointer field set to zero.
*/
nexthdr = hdr->nexthdr;
- if (ipv6frag_thdr_truncated(skb, skb_transport_offset(skb), &nexthdr)) {
+ if (ipv6frag_thdr_truncated(skb, skb_network_offset(skb) + sizeof(struct ipv6hdr), &nexthdr)) {
__IP6_INC_STATS(net, __in6_dev_get_safely(skb->dev),
IPSTATS_MIB_INHDRERRORS);
icmpv6_param_prob(skb, ICMPV6_HDR_INCOMP, 0);
--
2.27.0
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH v2] net: ipv6: fix wrong start position when receive hop-by-hop fragment
2024-04-22 9:19 ` [PATCH v2] " gaoxingwang
@ 2024-04-25 2:51 ` Jakub Kicinski
0 siblings, 0 replies; 3+ messages in thread
From: Jakub Kicinski @ 2024-04-25 2:51 UTC (permalink / raw)
To: gaoxingwang; +Cc: davem, dsahern, edumazet, linux-kernel, netdev, pabeni, yanan
On Mon, 22 Apr 2024 17:19:17 +0800 gaoxingwang wrote:
> In IPv6, ipv6_rcv_core will parse the hop-by-hop type extension header and increase skb->transport_header by one extension header length.
> But if there are more other extension headers like fragment header at this time, the skb->transport_header points to the second extension header,
> not the transport layer header or the first extension header.
>
> This will result in the start and nexthdrp variable not pointing to the same position in ipv6frag_thdr_trunced,
> and ipv6_skip_exthdr returning incorrect offset and frag_off.Sometimes,the length of the last sharded packet is smaller than the calculated incorrect offset, resulting in packet loss.
> We can use network header to offset and calculate the correct position to solve this problem.
>
> Fixes: 9d9e937b1c8b (ipv6/netfilter: Discard first fragment not including all headers)
nits:
- this is not correct format for Fixes, missing quotes
- please wrap the message at 72 chars
- please make sure you add spaces after punctuation
- please make sure you don't send new version of the patch in reply to
old, add a lore link to previous version under --- instead
About the code - how are you testing this?
What's the packet you're saying we drop?
If transport_header can't be trusted there may be more in this
function to fix..
--
pw-bot: cr
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2024-04-25 2:51 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-04-22 1:10 [PATCH] net: ipv6: fix wrong start position when receive hop-by-hop fragment gaoxingwang
2024-04-22 9:19 ` [PATCH v2] " gaoxingwang
2024-04-25 2:51 ` Jakub Kicinski
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 read-only IMAP folder(s) and NNTP newsgroup(s).