clamp packet length in zyfer_receive to bound a_lastcode

[arib06]

clamp recv_length in zyfer_receive before appending to a_lastcode, otherwise a short leading '!' line that seeds a small lencode followed by a packet longer than the buffer's remaining space overruns the 128-byte a_lastcode (recv_length reaches up to RX_BUFF_SIZE), matching the length clamp already used in jupiter_receive.

[hart-NTP]

Thanks for the report, @arib06. Please consider filing a report at https://bugs.ntp.org./ This repo is currently out of date on GitHub, but I checked and this shortcoming persists in the latest code.

[arib06]

Will do, I'll file this at bugs.ntp.org with the details.

For the record, I confirmed it with a standalone ASAN harness that mirrors the else-branch append: seed lencode=1 with a short '!' line, then feed a 220-byte packet. Unpatched that gives a heap-buffer-overflow WRITE of size 220 at the memcpy past the 128-byte a_lastcode; with the clamp it stops at lencode=127 and runs clean. Valid Zyfer input is a 29-byte timecode so it never reaches the clamp.

Happy to leave this PR open or close it once the bug report is in, whichever you prefer.

[arib06]

any update?

[ntpreleng]

I'm working on merging in bug fixes. I do not see this report at bugs.ntp.org, however.

If it's not too much trouble, please create a report for this issue at bugs.ntp.org and I should be able to get this handled for p19.