similar to: potential integer overflow in xenbus_file_write()

On 12/18/2011 11:55 PM, Stephen Rothwell wrote: > Hi all, > > Changes since 20111216: drivers/xen/xenbus/xenbus_dev_frontend.c: In function 'xenbus_init': drivers/xen/xenbus/xenbus_dev_frontend.c:609:2: error: implicit declaration of function 'xen_domain' Full randconfig file is attached. -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your

On 12/18/2011 11:55 PM, Stephen Rothwell wrote: > Hi all, > > Changes since 20111216: drivers/xen/xenbus/xenbus_dev_frontend.c: In function 'xenbus_init': drivers/xen/xenbus/xenbus_dev_frontend.c:609:2: error: implicit declaration of function 'xen_domain' Full randconfig file is attached. -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your

Dear xen-devel, There''s a race condition in xenfs (xenstore driver) that causes userspace utility xenstore-watch to crash. Normally, the userspace process gets an "OK" from xenfs and then the watch fires immediately after. Occasionally, this happens the other way around: the watch fires before the driver sends "OK", which confuses the xenstore-watch client. It seems

If m.num is too large then the "m.num * sizeof(*m.arr)" multiplication could overflow and the access_ok() check wouldn't test the right size. Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com> --- Only needed in linux-next. diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c index 215a3c0..fdff8f9 100644 --- a/drivers/xen/privcmd.c +++ b/drivers/xen/privcmd.c

If m.num is too large then the "m.num * sizeof(*m.arr)" multiplication could overflow and the access_ok() check wouldn't test the right size. Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com> --- Only needed in linux-next. diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c index 215a3c0..fdff8f9 100644 --- a/drivers/xen/privcmd.c +++ b/drivers/xen/privcmd.c

I did an audit for potential integer overflows of values which get passed to access_ok() and here are the results. Signed-off-by: Dan Carpenter <error27 at gmail.com> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c index dd3d6f7..c2aa12c 100644 --- a/drivers/vhost/vhost.c +++ b/drivers/vhost/vhost.c @@ -429,6 +429,14 @@ static int vq_access_ok(unsigned int num, struct

I did an audit for potential integer overflows of values which get passed to access_ok() and here are the results. Signed-off-by: Dan Carpenter <error27 at gmail.com> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c index dd3d6f7..c2aa12c 100644 --- a/drivers/vhost/vhost.c +++ b/drivers/vhost/vhost.c @@ -429,6 +429,14 @@ static int vq_access_ok(unsigned int num, struct

On 32 bit systems a high value of op.count could lead to an integer overflow in the kzalloc() and gref_ids would be smaller than expected. If the you triggered another integer overflow in "if (gref_size + op.count > limit)" then you'd probably get memory corruption inside add_grefs(). Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com> diff --git

On 32 bit systems a high value of op.count could lead to an integer overflow in the kzalloc() and gref_ids would be smaller than expected. If the you triggered another integer overflow in "if (gref_size + op.count > limit)" then you'd probably get memory corruption inside add_grefs(). Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com> diff --git

On 32 bit systems a high value of op.count could lead to an integer overflow in the kzalloc() and gref_ids would be smaller than expected. If the you triggered another integer overflow in "if (gref_size + op.count > limit)" then you'd probably get memory corruption inside add_grefs(). Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com> diff --git

So far only the watch path was checked to be zero terminated, while the watch token was merely assumed to be. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- drivers/xen/xenbus/xenbus_dev_frontend.c | 4 ++++ 1 file changed, 4 insertions(+) --- 3.3-rc1/drivers/xen/xenbus/xenbus_dev_frontend.c +++ 3.3-rc1-xenbus-dev-write-watch/drivers/xen/xenbus/xenbus_dev_frontend.c @@ -369,6

Hi Ville, Thank you for the patch! Perhaps something to improve: url: https://github.com/0day-ci/linux/commits/Ville-Syrjala/drm-Third-attempt-at-fixing-the-fb-helper-best_encoder-mess/20180629-014202 base: git://people.freedesktop.org/~airlied/linux.git drm-next smatch warnings: drivers/gpu/drm/nouveau/nouveau_connector.c:461 nouveau_connector_ddc_detect() error: uninitialized symbol

Reported-by: Dan Carpenter <dan.carpenter at oracle.com> Signed-off-by: Martin Peres <martin.peres at free.fr> --- nvkm/subdev/bios/base.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/nvkm/subdev/bios/base.c b/nvkm/subdev/bios/base.c index 3de7d81..5f8643d 100644 --- a/nvkm/subdev/bios/base.c +++ b/nvkm/subdev/bios/base.c @@ -183,10 +183,11 @@

The "vma->vm_pgoff" variable is an unsigned long so if it's larger than INT_MAX then "index" can be negative leading to an underflow. Fix this by changing the type of "index" to "unsigned long". Fixes: ddd89d0a059d ("vhost_vdpa: support doorbell mapping via mmap") Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com> ---

Hi Jeremy, My static analyzer complains about potential memory corruption in HYPERVISOR_physdev_op() arch/x86/include/asm/xen/hypercall.h 389 static inline int 390 HYPERVISOR_physdev_op(int cmd, void *arg) 391 { 392 int rc = _hypercall2(int, physdev_op, cmd, arg); 393 if (unlikely(rc == -ENOSYS)) { 394 struct physdev_op op; 395

Hi Jeremy, My static analyzer complains about potential memory corruption in HYPERVISOR_physdev_op() arch/x86/include/asm/xen/hypercall.h 389 static inline int 390 HYPERVISOR_physdev_op(int cmd, void *arg) 391 { 392 int rc = _hypercall2(int, physdev_op, cmd, arg); 393 if (unlikely(rc == -ENOSYS)) { 394 struct physdev_op op; 395

Hi Jeremy, My static analyzer complains about potential memory corruption in HYPERVISOR_physdev_op() arch/x86/include/asm/xen/hypercall.h 389 static inline int 390 HYPERVISOR_physdev_op(int cmd, void *arg) 391 { 392 int rc = _hypercall2(int, physdev_op, cmd, arg); 393 if (unlikely(rc == -ENOSYS)) { 394 struct physdev_op op; 395

This code in vhost_scsi_make_tpg() is confusing because we limit "tpgt" to UINT_MAX but the data type of "tpg->tport_tpgt" and that is a u16. I looked at the context and it turns out that in vhost_scsi_set_endpoint(), "tpg->tport_tpgt" is used as an offset into the vs_tpg[] array which has VHOST_SCSI_MAX_TARGET (256) elements so anything higher than 255 then it

This code in vhost_scsi_make_tpg() is confusing because we limit "tpgt" to UINT_MAX but the data type of "tpg->tport_tpgt" and that is a u16. I looked at the context and it turns out that in vhost_scsi_set_endpoint(), "tpg->tport_tpgt" is used as an offset into the vs_tpg[] array which has VHOST_SCSI_MAX_TARGET (256) elements so anything higher than 255 then it

On Tue, May 27, 2014 at 7:15 PM, Martin Peres <martin.peres at free.fr> wrote: > Le 03/04/2014 22:12, Martin Peres a ?crit : > >> Reported-by: Dan Carpenter <dan.carpenter at oracle.com> >> Signed-off-by: Martin Peres <martin.peres at free.fr> >> --- >> nvkm/subdev/bios/base.c | 9 +++++---- >> 1 file changed, 5 insertions(+), 4 deletions(-)