GHSA-995v-fvrw-c78m

### 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.