Skip to content

fix(parser): return error instead of panicking on TZ= prefix with no schedule#567

Open
SAY-5 wants to merge 1 commit intorobfig:masterfrom
SAY-5:fix/tz-prefix-without-spec-554
Open

fix(parser): return error instead of panicking on TZ= prefix with no schedule#567
SAY-5 wants to merge 1 commit intorobfig:masterfrom
SAY-5:fix/tz-prefix-without-spec-554

Conversation

@SAY-5
Copy link
Copy Markdown

@SAY-5 SAY-5 commented Apr 21, 2026

What

Fixes #554.

Parser.Parse supports an optional TZ=... / CRON_TZ=... prefix terminated by the first space character. If the prefix is provided alone (e.g. TZ=0 with no space), the space-index lookup returns -1 and spec[eq+1:-1] slices a negative upper bound, panicking at runtime with slice bounds out of range [:-1].

This is easy to hit in production scenarios where cron expressions come from user input or fuzz testing: any user that enters just a timezone prefix without a schedule crashes the host process.

Fix

Detect the missing space explicitly and return a normal parse error (missing schedule after timezone prefix: %q) so untrusted-input callers see a regular error return instead of a runtime panic.

Tests

Added three rows to TestParseScheduleErrors - TZ=0, TZ=UTC, and CRON_TZ=America/Los_Angeles - each asserting the new error message. All three trip the panic on master and pass after the fix.

Verification

Locally on macOS, go 1.26.2:

  • gofmt -s -l: clean
  • go vet ./...: clean
  • go test -race -count=1 ./...: pass

Closes #554

…schedule

Parser.Parse supports an optional 'TZ=...' or 'CRON_TZ=...' prefix
terminated by the first space character, with the schedule expression
following. If the prefix is provided alone (e.g. 'TZ=0' with no space)
the space-index lookup returned -1, and spec[eq+1:-1] sliced a negative
upper bound, panicking with 'slice bounds out of range [:-1]' on
fuzz-style input (robfig#554).

Detect the missing space explicitly and return a normal parse error
('missing schedule after timezone prefix: %q') so callers that treat
their input as untrusted (cron expressions from users, config files,
automated fuzzers) see a regular error return instead of a runtime
panic crashing the process.

Added regression coverage in TestParseScheduleErrors for three
representative inputs: 'TZ=0', 'TZ=UTC', and 'CRON_TZ=America/Los_Angeles'.

Closes robfig#554

Signed-off-by: SAY-5 <SAY-5@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

cron.ParseStandard("TZ=0") causes panic

1 participant