ota: bounds check on /api/flash only covers the first chunk, and runs after init_ota

[DrDoof]

http_rest_post_flash in the Beken HAL has a bounds check that doesn't cover what
actually gets written, and it runs too late to be safe when it does reject something.

The check is this:

init_ota(startaddr);

if (request->contentLength >= 0) {
    towrite = request->contentLength;
}

if (writelen < 0 || (startaddr + writelen > maxaddr)) {
    return http_rest_error(request, -20, "writelen < 0 or end > 0x200000");
}

writelen is request->bodylen, which is only the part of the body that arrived
along with the headers. The loop underneath writes towrite bytes, which comes from
Content-Length, pulling the rest off the socket with recv and bumping startaddr
each time round. It never checks again, and nothing below it does either:
add_otadata walks addr forward per sector and store_sector goes straight to
CMD_FLASH_ERASE_SECTOR followed by flash_write. So a POST to /api/flash/<addr>
with a large Content-Length and a small first chunk passes the check and then erases
its way past maxaddr. That endpoint takes the start address from the URL and only
requires it to be at or above the OTA partition.

The second half is the ordering. init_ota clears flash write protection and mallocs
the sector buffer before the check happens, and the error path returns without
close_ota(), which is the only place that frees the buffer and puts protection back.
init_ota also refuses to run while sector is non-null, so one rejected upload
leaves write protection off and OTA unusable until the device reboots.

I moved the check above init_ota and pointed it at towrite. Nothing else in the
function changed. I left the -20 error code alone in case anything depends on it, but
reworded the message, since it named a constant that isn't what's being compared.

Only the Beken HAL has this check at all. The other HALs take maxaddr and ignore it,
which is worth a separate look, but I didn't want to touch platforms I can't test.

Tested on BK7252N.

[DrDoof]

@openshwprojects @DeDaMrAzR @NonPIayerCharacter @divadiow flagging this one since
it's had no eyes yet and it's the one I'd least like to get wrong.

Short version: the bounds check in http_rest_post_flash tests the first chunk of
the body rather than the full Content-Length, and it runs after init_ota has
already dropped flash write protection. So an oversized upload walks past
maxaddr, and a rejected one leaves protection off with the sector buffer still
allocated, which blocks OTA until reboot.

Only the Beken HAL has the check at all, the others take maxaddr and ignore it,
so I've kept the patch to the one file. Tabs throughout.

[divadiow]

**HARDEN RANGE CHECK, THEN MERGE** | Code reviewed | The total-length and validation-order fix is correct. Replace signed startaddr + towrite arithmetic with an overflow-safe subtraction or wide-integer check, and reject zero or negative lengths before init_ota.

[DrDoof]

Good catch on the overflow, you're right that the signed sum can wrap and then sail straight past the check it was supposed to trip.

Reworked it as a subtraction. The operands get guarded first, so maxaddr - startaddr can't go negative before the comparison happens, and the zero length now falls into the same condition, so an empty POST no longer gets as far as init_ota erasing anything.

Went with the subtraction rather than a 64-bit compare mostly to keep the arithmetic 32-bit on these parts, but either would do the job.