opentelemetry-go's Schema ParseFile leaks file descriptors on each parse

Summary

go.opentelemetry.io/otel/schema/v1.0 and go.opentelemetry.io/otel/schema/v1.1 leaks one file descriptor on each successful ParseFile call. ParseFile opens the schema file and passes it to Parse without closing it; repeated parsing in a long-running process can exhaust the process file descriptor limit and cause denial of service. The severity is low because exploitation depends on a consuming application exposing repeated schema parsing to an attacker-controlled path.

Introduced in commit: e72a235

Details

In schema/v1.0/parser.go:41-47, ParseFile opens the requested schema path with os.Open and then returns Parse(file) without a defer file.Close() or other close path:

file, err := os.Open(schemaFilePath)
if err != nil {
	return nil, err
}
return Parse(file)

The validation evidence also identifies schema/v1.0/parser.go:50-73: Parse accepts an io.Reader, decodes from it, and does not close it. Ownership of the opened file is therefore not transferred to Parse, leaving the descriptor open until the Go runtime eventually finalizes the file object. With repeated ParseFile calls, descriptors can accumulate until the process receives EMFILE / "too many open files".

PoC

validation-artifact.zip

The local artifact validation-artifact.zip contains:

• leak_poc.go: PoC source that repeatedly calls schema.ParseFile("schema/v1.0/testdata/valid-example.yaml") and prints /proc/self/fd counts.
• LEAK_POC_README.txt: reproduction notes.
• leak_poc_run.log: captured attempted run; the local offline environment failed before execution because Go module download from proxy.golang.org was forbidden.

Reproduce from the root of a checkout of pellared/opentelemetry-go at commit e72a235 with Go module dependencies already available:

/bin/sh -c 'ulimit -n 256; GOGC=off go run leak_poc.go'

Configuration:

• File descriptor soft limit: 256
• Garbage collection: disabled with GOGC=off so leaked descriptors are not reclaimed during the loop
• Schema file: schema/v1.0/testdata/valid-example.yaml

Expected output is increasing descriptor counts followed by an EMFILE failure, for example:

iter 0 fds 7
iter 50 fds 57
iter 100 fds 107
...
panic: iteration 248: open schema/v1.0/testdata/valid-example.yaml: too many open files

The exact initial descriptor count and failing iteration can vary by OS and process state.

Impact

This is a file descriptor resource leak leading to availability loss. Applications that call schema.ParseFile repeatedly, especially through a runtime reload or request-controlled path, can exhaust their process file descriptor table and fail subsequent file, socket, or other descriptor operations. Impact is limited to denial of service of the consuming process; the evidence does not show confidentiality or integrity impact.