* [patch 2/2] staging: ath6kl: buffer overflow in SEND_FRAME ioctl
@ 2011-02-20 12:49 Dan Carpenter
2011-02-20 15:18 ` [patch 2/2] staging: ath6kl: buffer overflow in SEND_FRAME Vipin Mehta
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: Dan Carpenter @ 2011-02-20 12:49 UTC (permalink / raw)
To: kernel-janitors
We should check that optTxFrmCmd.optIEDataLen isn't too large before we
copy it into the data buffer.
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/drivers/staging/ath6kl/os/linux/ioctl.c b/drivers/staging/ath6kl/os/linux/ioctl.c
index 17ba543..9a9a324 100644
--- a/drivers/staging/ath6kl/os/linux/ioctl.c
+++ b/drivers/staging/ath6kl/os/linux/ioctl.c
@@ -3153,6 +3153,11 @@ int ar6000_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
break;
}
+ if (optTxFrmCmd.optIEDataLen > MAX_OPT_DATA_LEN) {
+ ret = -EINVAL;
+ break;
+ }
+
if (copy_from_user(data, userdata+sizeof(WMI_OPT_TX_FRAME_CMD) - 1,
optTxFrmCmd.optIEDataLen)) {
ret = -EFAULT;
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [patch 2/2] staging: ath6kl: buffer overflow in SEND_FRAME
2011-02-20 12:49 [patch 2/2] staging: ath6kl: buffer overflow in SEND_FRAME ioctl Dan Carpenter
@ 2011-02-20 15:18 ` Vipin Mehta
2011-02-23 18:40 ` [patch 2/2] staging: ath6kl: buffer overflow in SEND_FRAME ioctl Luis R. Rodriguez
2011-02-23 18:54 ` Greg KH
2 siblings, 0 replies; 4+ messages in thread
From: Vipin Mehta @ 2011-02-20 15:18 UTC (permalink / raw)
To: kernel-janitors
On Sun, Feb 20, 2011 at 04:49:53AM -0800, Dan Carpenter wrote:
> We should check that optTxFrmCmd.optIEDataLen isn't too large before we
> copy it into the data buffer.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
>
> diff --git a/drivers/staging/ath6kl/os/linux/ioctl.c b/drivers/staging/ath6kl/os/linux/ioctl.c
> index 17ba543..9a9a324 100644
> --- a/drivers/staging/ath6kl/os/linux/ioctl.c
> +++ b/drivers/staging/ath6kl/os/linux/ioctl.c
> @@ -3153,6 +3153,11 @@ int ar6000_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
> break;
> }
>
> + if (optTxFrmCmd.optIEDataLen > MAX_OPT_DATA_LEN) {
> + ret = -EINVAL;
> + break;
> + }
> +
> if (copy_from_user(data, userdata+sizeof(WMI_OPT_TX_FRAME_CMD) - 1,
> optTxFrmCmd.optIEDataLen)) {
> ret = -EFAULT;
Acked-by: Vipin Mehta <vipin.mehta@atheros.com>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [patch 2/2] staging: ath6kl: buffer overflow in SEND_FRAME ioctl
2011-02-20 12:49 [patch 2/2] staging: ath6kl: buffer overflow in SEND_FRAME ioctl Dan Carpenter
2011-02-20 15:18 ` [patch 2/2] staging: ath6kl: buffer overflow in SEND_FRAME Vipin Mehta
@ 2011-02-23 18:40 ` Luis R. Rodriguez
2011-02-23 18:54 ` Greg KH
2 siblings, 0 replies; 4+ messages in thread
From: Luis R. Rodriguez @ 2011-02-23 18:40 UTC (permalink / raw)
To: kernel-janitors
On Sun, Feb 20, 2011 at 7:18 AM, Vipin Mehta <vmehta@atheros.com> wrote:
> Acked-by: Vipin Mehta <vipin.mehta@atheros.com>
Greg, Joe is not sure if these patches will be applied as-is and his
cleanup depends on code being static, I think they would be there is a
chance you might muck them a bit and this would break any cleanup
work. Will these patches be merged as-is, can Joe for example git am
these into his tree as-is and work off of the assumption that they
will reflect the top of staging-next + these patches?
Luis
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [patch 2/2] staging: ath6kl: buffer overflow in SEND_FRAME ioctl
2011-02-20 12:49 [patch 2/2] staging: ath6kl: buffer overflow in SEND_FRAME ioctl Dan Carpenter
2011-02-20 15:18 ` [patch 2/2] staging: ath6kl: buffer overflow in SEND_FRAME Vipin Mehta
2011-02-23 18:40 ` [patch 2/2] staging: ath6kl: buffer overflow in SEND_FRAME ioctl Luis R. Rodriguez
@ 2011-02-23 18:54 ` Greg KH
2 siblings, 0 replies; 4+ messages in thread
From: Greg KH @ 2011-02-23 18:54 UTC (permalink / raw)
To: kernel-janitors
On Wed, Feb 23, 2011 at 10:40:50AM -0800, Luis R. Rodriguez wrote:
> On Sun, Feb 20, 2011 at 7:18 AM, Vipin Mehta <vmehta@atheros.com> wrote:
>
> > Acked-by: Vipin Mehta <vipin.mehta@atheros.com>
>
> Greg, Joe is not sure if these patches will be applied as-is and his
> cleanup depends on code being static, I think they would be there is a
> chance you might muck them a bit and this would break any cleanup
> work. Will these patches be merged as-is, can Joe for example git am
> these into his tree as-is and work off of the assumption that they
> will reflect the top of staging-next + these patches?
I already answered Joe about this yesterday, was that response somehow
not sufficient?
thanks,
greg "tired of repeating myself" k-h
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-02-23 18:54 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-02-20 12:49 [patch 2/2] staging: ath6kl: buffer overflow in SEND_FRAME ioctl Dan Carpenter
2011-02-20 15:18 ` [patch 2/2] staging: ath6kl: buffer overflow in SEND_FRAME Vipin Mehta
2011-02-23 18:40 ` [patch 2/2] staging: ath6kl: buffer overflow in SEND_FRAME ioctl Luis R. Rodriguez
2011-02-23 18:54 ` Greg KH
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox