summaryrefslogtreecommitdiffstats
path: root/scripts/qapi-visit.py
diff options
context:
space:
mode:
authorJan Beulich2016-05-23 08:44:57 +0200
committerStefano Stabellini2016-06-13 15:32:28 +0200
commit4837a1a51638ef1719bf8149591a57e7207db41a (patch)
tree443bc72bdf7d1138c736c0f7d5eafb5869a7e3d1 /scripts/qapi-visit.py
parentMerge remote-tracking branch 'remotes/berrange/tags/qcrypto-next-2016-06-13-v... (diff)
downloadqemu-4837a1a51638ef1719bf8149591a57e7207db41a.tar.gz
qemu-4837a1a51638ef1719bf8149591a57e7207db41a.tar.xz
qemu-4837a1a51638ef1719bf8149591a57e7207db41a.zip
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 'scripts/qapi-visit.py')
0 files changed, 0 insertions, 0 deletions