+ "details": "### Summary\n\n`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.\n\nIntroduced in commit: e72a235\n\n### Details\n\nIn `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:\n\n```go\nfile, err := os.Open(schemaFilePath)\nif err != nil {\n\treturn nil, err\n}\nreturn Parse(file)\n```\n\nThe 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\".\n\n### PoC\n\n[validation-artifact.zip](https://github.com/user-attachments/files/27494463/validation-artifact.zip)\n\nThe local artifact `validation-artifact.zip` contains:\n\n- `leak_poc.go`: PoC source that repeatedly calls `schema.ParseFile(\"schema/v1.0/testdata/valid-example.yaml\")` and prints `/proc/self/fd` counts.\n- `LEAK_POC_README.txt`: reproduction notes.\n- `leak_poc_run.log`: captured attempted run; the local offline environment failed before execution because Go module download from `proxy.golang.org` was forbidden.\n\nReproduce from the root of a checkout of `pellared/opentelemetry-go` at commit `e72a235` with Go module dependencies already available:\n\n```sh\n/bin/sh -c 'ulimit -n 256; GOGC=off go run leak_poc.go'\n```\n\nConfiguration:\n\n- File descriptor soft limit: `256`\n- Garbage collection: disabled with `GOGC=off` so leaked descriptors are not reclaimed during the loop\n- Schema file: `schema/v1.0/testdata/valid-example.yaml`\n\nExpected output is increasing descriptor counts followed by an `EMFILE` failure, for example:\n\n```text\niter 0 fds 7\niter 50 fds 57\niter 100 fds 107\n...\npanic: iteration 248: open schema/v1.0/testdata/valid-example.yaml: too many open files\n```\n\nThe exact initial descriptor count and failing iteration can vary by OS and process state.\n\n### Impact\n\nThis 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.",
0 commit comments