CVE-2026-45287

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: ```go 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](https://github.com/user-attachments/files/27494463/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: ```sh /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: ```text 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.