* flask_copyin_string integer overflow

This function allocates a buffer sized to hold an incoming string along with null termination by adding one to the incoming string size; this can overflow if size == ~0.

This function is reachable by unprivileged users by using FLASK_{GET,SET}BOOL (no permission checks are made by Xen or Flask).

Overflow will lead xmalloc_bytes to be asked to allocate 0 bytes, which it handles by returning a static sentinel value, ZERO_BLOCK_PTR, which is 0xBAD0BAD0BAD0BAD0ul on x86 and -1ul otherwise. Hence on x86, when flask_copyin_string then tries to copy ~0 bytes into this location, we get a GPF (non-canonical address). On ARM I'm not sure, but I suppose a fatal PF or whatever.

I think the best fix would be to add a limit to the incoming string length in flask_copyin_string, but it shouldn't just be ~0 - 1, but instead something more sensible so that users can't allocate 4GB of memory in one go either. Not sure what size exactly, so I haven't suggested a patch yet.


* flask_security_avc_cachestats (only #ifdef FLASK_AVC_STATS, which is defined for FLASK_ENABLEd builds by default by xen/Rules.mk)

Off-by-one when checking the user-provided arg->cpu against nr_cpu_ids (uses >, should be >=).

Reachable by unprivileged users by using FLASK_AVC_CACHESTATS.

After the check "passing", cpu_online checks the cpumask cpu_online_map which is length NR_CPUS, so nr_cpu_ids would have to == NR_CPUS(!) for this to be an issue of any sort. Not sure what happens then, either read out dodgy data or die trying.