aboutsummaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorGravatar Alan Cox <alan@linux.intel.com> 2016-09-19 20:15:24 +0100
committerGravatar David S. Miller <davem@davemloft.net> 2016-09-20 22:51:30 -0400
commitad9798967dd67f080bf0e8d611b382a5d292aae2 (patch)
tree5aabd6be61938c124e1d67292e6188584a6f304a /include
parentmlx4: add missed recycle opportunity for XDP_TX on TX failure (diff)
downloadlinux-ad9798967dd67f080bf0e8d611b382a5d292aae2.tar.gz
linux-ad9798967dd67f080bf0e8d611b382a5d292aae2.tar.bz2
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 'include')
0 files changed, 0 insertions, 0 deletions