similar to: [patch 1/3] xen/privcmd: check for integer overflow in ioctl

When we use this pointer, we cast away the const modifier and modify the data. I think it was an accident to declare it as const. Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com> diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h index a853168..58ed953 100644 --- a/include/xen/privcmd.h +++ b/include/xen/privcmd.h @@ -69,7 +69,7 @@ struct privcmd_mmapbatch_v2 {

When we use this pointer, we cast away the const modifier and modify the data. I think it was an accident to declare it as const. Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com> diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h index a853168..58ed953 100644 --- a/include/xen/privcmd.h +++ b/include/xen/privcmd.h @@ -69,7 +69,7 @@ struct privcmd_mmapbatch_v2 {

put_user() may fail. In this case propagate error code from privcmd_ioctl_mmap_batch(). Signed-off-by: Vasiliy Kulikov <segooon at gmail.com> --- Compile tested. drivers/xen/xenfs/privcmd.c | 8 ++------ 1 files changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/xen/xenfs/privcmd.c b/drivers/xen/xenfs/privcmd.c index f80be7f..2eb04c8 100644 ---

put_user() may fail. In this case propagate error code from privcmd_ioctl_mmap_batch(). Signed-off-by: Vasiliy Kulikov <segooon at gmail.com> --- Compile tested. drivers/xen/xenfs/privcmd.c | 8 ++------ 1 files changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/xen/xenfs/privcmd.c b/drivers/xen/xenfs/privcmd.c index f80be7f..2eb04c8 100644 ---

Copy back of per-slot error codes is only necessary for V2. V1 does not provide an error array, so copyback will unconditionally set the global rc to EFAULT. Only copyback for V2. Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org> --- drivers/xen/privcmd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c index

This series implements ballooning for Xen on ARM and builds and Mukesh''s PVH privcmd stuff to implement foreign page mapping on ARM, replacing the old "HACK: initial (very hacky) XENMAPSPACE_gmfn_foreign" patch. The baseline is a bit complex, it is basically Stefano''s xenarm-forlinus branch (commit bbd6eb29214e) merged with Konrad''s linux-next-pvh branch

On Tue, Jul 03, 2018 at 01:38:04PM +0800, Jason Wang wrote: > This patch introduces support for event suppression. This is done by > have a two areas: device area and driver area. One side could then try > to disable or enable (delayed) notification from other side by using a > boolean hint or event index interface in the areas. > > For more information, please refer Virtio

On Tue, Jul 03, 2018 at 01:38:04PM +0800, Jason Wang wrote: > This patch introduces support for event suppression. This is done by > have a two areas: device area and driver area. One side could then try > to disable or enable (delayed) notification from other side by using a > boolean hint or event index interface in the areas. > > For more information, please refer Virtio

access_ok() returns 1 if it's OK otherwise it should return 0. Signed-off-by: Dan Carpenter <error27 at gmail.com> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c index c2aa12c..f82fe57 100644 --- a/drivers/vhost/vhost.c +++ b/drivers/vhost/vhost.c @@ -371,7 +371,7 @@ static int log_access_ok(void __user *log_base, u64 addr, unsigned long sz) /* Make sure 64 bit math will

access_ok() returns 1 if it's OK otherwise it should return 0. Signed-off-by: Dan Carpenter <error27 at gmail.com> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c index c2aa12c..f82fe57 100644 --- a/drivers/vhost/vhost.c +++ b/drivers/vhost/vhost.c @@ -371,7 +371,7 @@ static int log_access_ok(void __user *log_base, u64 addr, unsigned long sz) /* Make sure 64 bit math will

v2: * Rewrote the conditional to make the vq access check clearer [Linus] * Added Patch 2 to make the return type consistent and harder to misuse [Linus] The first patch fixes the vhost virtqueue access check which was recently broken. The second patch replaces the int return type with bool to prevent future bugs. Stefan Hajnoczi (2): vhost: fix vhost_vq_access_ok() log check vhost:

v2: * Rewrote the conditional to make the vq access check clearer [Linus] * Added Patch 2 to make the return type consistent and harder to misuse [Linus] The first patch fixes the vhost virtqueue access check which was recently broken. The second patch replaces the int return type with bool to prevent future bugs. Stefan Hajnoczi (2): vhost: fix vhost_vq_access_ok() log check vhost:

v3: * Rebased onto net/master and resolved conflict [DaveM] v2: * Rewrote the conditional to make the vq access check clearer [Linus] * Added Patch 2 to make the return type consistent and harder to misuse [Linus] The first patch fixes the vhost virtqueue access check which was recently broken. The second patch replaces the int return type with bool to prevent future bugs. Stefan Hajnoczi

v3: * Rebased onto net/master and resolved conflict [DaveM] v2: * Rewrote the conditional to make the vq access check clearer [Linus] * Added Patch 2 to make the return type consistent and harder to misuse [Linus] The first patch fixes the vhost virtqueue access check which was recently broken. The second patch replaces the int return type with bool to prevent future bugs. Stefan Hajnoczi

On Thu, Nov 1, 2018 at 4:00 PM Kees Cook <keescook at chromium.org> wrote: > > + memset(&rsp, 0, sizeof(rsp)); > + rsp.response = VIRTIO_SCSI_S_FUNCTION_REJECTED; > + resp = vq->iov[out].iov_base; > + ret = __copy_to_user(resp, &rsp, sizeof(rsp)); > > Is it actually safe to trust that iov_base has passed an earlier > access_ok()

On Thu, Nov 1, 2018 at 4:00 PM Kees Cook <keescook at chromium.org> wrote: > > + memset(&rsp, 0, sizeof(rsp)); > + rsp.response = VIRTIO_SCSI_S_FUNCTION_REJECTED; > + resp = vq->iov[out].iov_base; > + ret = __copy_to_user(resp, &rsp, sizeof(rsp)); > > Is it actually safe to trust that iov_base has passed an earlier > access_ok()

This is with last night''s Xen snapshot (apr 24th), on kernel 2.6.12-rc3 - but the mess is so horrid that I''m not quite sure how to fix it... This oops prevents xen from starting xenU domains. Basically xend does the following: 1) mmap /proc/xen/privcmd 2) call an ioctl to populate the mmap 3) munmap the mapping created in (1) During the munmap, the dom0 kernel oopses, as

changeset: 30726:2a6fda4e7dde1a0a5d29a62303e85bcea868eb47 tag: tip user: Jimi Xenidis <jimix@watson.ibm.com> date: Thu Jul 13 11:51:38 2006 -0400 files: drivers/xen/privcmd/Makefile drivers/xen/privcmd/compat_privcmd.c fs/compat_ioctl.c include/xen/public/privcmd.h description: [ppc] ioctl32() compat plumbing for xen calls The following patch deals with xen

On Thu, 2005-06-16 at 06:17 +0100, Keir Fraser wrote: > > I suggested that we simply mmap /dev/kmem for the xenstored to access > > the domain0 page for the moment. That doesn''t work: we''ll do something > > else. > > Just use xc_map_foreign_range(), as you would for mapping any other > domain''s xenstore page. So here''s my patch

From: Randy Dunlap <randy.dunlap at oracle.com> scripts/headers_install.pl prevents "__user" from being exported to userspace headers, so just use compiler.h to make sure that __user is defined and avoid the error. unifdef: linux-next-20101112/xx64/usr/include/xen/privcmd.h.tmp: 79: Premature EOF (#if line 33 depth 1) Signed-off-by: Randy Dunlap <randy.dunlap at