On Wed, Dec 30, 2020 at 11:46 AM Nicolas Iooss <nicolas.iooss@xxxxxxx> wrote: > > Hello, > > A few weeks ago, OSS-Fuzz got configured in order to fuzz the CIL > policy compiler. One of the issue it reported was a "Stack-overflow in > __cil_resolve_name_with_parents", which seemed strange > (https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28491, for > future reference). > > By looking into it, the reduced test-case is the following CIL policy: > > (optional o > (block b > (block b > (blockabstract b0) > ) > (blockinherit b) > ) > ) > (blockinherit b) > > When building this policy with secilc, the command seems to be caught > in a loop that never ends. Using gdb to break somewhere leads to the > following call stack: > > #0 0x0000555555bab646 in __cil_resolve_name_with_parents > (node=0x606000000fe0, name=<optimized out>, sym_index=<optimized out>, > datum=<optimized out>) at ../cil/src/cil_resolve_ast.c:4070 > #1 0x0000555555baae73 in __cil_resolve_name_helper (db=<optimized > out>, node=<optimized out>, name=0x602000002850 "b0", > sym_index=CIL_SYM_BLOCKS, datum=0x7fffffffcd80) at > ../cil/src/cil_resolve_ast.c:4122 > #2 0x0000555555b7865b in cil_resolve_name_keep_aliases > (ast_node=<optimized out>, name=<optimized out>, sym_index=<optimized > out>, extra_args=<optimized out>, datum=<optimized out>) at > ../cil/src/cil_resolve_ast.c:4173 > #3 0x0000555555b70384 in cil_resolve_name (ast_node=0x0, name=0x0, > sym_index=CIL_SYM_BLOCKS, extra_args=0x7fffffffcd80, > datum=0x7fffffffcd80) at ../cil/src/cil_resolve_ast.c:4134 > #4 0x0000555555b96b9f in cil_resolve_blockabstract > (current=0x606000001040, extra_args=<optimized out>) at > ../cil/src/cil_resolve_ast.c:2457 > #5 0x0000555555ba4c2c in __cil_resolve_ast_node (node=<optimized > out>, extra_args=<optimized out>) at ../cil/src/cil_resolve_ast.c:3450 > #6 0x0000555555ba6e00 in __cil_resolve_ast_node_helper > (node=<optimized out>, finished=<optimized out>, extra_args=<optimized > out>) at ../cil/src/cil_resolve_ast.c:3769 > #7 0x0000555555bb86ed in cil_tree_walk_core (node=0x606000001040, > process_node=<optimized out>, first_child=<optimized out>, > last_child=<optimized out>, extra_args=<optimized out>) at > ../cil/src/cil_tree.c:272 > #8 0x0000555555bb8bf2 in cil_tree_walk (node=0x606000000fe0, > process_node=<optimized out>, first_child=<optimized out>, > last_child=<optimized out>, extra_args=<optimized out>) at > ../cil/src/cil_tree.c:316 > #9 0x0000555555bb87f0 in cil_tree_walk_core (node=0x606000000fe0, > process_node=<optimized out>, first_child=<optimized out>, > last_child=<optimized out>, extra_args=<optimized out>) at > ../cil/src/cil_tree.c:284 > #10 0x0000555555bb8bf2 in cil_tree_walk (node=0x606000000bc0, > process_node=<optimized out>, first_child=<optimized out>, > last_child=<optimized out>, extra_args=<optimized out>) at > ../cil/src/cil_tree.c:316 > #11 0x0000555555bb87f0 in cil_tree_walk_core (node=0x606000000bc0, > process_node=<optimized out>, first_child=<optimized out>, > last_child=<optimized out>, extra_args=<optimized out>) at > ../cil/src/cil_tree.c:284 > #12 0x0000555555bb8bf2 in cil_tree_walk (node=0x606000000980, > process_node=<optimized out>, first_child=<optimized out>, > last_child=<optimized out>, extra_args=<optimized out>) at > ../cil/src/cil_tree.c:316 > #13 0x0000555555bb87f0 in cil_tree_walk_core (node=0x606000000980, > process_node=<optimized out>, first_child=<optimized out>, > last_child=<optimized out>, extra_args=<optimized out>) at > ../cil/src/cil_tree.c:284 > #14 0x0000555555bb8bf2 in cil_tree_walk (node=0x606000000080, > process_node=<optimized out>, first_child=<optimized out>, > last_child=<optimized out>, extra_args=<optimized out>) at > ../cil/src/cil_tree.c:316 > #15 0x0000555555ba9dd1 in cil_resolve_ast (db=<optimized out>, > current=<optimized out>) at ../cil/src/cil_resolve_ast.c:3937 > #16 0x0000555555a1d64a in cil_compile (db=0x6120000001c0) at > ../cil/src/cil.c:550 > #17 0x00005555559e9d06 in main () > > However, if I understand correctly the documentation > (https://github.com/SELinuxProject/selinux/blob/master/secilc/docs/cil_container_statements.md), > having two "(block b)" and a "(blockabstract b0)" that does not > reference "b" are not supposed to work. Maybe the CIL compiler needs > to detect such issues and fail instead of entering some kind of loop. > How should this issue be fixed? That seems reasonable to me, but I would say this CIL not my forte. Have you had any other thoughts around this? > > Nicolas >
