diff options
| author | Alan Cox <alan@linux.intel.com> | 2016-09-19 21:15:24 +0200 |
|---|---|---|
| committer | David S. Miller <davem@davemloft.net> | 2016-09-21 04:51:30 +0200 |
| commit | ad9798967dd67f080bf0e8d611b382a5d292aae2 (patch) | |
| tree | 5aabd6be61938c124e1d67292e6188584a6f304a /drivers/net/hamradio/6pack.c | |
| parent | mlx4: add missed recycle opportunity for XDP_TX on TX failure (diff) | |
| download | linux-ad9798967dd67f080bf0e8d611b382a5d292aae2.tar.xz linux-ad9798967dd67f080bf0e8d611b382a5d292aae2.zip | |
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>
Diffstat (limited to 'drivers/net/hamradio/6pack.c')
| -rw-r--r-- | drivers/net/hamradio/6pack.c | 12 |
1 files changed, 4 insertions, 8 deletions
diff --git a/drivers/net/hamradio/6pack.c b/drivers/net/hamradio/6pack.c index 5a1e98547031..470b3dcd54e5 100644 --- a/drivers/net/hamradio/6pack.c +++ b/drivers/net/hamradio/6pack.c @@ -127,7 +127,7 @@ struct sixpack { #define AX25_6PACK_HEADER_LEN 0 -static void sixpack_decode(struct sixpack *, unsigned char[], int); +static void sixpack_decode(struct sixpack *, const unsigned char[], int); static int encode_sixpack(unsigned char *, unsigned char *, int, unsigned char); /* @@ -428,7 +428,7 @@ out: /* * Handle the 'receiver data ready' interrupt. - * This function is called by the 'tty_io' module in the kernel when + * This function is called by the tty module in the kernel when * a block of 6pack data has been received, which can now be decapsulated * and sent on to some IP layer for further processing. */ @@ -436,7 +436,6 @@ static void sixpack_receive_buf(struct tty_struct *tty, const unsigned char *cp, char *fp, int count) { struct sixpack *sp; - unsigned char buf[512]; int count1; if (!count) @@ -446,10 +445,7 @@ static void sixpack_receive_buf(struct tty_struct *tty, if (!sp) return; - memcpy(buf, cp, count < sizeof(buf) ? count : sizeof(buf)); - /* Read the characters out of the buffer */ - count1 = count; while (count) { count--; @@ -459,7 +455,7 @@ static void sixpack_receive_buf(struct tty_struct *tty, continue; } } - sixpack_decode(sp, buf, count1); + sixpack_decode(sp, cp, count1); sp_put(sp); tty_unthrottle(tty); @@ -992,7 +988,7 @@ static void decode_std_command(struct sixpack *sp, unsigned char cmd) /* decode a 6pack packet */ static void -sixpack_decode(struct sixpack *sp, unsigned char *pre_rbuff, int count) +sixpack_decode(struct sixpack *sp, const unsigned char *pre_rbuff, int count) { unsigned char inbyte; int count1; |