On Thu, Nov 22, 2012 at 6:17 AM, P J P <ppandit@xxxxxxxxxx> wrote: > +-- On Mon, 19 Nov 2012, Kees Cook wrote --+ > | I think to avoid the explosion of request_module calls in the abusive > | case, we could simply return ELOOP instead of ENOEXEC on max > | recursion. > > -> http://www.spinics.net/lists/mm-commits/msg92433.html > > 1. returning -ELOOP has a side effect of not reaching to request_module() > ever, for: > == > #ifdef CONFIG_MODULES > 1415 if (retval != -ENOEXEC || bprm->mm == NULL) { > 1416 break; > 1417 } else { > ... > == Well, "ever" meaning "if depth is hit, always fail out", yes. This is intentional. We do not want to attempt module loading if we hit a recursion limit. > 2. above patch does not seem to fix the 2^6(64) recursions issue, for: > == > + bprm->recursion_depth = depth + 1; > retval = fn(bprm); > bprm->recursion_depth = depth; > == > > setting - recursion_dept = depth - again and the outer for(try=0;try<2...) > loop seems to be causing the 2^6 recursions. When entering recursion, we set "depth + 1", and when leaving, we restore it to "depth". When -ELOOP is set, we fail back through all levels of recursion instead of attempting to retry the loop. -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
