summaryrefslogtreecommitdiff
path: root/hw/block/xen_disk.c
diff options
context:
space:
mode:
authorJan Beulich <JBeulich@suse.com>2016-05-23 00:44:57 -0600
committerStefano Stabellini <sstabellini@kernel.org>2016-06-13 14:32:28 +0100
commit4837a1a51638ef1719bf8149591a57e7207db41a (patch)
tree443bc72bdf7d1138c736c0f7d5eafb5869a7e3d1 /hw/block/xen_disk.c
parent55e5c3a2d2433bd2e1e635a7ba395f1c70341794 (diff)
downloadqemu-4837a1a51638ef1719bf8149591a57e7207db41a.tar.gz
xen/blkif: avoid double access to any shared ring request fields
Commit f9e98e5d7a ("xen/blkif: Avoid double access to src->nr_segments") didn't go far enough: src->operation is also being used twice. And nothing was done to prevent the compiler from using the source side of the copy done by blk_get_request() (granted that's very unlikely). Move the barrier()s up, and add another one to blk_get_request(). Note that for completing XSA-155, the barrier() getting added to blk_get_request() would suffice, and hence the changes to xen_blkif.h are more like just cleanup. And since, as said, the unpatched code getting compiled to something vulnerable is very unlikely (and not observed in practice), this isn't being viewed as a new security issue. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Diffstat (limited to 'hw/block/xen_disk.c')
-rw-r--r--hw/block/xen_disk.c2
1 files changed, 2 insertions, 0 deletions
diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 064c116a7c..cf57814fb6 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -679,6 +679,8 @@ static int blk_get_request(struct XenBlkDev *blkdev, struct ioreq *ioreq, RING_I
RING_GET_REQUEST(&blkdev->rings.x86_64_part, rc));
break;
}
+ /* Prevent the compiler from accessing the on-ring fields instead. */
+ barrier();
return 0;
}