aboutsummaryrefslogtreecommitdiff
path: root/net/unix/unix_bpf.c
diff options
context:
space:
mode:
authorYan Zhai <yan@cloudflare.com>2023-10-24 07:26:40 -0700
committerJakub Kicinski <kuba@kernel.org>2023-10-25 18:04:29 -0700
commit03d6c848bfb406e9ef6d9846d759e97beaeea113 (patch)
tree9283e779aab9e7621bb9ae824dcadb28f699096e /net/unix/unix_bpf.c
parent1f7ec1b3721d7f49f13d01e6f5ed5f28a305e3b6 (diff)
ipv6: avoid atomic fragment on GSO packets
When the ipv6 stack output a GSO packet, if its gso_size is larger than dst MTU, then all segments would be fragmented. However, it is possible for a GSO packet to have a trailing segment with smaller actual size than both gso_size as well as the MTU, which leads to an "atomic fragment". Atomic fragments are considered harmful in RFC-8021. An Existing report from APNIC also shows that atomic fragments are more likely to be dropped even it is equivalent to a no-op [1]. Add an extra check in the GSO slow output path. For each segment from the original over-sized packet, if it fits with the path MTU, then avoid generating an atomic fragment. Link: https://www.potaroo.net/presentations/2022-03-01-ipv6-frag.pdf [1] Fixes: b210de4f8c97 ("net: ipv6: Validate GSO SKB before finish IPv6 processing") Reported-by: David Wragg <dwragg@cloudflare.com> Signed-off-by: Yan Zhai <yan@cloudflare.com> Link: https://lore.kernel.org/r/90912e3503a242dca0bc36958b11ed03a2696e5e.1698156966.git.yan@cloudflare.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'net/unix/unix_bpf.c')
0 files changed, 0 insertions, 0 deletions