vbpf / prevail / 34454208277

87%

push

github

Fix narrowing_error on 64-bit SUB with an INT_MIN immediate (#1229)

`r0 -= -0x80000000` aborted the analysis with `error: narrowing_error`:

    0:  b7 00 00 00 00 00 00 00 r0 = 0x0
    1:  17 00 00 00 00 00 00 80 r0 -= -0x80000000
    2:  95 00 00 00 00 00 00 00 exit

`EbpfTransformer::add` took the immediate as an `int`, and the SUB case reached
it through `add(bin.dst, gsl::narrow<int>(-imm), ...)`. `imm` is an `int64_t`
holding a sign-extended 32-bit immediate, so for `imm == INT32_MIN` the negation
is 2147483648, one past `INT_MAX`, and `gsl::narrow` threw. The value is
otherwise ordinary: nothing downstream of `add` needs a 32-bit parameter, since
every use converts to `Number`.

Widen the parameter to `int64_t` and negate there. `|imm| <= 2^31` for both the
64-bit path (sign-extended imm32) and the 32-bit path (`narrow_cast<int32_t>`),
so the negation cannot overflow.

Verified against the reporter's object file, which now passes and leaves
r0.svalue = 2147483648. The two new subtract.yaml cases fail with
`Exception: narrowing_error` when the source fix is reverted; the add.yaml case
pins the ADD side of the same boundary, which was already correct.

Reported-by: fuzzing, https://github.com/vbpf/prevail/issues/1229

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Nb7vGAy22VEik5PotYN92p
Signed-off-by: Elazar Gershuni <elazarg@gmail.com>

3 of 3 new or added lines in 1 file covered. (100.0%)

9026 of 10497 relevant lines covered (85.99%)

3151042.29 hits per line