Check the screen frame size before copying it

[munzzyy]

expansion_process_screen_streaming() reads ScreenFrame.data->bytes and passes it to frame_parse_data(), which memcpy's a fixed 1024 bytes (sizeof(frame_t)) out of it. Nothing checks the pointer or the length first.

ScreenFrame.data is a pointer field — flipperzero-protobuf's gui.options has PB_Gui.ScreenFrame.data type:FT_POINTER. On that path nanopb allocates exactly as many bytes as arrived on the wire, and leaves the pointer NULL when the field isn't present at all. The max_size:1024 line next to it only constrains statically allocated fields, pb_dec_bytes() never applies it to pointer fields. So a frame that omits the data field, or carries a short one, gets us either a NULL dereference or a read off the end of the allocation.

I checked this against real generated code rather than reasoning about it. I ran the repo's own gui.proto and gui.options through the nanopb generator, decoded hand-built wire bytes with the real pb_decode.c, and repeated the same access pattern under ASan.

Field omitted:

runtime error: member access within null pointer of type 'struct pb_bytes_array_t'
AddressSanitizer: SEGV on unknown address 0x000000000002

Field present but only 4 bytes long:

AddressSanitizer: heap-buffer-overflow
READ of size 1024 at 0x7b59ba5e0012
0x7b59ba5e0016 is located 0 bytes after 6-byte region
allocated by: pb_dec_bytes nanopb/pb_decode.c:1556

The other two callers of frame_parse_data() both hand it a fixed 1024-byte buffer, so the streaming path is the only one that needs the check. Breaking out of the loop on a bad frame matches how the rest of the function already handles a frame it can't use.