Coverity points out that x86_insn_modrm() returns -EINVAL for instructions not
encoded with a ModRM byte. A consequence is that checking != 3 is
insufficient to confirm that &ext was actually written to.
In practice, this check is only used after decode has been successful, and
0f01 will have a ModRM byte.
Use an unsigned < comparison to exclude the -EINVAL case, guaranteeing that
ext is only read if it was filled in by x86_insn_modrm(), which should placate
Coverity.
Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
---
CC: Jan Beulich <jbeul...@suse.com>
CC: Boris Ostrovsky <boris.ostrov...@oracle.com>
CC: Suravee Suthikulpanit <suravee.suthikulpa...@amd.com>
RFC. I haven't actually checked that this fixes the issue.
An alternative would be to ASSERT() that x86_insn_modrm() is non-negative, but
I can't nice way of integrating that into the existing logic (without using
the comma operator, and that isn't nice to read).
---
xen/arch/x86/hvm/svm/svm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index ae8e2c4..ff134a5 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -2162,7 +2162,7 @@ static bool is_invlpg(const struct x86_emulate_state
*state,
unsigned int ext;
return ctxt->opcode == X86EMUL_OPC(0x0f, 0x01) &&
- x86_insn_modrm(state, NULL, &ext) != 3 &&
+ (unsigned int)x86_insn_modrm(state, NULL, &ext) < 3 &&
(ext & 7) == 7;
}
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
