[receiver/windowseventlog] Fix panic when rendering excessively long offset #36179
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
djaglowski
force-pushed
the
fix-panic-wel
branch
from
a46e350 to
adc3c79
Compare
TylerHelmuth
approved these changes
Nov 5, 2024
codeboten
approved these changes
Nov 5, 2024
|
@djaglowski - sorry, didn't see this one in time. Let me know if you have steps for a repro so I can take a deeper look. The change itself is fine for me. |
|
IIRC the in memory events themselves are limited to 64KiB but of course the XML representation can be much bigger. |
michael-burt
pushed a commit
to michael-burt/opentelemetry-collector-contrib
that referenced
this pull request
Nov 7, 2024
…offset (open-telemetry#36179) A user observed a panic in the receiver after updating to v0.112.0, where rendering info is expanded by default: ``` goroutine 69 [running]: github.com/open-telemetry/opentelemetry-collector-contrib/pkg/stanza/operator/input/windows.(*Buffer).ReadBytes(0x37?, 0x19?) C:/Users/runneradmin/go/pkg/mod/github.com/open-telemetry/opentelemetry-collector-contrib/pkg/[email protected]/operator/input/windows/buffer.go:26 +0x165 github.com/open-telemetry/opentelemetry-collector-contrib/pkg/stanza/operator/input/windows.(*Buffer).ReadWideChars(...) C:/Users/runneradmin/go/pkg/mod/github.com/open-telemetry/opentelemetry-collector-contrib/pkg/[email protected]/operator/input/windows/buffer.go:37 github.com/open-telemetry/opentelemetry-collector-contrib/pkg/stanza/operator/input/windows.(*Event).RenderDeep(0xc002aaf998, {{0xc003120000, 0x4000, 0x4000}}, {0x8c1b918?}) C:/Users/runneradmin/go/pkg/mod/github.com/open-telemetry/opentelemetry-collector-contrib/pkg/[email protected]/operator/input/windows/event.go:117 +0x155 github.com/open-telemetry/opentelemetry-collector-contrib/pkg/stanza/operator/input/windows.(*Input).renderDeepAndSend(0xc001ee3dc0, {0x9977160, 0xc00312c460}, {0x19}, {0x13b480ccd58?}) ``` @pjanotti This is a quick fix to avoid the panic by reading the full buffer, but not trying to read more. There may be a better behavior than this but I am not familiar with how the buffer size is established so am proposing to just read the full content for now.
dmitryax
pushed a commit
that referenced
this pull request
Nov 8, 2024
…36252) The root of the crash reported in #36179 was the fact that the `Buffer` struct being passed by value in recursive calls made it allocate the needed amount, but, after the return of the recursive call it attempted to read a buffer that was larger than the allocated buffer on the recursive call. The crash was going to be hit whenever an XML was larger than the default size of the buffer (16KiB). The code is a bit hard to test because its fully usage actually happens on the receiver where the buffer and its components are not visible. I'll look to add a test in a follow-up. cc @djaglowski Skipping changelog since #36179 covers it. --------- Co-authored-by: Daniel Jaglowski <[email protected]>
pull bot
pushed a commit
to abaguas/opentelemetry-collector-contrib
that referenced
this pull request
Nov 9, 2024
…pen-telemetry#36252) The root of the crash reported in open-telemetry#36179 was the fact that the `Buffer` struct being passed by value in recursive calls made it allocate the needed amount, but, after the return of the recursive call it attempted to read a buffer that was larger than the allocated buffer on the recursive call. The crash was going to be hit whenever an XML was larger than the default size of the buffer (16KiB). The code is a bit hard to test because its fully usage actually happens on the receiver where the buffer and its components are not visible. I'll look to add a test in a follow-up. cc @djaglowski Skipping changelog since open-telemetry#36179 covers it. --------- Co-authored-by: Daniel Jaglowski <[email protected]>
sbylica-splunk
pushed a commit
to sbylica-splunk/opentelemetry-collector-contrib
that referenced
this pull request
Dec 17, 2024
…offset (open-telemetry#36179) A user observed a panic in the receiver after updating to v0.112.0, where rendering info is expanded by default: ``` goroutine 69 [running]: github.com/open-telemetry/opentelemetry-collector-contrib/pkg/stanza/operator/input/windows.(*Buffer).ReadBytes(0x37?, 0x19?) C:/Users/runneradmin/go/pkg/mod/github.com/open-telemetry/opentelemetry-collector-contrib/pkg/[email protected]/operator/input/windows/buffer.go:26 +0x165 github.com/open-telemetry/opentelemetry-collector-contrib/pkg/stanza/operator/input/windows.(*Buffer).ReadWideChars(...) C:/Users/runneradmin/go/pkg/mod/github.com/open-telemetry/opentelemetry-collector-contrib/pkg/[email protected]/operator/input/windows/buffer.go:37 github.com/open-telemetry/opentelemetry-collector-contrib/pkg/stanza/operator/input/windows.(*Event).RenderDeep(0xc002aaf998, {{0xc003120000, 0x4000, 0x4000}}, {0x8c1b918?}) C:/Users/runneradmin/go/pkg/mod/github.com/open-telemetry/opentelemetry-collector-contrib/pkg/[email protected]/operator/input/windows/event.go:117 +0x155 github.com/open-telemetry/opentelemetry-collector-contrib/pkg/stanza/operator/input/windows.(*Input).renderDeepAndSend(0xc001ee3dc0, {0x9977160, 0xc00312c460}, {0x19}, {0x13b480ccd58?}) ``` @pjanotti This is a quick fix to avoid the panic by reading the full buffer, but not trying to read more. There may be a better behavior than this but I am not familiar with how the buffer size is established so am proposing to just read the full content for now.
sbylica-splunk
pushed a commit
to sbylica-splunk/opentelemetry-collector-contrib
that referenced
this pull request
Dec 17, 2024
…pen-telemetry#36252) The root of the crash reported in open-telemetry#36179 was the fact that the `Buffer` struct being passed by value in recursive calls made it allocate the needed amount, but, after the return of the recursive call it attempted to read a buffer that was larger than the allocated buffer on the recursive call. The crash was going to be hit whenever an XML was larger than the default size of the buffer (16KiB). The code is a bit hard to test because its fully usage actually happens on the receiver where the buffer and its components are not visible. I'll look to add a test in a follow-up. cc @djaglowski Skipping changelog since open-telemetry#36179 covers it. --------- Co-authored-by: Daniel Jaglowski <[email protected]>
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.
A user observed a panic in the receiver after updating to v0.112.0, where rendering info is expanded by default:
@pjanotti This is a quick fix to avoid the panic by reading the full buffer, but not trying to read more. There may be a better behavior than this but I am not familiar with how the buffer size is established so am proposing to just read the full content for now.