summaryrefslogtreecommitdiff
path: root/libm/i386/ftestexcept.c
diff options
context:
space:
mode:
authorFilippo ARCIDIACONO <filippo.arcidiacono@st.com>2012-12-14 11:40:05 +0100
committerCarmelo Amoroso <carmelo.amoroso@st.com>2013-05-13 10:08:11 +0200
commitf74663a2e6e3395d8f7e83efc28799c85842bed1 (patch)
tree987d3ec6777427e6408579d986664d358c09dbe3 /libm/i386/ftestexcept.c
parent458076d59ef9849f79d27e21b6094b0b3a85fbb4 (diff)
libc: deal with aux vect inside __uClibc_main only if !SHARED
It's not safe to use the aux vect inside __uClibc_main if we are running with shared libraries, because it could have been already modified. For example, if some constructor plays with environment variables by using unsetenv, the modifications done into the stack to unset an environment variable, have impacts on the aux vect due to the extra NULL entries added. Due to this, __uClibc_main is not able to detect where the aux vect starts, so all the entries that are used by __uClibc_main (AT_UID, AT_EUID, AT_GID, AT_EGID, AT_PAGESZ and possibly other arch specific) are impacted. Same side effect on the aux vect is caused by the ld.so when running a SUID program with some of the unsecure environment variables set, that will be unset by the ld.so itself. In order to fix this issue, it needs to handle aux vect entries into __uClibc_main only if SHARED is not defined. In SHARED case, libc refers to __dl_secure and _dl_pagesize as initialised by the ld.so where the aux vext is still untouched. Signed-off-by: Filippo Arcidiacono <filippo.arcidiacono@st.com> Reviewed-by: Carmelo Amoroso <carmelo.amoroso@st.com> Signed-off-by: Carmelo Amoroso <carmelo.amoroso@st.com>
Diffstat (limited to 'libm/i386/ftestexcept.c')
0 files changed, 0 insertions, 0 deletions