From a7a31424ba823f404e4b1702070e4769201acf71 Mon Sep 17 00:00:00 2001 From: Charles Eckman Date: Wed, 4 Jun 2025 17:59:32 -0400 Subject: [PATCH 1/2] Reject core cache body ranges where the end precedes the start These are rejected in Go as of https://github.com/fastly/compute-sdk-go/pull/165, and in Rust as of PR 5097 in that repository. This is a guest (SDK/runtime) change rather than a host change so as not to break users that may accidentallly rely on this "feature"; hopefully their next SDK upgrade will highlight the issue. --- runtime/fastly/builtins/cache-core.cpp | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/runtime/fastly/builtins/cache-core.cpp b/runtime/fastly/builtins/cache-core.cpp index 7a0bb32ba3..f7d41c73e8 100644 --- a/runtime/fastly/builtins/cache-core.cpp +++ b/runtime/fastly/builtins/cache-core.cpp @@ -612,6 +612,14 @@ bool CacheEntry::body(JSContext *cx, unsigned argc, JS::Value *vp) { } options.end = JS::ToUint64(end); } + + // Reject cases where the start is greater than the end. + // Ideally this would be a host-side check... but we didn't do it there to begin with, + // so we couple it to an SDK/runtime upgrade. + if(!start_val.isUndefined() && !end_val.isUndefined() && options.end > options.start) { + JS_ReportErrorASCII(cx, "end field is before the start field"); + return false; + } } auto res = handle.get_body(options); From ab2c1b32e011cea750e3a2abbe95c885fb9ceed7 Mon Sep 17 00:00:00 2001 From: Charles Eckman Date: Wed, 4 Jun 2025 18:05:59 -0400 Subject: [PATCH 2/2] clang-format --- runtime/fastly/builtins/cache-core.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/runtime/fastly/builtins/cache-core.cpp b/runtime/fastly/builtins/cache-core.cpp index f7d41c73e8..e42dd6e40d 100644 --- a/runtime/fastly/builtins/cache-core.cpp +++ b/runtime/fastly/builtins/cache-core.cpp @@ -616,7 +616,7 @@ bool CacheEntry::body(JSContext *cx, unsigned argc, JS::Value *vp) { // Reject cases where the start is greater than the end. // Ideally this would be a host-side check... but we didn't do it there to begin with, // so we couple it to an SDK/runtime upgrade. - if(!start_val.isUndefined() && !end_val.isUndefined() && options.end > options.start) { + if (!start_val.isUndefined() && !end_val.isUndefined() && options.end > options.start) { JS_ReportErrorASCII(cx, "end field is before the start field"); return false; }