6pack: fix buffer length mishandling
authorAlan Cox <alan@linux.intel.com>
Mon, 19 Sep 2016 19:15:24 +0000 (20:15 +0100)
committerDavid S. Miller <davem@davemloft.net>
Wed, 21 Sep 2016 02:51:30 +0000 (22:51 -0400)
commitad9798967dd67f080bf0e8d611b382a5d292aae2
tree5aabd6be61938c124e1d67292e6188584a6f304a
parent5737f6c92681939e417579b421f81f035e57c582
6pack: fix buffer length mishandling

Dmitry Vyukov wrote:
> different runs). Looking at code, the following looks suspicious -- we
> limit copy by 512 bytes, but use the original count which can be
> larger than 512:
>
> static void sixpack_receive_buf(struct tty_struct *tty,
>     const unsigned char *cp, char *fp, int count)
> {
>     unsigned char buf[512];
>     ....
>     memcpy(buf, cp, count < sizeof(buf) ? count : sizeof(buf));
>     ....
>     sixpack_decode(sp, buf, count1);

With the sane tty locking we now have I believe the following is safe as
we consume the bytes and move them into the decoded buffer before
returning.

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
drivers/net/hamradio/6pack.c