LibSSH: Fix off-by-one in read_packet's payload length check

[Chandan3456]

read_packet computes the payload as packet_length - padding_length - 1 but only rejects packet_length == padding_length, so the guard is one byte short. length 5 with padding 4 slips through and returns a zero-length payload, which breaks the size >= 1 invariant unpack_generic_message asserts on and that handle_new_keys_message relies on when it indexes payload[0]. padding_length can also just exceed packet_length: 4 with padding 255 wraps the subtraction and asks create_uninitialized for 4294967044 bytes off a nine byte packet, which asan flags as an allocation-size-too-big at Peer.cpp:60. both land before authentication since the transport is still on the identity cipher until NEWKEYS. found it reading the framing code against rfc 4253 section 6.

[LucasChollet]

Thanks for catching this and the tests!

Very small nit: do you mind moving that check just before we compute payload_length?

I think it's just a bit clearer this way (I also dropped the comment as this is literally the same thing as the code).

    // "There MUST be at least four bytes of padding."
    if (padding_length < 4)
        return Error::from_string_literal("Padding length is too short");

    if (packet_length <= padding_length + 1u)
        return Error::from_string_literal("Packet doesn't have a payload");
    auto payload_length = packet_length - padding_length - 1;