The logic in oxenstored for handling writes depended on the order of evaluation of expressions making up a tuple. As indicated in section 7.7.3 "Operations on data structures" of the OCaml manual: <a href="http://caml.inria.fr/pub/docs/manual-ocaml/expr.html">http://caml.inria.fr/pub/docs/manual-ocaml/expr.html</a> the order of evaluation of subexpressions is not specified. In practice, different implementations behave differently.
oxenstored may not enforce the configured quota-maxentity. This allows a malicious or buggy guest to write as many xenstore entries as it wishes, causing unbounded memory usage in oxenstored. This can lead to a system-wide DoS.
Xen 4.1 and later are potentially vulnerable. Only systems using the OCaml xenstored implementation are potentially vulnerable. Systems using the C xenstored implementation are not vulnerable. Whether the compiled oxenstored binary is vulnerable depends on which compiler was used. OCaml can be compiled either as bytecode (with ocamlc) or as a native binary (with ocamlopt). The following OCaml program demonstrates the issue, and identifies whether the resulting oxenstored binary will skip the quota enforcement. $ cat order.ml let check () = let flag = ref false in let update _ = flag := true; () in List.iter update [1;2;3], !flag let main () = let _, flag = check () in if flag then print_endline "This code is not vulnerable!" else print_endline "This code is vulnerable!" let () = main () $ ocamlc order.ml -o order.bytecode $ ./order.bytecode This code is vulnerable! $ ocamlopt order.ml -o order.native $ ./order.native This code is not vulnerable! To confirm whether an OCaml binary is bytecode or native, use file. $ file order.bytecode order.bytecode: a /usr/bin/ocamlrun script executable (binary data) $ file order.native order.native: ELF 64-bit LSB executable, ... NOTE: These results are applicable to OCaml 4.01.0-5 as distributed in Debian Jessie. These results are not representative of other versions of OCaml, or of other OS distributions.