Re: [PATCH] net: hamradio: 6pack: fix uninit-value in sixpack_receive_buf

On Wed, Apr 08, 2026, Simon Horman wrote:
> Sorry for not noticing this earlier, but AI generated review flags
> that while this change looks correct, it's not clear how it relates
> to the sysbot report: IOW, how is it that bytes with TTY error flags
> may be uninitialized?

Thanks for the question, and for the earlier review.

The TTY receive_buf() contract is that for positions where fp[i] != 0
(error flag set), the caller must discard cp[i] -- the TTY driver does
not guarantee a meaningful value there.  In syzbot's fuzzing harness
(pty/ldisc injection), the fuzzer allocates a tty_buffer, sets error
flags on certain byte positions, but leaves the corresponding entries in
the char buffer uninitialized.  KMSAN then detects that sixpack_decode()
reads those uninitialized bytes.

slip_receive_buf() and mkiss_receive_buf() already handle this correctly
by advancing their char pointer past error-flagged bytes before calling
their decode functions.  sixpack_receive_buf() had the same structure
but cp was never advanced, so the full original buffer -- including the
uninit error-flagged positions -- was forwarded to sixpack_decode().

I have also dropped the Suggested-by tag per your note, and submitted
a v2 with the commit message expanded to explain the uninit-value
connection more clearly.

Thanks,
Mashiro Chen