+-- On Fri, 16 Nov 2012, Kees Cook wrote --+
| Hrm? It should be showing only the live heap-allocated interp -- are
| you seeing uninitialized contents?
I don't see uninitialised content; I see interpreter names from previous
iterations. Which was the case earlier as well. The - interp - array is
initialised with the interpreter name, before being assigned to bprm->interp.
These - interp - bytes are *leaked* because after 4 recursions, when
load_script returns -ENOEXEC, - bprm->interp - becomes invalid for it starts
pointing to an invalid stack memory location.
Crux of the problem is in the fact that the recursion limit -
BINPRM_MAX_RECURSION(4) - exceeds after ones been rightly adhered to.
(bprm->recursion_depth > BINPRM_MAX_RECURSION))
return -ENOEXEC;
This check fails due to specific condition, which still exists.
Dynamically allocating memory fixes the leak by making the memory area live
and valid.
It does not fix the problem which caused the leak in the first place by
exceeding the BINPRM_MAX_RECURSION, not by 1 or 2 but possible 2^6
recursions. Isn't that performance hit?
--
Prasad J Pandit / Red Hat Security Response Team
DB7A 84C5 D3F9 7CD1 B5EB C939 D048 7860 3655 602B
--
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
