CVE-2026-88015

### Summary When `backend/local` is used with `--links`/`-l` (or the `links=true` config option), each symlink is exposed as an rclone object whose content is the target path string, suffixed `.rclonelink`. `Object.Open()` decodes an incoming `fs.RangeOption` via `Decode(o.Size())`, then for a translated-symlink object passes the decoded `offset` straight into `openTranslatedLink`, which indexes the target string directly: `linkdst[offset:]`. `RangeOption.Decode`'s `Start >= 0` branch (an ordinary `Range: bytes=X-` request) sets `offset = o.Start` with no upper bound, unlike its suffix-range branch (`Start < 0`, e.g. `bytes=-N`), which already clamps a too-large value to 0 - the fix for a prior, related crash (issue #6310: "bytes=-90407" against a 5-byte object panicked with "slice bounds out of range", now covered by an existing regression test). The `Start >= 0` branch never received the analogous protection. A `Range: bytes=<hugeStart>-` request sent to `rclone serve http`/`webdav` (or any consumer of `lib/http/serve`'s `Object()`, which parses and decodes the client's own Range header) against a directory containing a symlink therefore reaches `linkdst[offset:]` with offset far beyond the target string's length, and Go panics with "slice bounds out of range" instead of returning an empty read. ### Details Vulnerable code (before fix): ```go func (o *Object) openTranslatedLink(offset, limit int64) (lrc io.ReadCloser, err error) { linkdst, err := os.Readlink(o.path) if err != nil { return nil, err } return readers.NewLimitedReadCloser(io.NopCloser(strings.NewReader(linkdst[offset:])), limit), nil } ``` ### PoC Called the real production `Object.Open()` on a translated-symlink object (target length 12) with `&fs.RangeOption{Start: math.MaxInt64, End: -1}`: ``` panic: runtime error: slice bounds out of range [9223372036854775807:8] ...backend/local.(*Object).openTranslatedLink ...backend/local.(*Object).Open ``` ### Impact A remote client can send a sing