New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bpf: lxc: fix L4 offset in RevNAT path for IPv6 extension headers #27312
Merged
julianwiedmann
merged 1 commit into
cilium:main
from
julianwiedmann:1.15-bpf-lxc-ipv6-hdrlen
Aug 8, 2023
Merged
bpf: lxc: fix L4 offset in RevNAT path for IPv6 extension headers #27312
julianwiedmann
merged 1 commit into
cilium:main
from
julianwiedmann:1.15-bpf-lxc-ipv6-hdrlen
Aug 8, 2023
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The typical pattern to determine the L4 offset of an IPv6 packet is tuple->nexthdr = ip6->nexthdr; hdrlen = ipv6_hdrlen(ctx, &tuple->nexthdr); if (hdrlen < 0) return hdrlen; l4_off = ETH_HLEN + hdrlen; ipv6_hdrlen() then walks the extension headers and adds up their length, until it reaches the TCP/UDP/... header. For bpf_lxc, 38b4a61 ("bpf: Split CT lookup to its own tail call") split off the CT lookup into a separate tail-call. Subsequent code retrieves the lookup result and a fully populated CT tuple from the CT_TAIL_CALL_BUFFER6. For the IPv6 paths this means that tuple->nexthdr already contains the L4 proto. When ipv6_hdrlen() is called a second time with this value, it believes that the packet has no extension headers and returns a wrong L4 offset. Go for the minimal fix and re-initialize tuple->nexthdr in the affected paths. Fixes: 38b4a61 ("bpf: Split CT lookup to its own tail call") Signed-off-by: Julian Wiedmann <jwi@isovalent.com>
julianwiedmann
added
kind/bug
This is a bug in the Cilium logic.
sig/datapath
Impacts bpf/ or low-level forwarding details, including map management and monitor messages.
release-note/bug
This PR fixes an issue in a previous release of Cilium.
feature/ipv6
Relates to IPv6 protocol support
area/loadbalancing
Impacts load-balancing and Kubernetes service implementations
needs-backport/1.12
needs-backport/1.13
This PR / issue needs backporting to the v1.13 branch
needs-backport/1.14
This PR / issue needs backporting to the v1.14 branch
labels
Aug 7, 2023
/test |
jschwinger233
approved these changes
Aug 8, 2023
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
maintainer-s-little-helper
bot
added
the
ready-to-merge
This PR has passed all tests and received consensus from code owners to merge.
label
Aug 8, 2023
joamaki
added
backport-pending/1.14
The backport for Cilium 1.14.x for this PR is in progress.
backport-done/1.14
The backport for Cilium 1.14.x for this PR is done.
and removed
needs-backport/1.14
This PR / issue needs backporting to the v1.14 branch
backport-pending/1.14
The backport for Cilium 1.14.x for this PR is in progress.
labels
Aug 8, 2023
joamaki
added
backport-pending/1.13
The backport for Cilium 1.13.x for this PR is in progress.
and removed
needs-backport/1.13
This PR / issue needs backporting to the v1.13 branch
labels
Aug 9, 2023
maintainer-s-little-helper
bot
moved this from Needs backport from main
to Backport done to v1.14
in 1.14.1
Aug 9, 2023
maintainer-s-little-helper
bot
moved this from Needs backport from main
to Backport pending to v1.13
in 1.13.6
Aug 9, 2023
maintainer-s-little-helper
bot
moved this from Needs backport from main
to Backport pending to v1.12
in 1.12.13
Aug 9, 2023
maintainer-s-little-helper
bot
moved this from Backport pending to v1.12
to Needs backport from main
in 1.12.13
Aug 13, 2023
YutaroHayakawa
added
backport-done/1.13
The backport for Cilium 1.13.x for this PR is done.
backport-done/1.12
The backport for Cilium 1.12.x for this PR is done.
and removed
backport-pending/1.13
The backport for Cilium 1.13.x for this PR is in progress.
needs-backport/1.12
labels
Aug 17, 2023
joestringer
moved this from Needs backport from main
to Backport done to v1.12
in 1.12.14
Aug 25, 2023
joestringer
moved this from Backport pending to v1.13
to Backport done to v1.13
in 1.13.7
Aug 25, 2023
This was referenced Sep 9, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
area/loadbalancing
Impacts load-balancing and Kubernetes service implementations
backport-done/1.12
The backport for Cilium 1.12.x for this PR is done.
backport-done/1.13
The backport for Cilium 1.13.x for this PR is done.
backport-done/1.14
The backport for Cilium 1.14.x for this PR is done.
feature/ipv6
Relates to IPv6 protocol support
kind/bug
This is a bug in the Cilium logic.
ready-to-merge
This PR has passed all tests and received consensus from code owners to merge.
release-note/bug
This PR fixes an issue in a previous release of Cilium.
sig/datapath
Impacts bpf/ or low-level forwarding details, including map management and monitor messages.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The typical pattern to determine the L4 offset of an IPv6 packet is
ipv6_hdrlen() then walks the extension headers and adds up their length, until it reaches the TCP/UDP/... header.
For bpf_lxc, 38b4a61 ("bpf: Split CT lookup to its own tail call") split off the CT lookup into a separate tail-call. Subsequent code retrieves the lookup result and a fully populated CT tuple from the CT_TAIL_CALL_BUFFER6.
For the IPv6 paths this means that tuple->nexthdr already contains the L4 proto. When ipv6_hdrlen() is called a second time with this value, it believes that the packet has no extension headers and returns a wrong L4 offset.
Go for the minimal fix and re-initialize tuple->nexthdr in the affected paths.