Fixed out-of-bounds read in module protocol when a '%' line has no '='

[aizu-m]

AddressSanitizer, parsing a "%" module-protocol line with no "=":

ERROR: AddressSanitizer: SEGV on a READ
    #0 strlen
    #1 BufferNewFrom buffer.c:68
    #2 ModuleProtocol evalfunction.c:10252

Came across this whilst reading the module protocol parser. The "%" case
builds the JSON payload with

BufferNewFrom(line + strlen(name) + 1 + 1,
              length - strlen(name) - 1 - 1);

which assumes a well-formed "%name=" line. But sscanf("%256[^=]=",
name) also returns with name set when the line carries no "=": it leaves
the whole tail in name. So strlen(name) == length - 1, the length argument
underflows to SIZE_MAX, and the data pointer steps one past the terminating
NUL. BufferAppend() then scans from there and walks off the heap line
buffer.

read_module_protocol() hands arbitrary file lines straight to
ModuleProtocol(), so a single line "%x" is enough to reproduce it.

The other directives ("=", "@", ...) already guard their input; the "%"
case did not. Only do the arithmetic once the "=" delimiter is present.

[cf-bottom]

Thanks for submitting a PR! Maybe @larsewi can review this?

[larsewi]

Your test passes without this change

[aizu-m]

Good catch, you are right. The OOB read only trips under ASan. In a plain build the scan past the line just reads adjacent heap, JsonParse() rejects the garbage, and the variable ends up undefined either way, so the behavioural check could not tell the patched and unpatched paths apart.

Reworked the test to be deterministic instead of leaning on ASan. The "%bad" line now sits with its terminating NUL on the last readable byte before a PROT_NONE guard page, so the underflowed scan walks straight into it. Confirmed both ways locally:

without the fix: Bus error -> test_module_protocol_percent_no_delimiter: Test failed -> 1 out of 4 tests failed
with the fix:    All 4 tests passed

Pushed in 5f94cc1.