-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Reclaim one byte from HeaderString. #6826
Reclaim one byte from HeaderString. #6826
Conversation
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.
Nice thanks for doing all of these follow ups. I assume you audited all calls to make sure we aren't using data()
anywhere in the existing code? I know we caught some last time.
/wait
With conversion to getStringView() access there is no longer any need to reserve a NUL byte at the end of the HeaderString since all accesses will be through string_views which are not required to be NUL terminated. Ran bazel test -c opt //test/... --config=asan --runs_per_test=10 without issue. There is some risk that someone has or will abuse the data() accessor on a string_view assuming it is NUL terminated. A comment is added to emphasize that the HeaderString::getStringView() is not NUL terminated. By eliminating this wasted byte it is more likely that a HeaderString will fit into the existing embedded space, hopefully giving a small performance gain and reduction in memory allocations. Signed-off-by: Dan Noé <[email protected]>
Signed-off-by: Dan Noé <[email protected]>
14cb6ca
to
16c6604
Compare
Sorry about the force push, somehow I screwed up my local branch trying to be smart. It should be the same two commits, so you can see the changes by looking at the second commit. |
Manual inspection finds no mis-use of |
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.
🙏
This is failing header_map_impl_fuzz due to memcpy heap buffer overflow and should be considered a serious security issue. Given this was only introduced in the last day and does not affect any release, a revert and bump is the consensus of Envoy security team. This reverts commit 977907d. Fixes oss-fuzz issue https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14639. Risk level: Low Testing: Corpus entry added, bazel test //test/common/http:header_map_impl_fuzz_test --test_output=all -c dbg --config=clang-asan Signed-off-by: Harvey Tuch <[email protected]>
This is failing header_map_impl_fuzz due to memcpy heap buffer overflow and should be considered a serious security issue. Given this was only introduced in the last day and does not affect any release, a revert and bump is the consensus of Envoy security team. This reverts commit 977907d. Fixes oss-fuzz issue https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14639. Risk level: Low Testing: Corpus entry added, bazel test //test/common/http:header_map_impl_fuzz_test --test_output=all -c dbg --config=clang-asan Signed-off-by: Harvey Tuch <[email protected]>
Description:
With conversion to
getStringView()
access there is no longer any need toreserve a NUL byte at the end of the HeaderString since all accesses
will be through string_views which are not required to be NUL
terminated.
Ran
bazel test -c opt //test/... --config=asan --runs_per_test=10
without issue. There is some risk that someone has or will abuse the
data() accessor on a string_view assuming it is NUL terminated. A
comment is added to emphasize that the
HeaderString::getStringView()
isnot NUL terminated.
By eliminating this wasted byte it is more likely that a HeaderString
will fit into the existing embedded space, hopefully giving a small
performance gain and reduction in memory allocations.
Signed-off-by: Dan Noé [email protected]
Risk Level: Medium
Testing:
bazel test -c opt //test/... --config=asan --runs_per_test=10
Docs Changes: None
Release Notes: None
Part of: Issue #6580