Re: [PATCH] exec: do not leave bprm->interp on stack

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



+-- 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


[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux