[PATCH] Staging: bcm: avoid use-after-free in bcm_char_ioctl()

2013-03-06 Thread Xi Wang
Free pBulkBuffer (pvBuffer) after pBulkBuffer->Register. Signed-off-by: Xi Wang --- drivers/staging/bcm/Bcmchar.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/bcm/Bcmchar.c b/drivers/staging/bcm/Bcmchar.c index 491e2bf..35641e5 100644 --- a/driv

Re: [PATCH] staging: vt6656: Don't leak memory in drivers/staging/vt6656/ioctl.c::private_ioctl()

2012-04-11 Thread Xi Wang
On Apr 11, 2012, at 6:35 PM, Jesper Juhl wrote: > - pNodeList = (PSNodeList)kmalloc(sizeof(SNodeList) + > (sNodeList.uItem * sizeof(SNodeItem)), (int)GFP_ATOMIC); > + pNodeList = kmalloc(sizeof(SNodeList) + (sNodeList.uItem * > sizeof(SNodeItem)), (int)GFP_ATOMIC); Can y

[PATCH v3] staging: olpc_dcon: ->read_status() API change

2011-12-02 Thread Xi Wang
Change ->read_status() by separating the error handling and the status bits. This also fixes a signedness bug in dcon_interrupt() that would break the error handling. Signed-off-by: Xi Wang Cc: Andres Salomon Cc: Dan Carpenter --- drivers/staging/olpc_dcon/olpc_dcon.c|

Re: [PATCH v2] staging: olpc_dcon: ->read_status() API change

2011-12-02 Thread Xi Wang
On Dec 2, 2011, at 3:40 PM, Dan Carpenter wrote: > It would be better to do a check for < 0 instead of -1 or even just > a check for non-zero. > > if (pdata->read_status(&status)) > return IRQ_NONE; > > That's more linux-ish. Sounds good to me. Will do a v3. Thanks. - xi _

[PATCH v2] staging: olpc_dcon: ->read_status() API change

2011-12-02 Thread Xi Wang
Change ->read_status() by separating the error handling and the status bits. This also fixes a signedness bug in dcon_interrupt(). Signed-off-by: Xi Wang Cc: Andres Salomon --- drivers/staging/olpc_dcon/olpc_dcon.c|4 ++-- drivers/staging/olpc_dcon/olpc_dcon.h|

Re: [PATCH] staging: olpc_dcon: signedness bug in dcon_interrupt()

2011-12-02 Thread Xi Wang
On Dec 1, 2011, at 7:04 PM, Andres Salomon wrote: > Thanks for catching that. I'd prefer to see this cleaned up, though. > Error handling and the status bits (of which we only use two) should be > separate. > > ie, "int (*read_status)(u8 *status);" > > Alternatively, we could have the high bit o

[PATCH] staging: olpc_dcon: signedness bug in dcon_interrupt()

2011-12-01 Thread Xi Wang
The error handling with (status == -1) didn't work because "status" is a zero extension of a u8 from read_status(). Signed-off-by: Xi Wang --- drivers/staging/olpc_dcon/olpc_dcon.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/staging/olpc_dcon

Re: [PATCH 2/2 v2] staging: vt6656: integer overflows in private_ioctl()

2011-11-30 Thread Xi Wang
On Nov 30, 2011, at 10:15 AM, Dan Carpenter wrote: > It doesn't actually matter because sizeof(SBSSIDList) is just 4 but > normally you would do the math different. > > if (sList.uItem > ULONG_MAX / sizeof(SBSSIDItem) - > sizeof(SBSSIDList)) { > > But both checks are low enough in

[PATCH 2/2 v2] staging: vt6656: integer overflows in private_ioctl()

2011-11-30 Thread Xi Wang
There are two potential integer overflows in private_ioctl() if userspace passes in a large sList.uItem / sNodeList.uItem. The subsequent call to kmalloc() would allocate a small buffer, leading to a memory corruption. Reported-by: Dan Rosenberg Signed-off-by: Xi Wang --- drivers/staging

Re: [PATCH 2/2] staging: vt6656: integer overflows in private_ioctl()

2011-11-30 Thread Xi Wang
On Nov 30, 2011, at 8:31 AM, Forest Bond wrote: > > Did you mean to use EINVAL here? That's what you used for vt6655. You are right. I will update the patch. Thanks. - xi ___ devel mailing list devel@linuxdriverproject.org http://driverdev.

[PATCH 2/2] staging: vt6656: integer overflows in private_ioctl()

2011-11-29 Thread Xi Wang
There are two potential integer overflows in private_ioctl() if userspace passes in a large sList.uItem / sNodeList.uItem. The subsequent call to kmalloc() would allocate a small buffer, leading to a memory corruption. Reported-by: Dan Rosenberg Signed-off-by: Xi Wang --- drivers/staging

[PATCH 1/2] staging: vt6655: integer overflows in private_ioctl()

2011-11-29 Thread Xi Wang
There are two potential integer overflows in private_ioctl() if userspace passes in a large sList.uItem / sNodeList.uItem. The subsequent call to kmalloc() would allocate a small buffer, leading to a memory corruption. Reported-by: Dan Rosenberg Signed-off-by: Xi Wang --- drivers/staging

[PATCH v3] comedi: integer overflow in do_insnlist_ioctl()

2011-11-25 Thread Xi Wang
and Lars-Peter Clausen . Signed-off-by: Xi Wang --- drivers/staging/comedi/comedi_fops.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/staging/comedi/comedi_fops.c b/drivers/staging/comedi/comedi_fops.c index 21d8c1c..7f7d79e 100644 --- a/drivers/staging/comedi

Re: [PATCH] comedi: integer overflow in do_insnlist_ioctl()

2011-11-24 Thread Xi Wang
Using kcalloc looks good to me. Do you want to redo the patch in that way? - xi On Nov 23, 2011, at 4:51 PM, Dan Carpenter wrote: > > I think the reason why I didn't do that in my original patch is that > kcalloc() has a memset(..., 0, ...) in it so it's a slow down. But > this isn't performan

[PATCH v2] comedi: integer overflow in do_insnlist_ioctl()

2011-11-23 Thread Xi Wang
There is a potential integer overflow in do_insnlist_ioctl() if userspace passes in a large insnlist.n_insns. The call to kmalloc() would allocate a small buffer, leading to a memory corruption. Reported-by: Haogang Chen Suggested-by: Dan Carpenter Suggested-by: Ian Abbott Signed-off-by: Xi

Re: [PATCH] comedi: integer overflow in do_insnlist_ioctl()

2011-11-23 Thread Xi Wang
Thanks for the pointer. However you cannot do the overflow check using if (sizeof(struct comedi_insn) * insnlist.n_insns < insnlist.n_insns) Let's assume 32-bit system, sizeof(struct comedi_insn) = 32, and insnlist.n_insns = 0x7fff. Note that 32 * 0x7fff = 0xffe0 overflows but byp

[PATCH] comedi: integer overflow in do_insnlist_ioctl()

2011-11-22 Thread Xi Wang
There is a potential integer overflow in do_insnlist_ioctl() if userspace passes in a large insnlist.n_insns. The call to kmalloc() would allocate a small buffer, which would result in a memory corruption. Reported-by: Haogang Chen Signed-off-by: Xi Wang --- drivers/staging/comedi