From 75b14a5de10a825348128bcca6c47fe5a29b8d31 Mon Sep 17 00:00:00 2001 From: Nicolas Iooss Date: Wed, 23 Nov 2016 23:06:44 +0100 Subject: [PATCH] libsepol: ebitmap: reject loading bitmaps with incorrect high bit Currently ebitmap_load() accepts loading a bitmap with highbit=192 and one node {startbit=0, map=0x2}. When iterating over the bitmap, ebitmap_for_each_bit() is expected to only yield "1" but it gives the following bits: 1, 65, 129. This is due to two facts in ebitmap_for_each_bit() implementation: * ebitmap_next() stays on the first (and only) node of the bitmap instead of stopping the iteration. * the end condition of the for loop consists in comparing the bit with ebitmap_length() (ie. the bitmap highbit), which is above the limit of the last node here. These are not bugs when the bitmap highbit is equals to l->startbit+MAPSIZE, where l is the last node (this is how ebitmap_set_bit() sets it). So a simple fix consists in making ebitmap_load() reject bitmaps which are loaded with an invalid highbit value. This issue has been found while fuzzing semodule_package with the American Fuzzy Lop. Signed-off-by: Nicolas Iooss --- libsepol/src/ebitmap.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/libsepol/src/ebitmap.c b/libsepol/src/ebitmap.c index fe8beb87..218adc29 100644 --- a/libsepol/src/ebitmap.c +++ b/libsepol/src/ebitmap.c @@ -453,6 +453,12 @@ int ebitmap_read(ebitmap_t * e, void *fp) l = n; } + if (count && l->startbit + MAPSIZE != e->highbit) { + printf + ("security: ebitmap: hight bit %u has not the expected value %zu\n", + e->highbit, l->startbit + MAPSIZE); + goto bad; + } ok: rc = 0;