GHSA-hjf4-fphr-2h65: Go/go.opentelemetry.io/otel/sdk/log vulnerability
Summary
A BatchingProcessor in go.opentelemetry.io/otel/sdk/log can enter a tight CPU loop when the asynchronous export buffer is full. Under exporter backpressure, attacker-driven high-volume log emission can keep the queue at or above the batch size, causing repeated immediate export retries and a denial of service through CPU exhaustion.
Introduced in commit: 4af9c20
Details
NewBatchingProcessor wraps the exporter with newBufferExporter(exporter, 1) (sdk/log/batch.go:116-122), so the asynchronous export input can fill quickly when the downstream exporter blocks. The poll goroutine dequeues a batch with b.q.TryDequeue, calls b.exporter.EnqueueExport(r), and then immediately sends on b.pollTrigger whenever qLen >= b.batchSize (sdk/log/batch.go:129-165).
bufferExporter.EnqueueExport is non-blocking: it sends to e.input if possible and returns false in the default case when the channel is full (sdk/log/exporter.go:221-248). TryDequeue leaves q.len unchanged when the write callback returns false (sdk/log/batch.go:289-314). Therefore, while the exporter is backpressured, EnqueueExport fails, the queue remains at or above one full batch, and the poll loop continuously retriggers itself without waiting for the ticker.
PoC
validation-artifact.zip
The validation artifact contains a PoC bundle:
- validation-artifact.tar:main.go: PoC source. - validation-artifact.tar:README.md: build/run notes. - validation-artifact.tar:buildfailed.log: captured build failure from the validation environment.
The PoC configures a blocking exporter and a BatchingProcessor with WithExportMaxBatchSize(1), WithExportInterval(5time.Second), and WithMaxQueueSize(2048). It emits 1000 records, records a CPU profile for 750 ms while the exporter is blocked, then writes /workspace/validationartifacts/busyloop.pprof.
Reproduction steps from an affected checkout at commit 4af9c20:
sh cd /workspace/opentelemetry-go git checkout 4af9c20
mkdir -p validationpoc/busyloop /workspace/validationartifacts /tmp/batchingprocessor-busyloop-poc tar -xf /path/to/this/finding/validation-artifact.tar -C /tmp/batchingprocessor-busyloop-poc cp /tmp/batchingprocessor-busyloop-poc/main.go validationpoc/busyloop/main.go
go build -o validationpoc/busyloop/busyloop ./validationpoc/busyloop ./validationpoc/busyloop/busyloop go tool pprof -top /workspace/validationartifacts/busyloop.pprof
Expected program output:
text cpu profile written to /workspace/validationartifacts/busyloop.pprof
Expected profile evidence: hot functions should include (BatchingProcessor).poll, (queue).TryDequeue, and (bufferExporter).EnqueueExport, showing repeated export attempts while the exporter is blocked.
Impact
This is an availability vulnerability: uncontrolled CPU consumption caused by a busy-spin retry loop. Applications using sdk/log BatchingProcessor are impacted when an attacker can cause sustained log emission and the configured exporter or downstream collector is slow, blocked, or otherwise backpressured. The impact is limited to the embedding process but can degrade or deny service for that application.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/go.opentelemetry.io/otel/sdk/logto a version that resolves this vulnerability.Fixed in 0.21.0
Event History
Frequently Asked Questions
What conditions are required for this issue to be triggered?
The downstream log exporter must be backpressured or blocked so that its asynchronous input buffer is full. High-volume log emission must also keep the batching queue at or above the configured batch size.
Is a custom asynchronous exporter buffer configuration required for exposure?
No. NewBatchingProcessor wraps its exporter with an asynchronous buffer capacity of one, so the export input can fill quickly when the downstream exporter blocks.
What can an attacker realistically influence?
An attacker who can cause the application to emit logs at high volume can sustain the condition while export is backpressured. The resulting repeated export attempts can exhaust CPU resources and deny service.
How does exporter backpressure lead to persistent CPU use?
When the exporter input is full, EnqueueExport returns without accepting the batch. The dequeue operation leaves the batch queued, and because the queue remains at least one batch long, the poll goroutine immediately triggers another export attempt.