Repository navigation
Conversation
Signed-off-by: Sai Asish Y <say.apm35@gmail.com>
This branch has not been deployed
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
displayPdr calls into go-pfcp's SDFFilter() while logging a session establishment/modification request. If the SDF Filter's Flow-Description length lies about how many bytes follow (0xFFFE/0x7FFF with only a few actual bytes), go-pfcp v0.0.23 slices past the buffer and panics, taking the whole UPF down over a logging call. Fixes #638.
Added a recover around displayPdr so a bad IE only drops that log line instead of crashing the process, and a test that builds exactly this malformed SDF Filter and calls displayPdr directly. I confirmed the panic against the pinned go-pfcp dependency itself first (slice bounds out of range [:65538] with capacity 5) before writing the fix. cmd/core also imports the eBPF bindings that this repo generates via bpf2go/clang/libbpf in CI, so I couldn't build the full package locally on macOS to run the new test myself, but it exercises the same code path your CI already runs under go test ./cmd/....