This is a followup patch to incomplete CVE-2014-6271 fix code execution via
specially-crafted environment
This patch changes the encoding bash uses for exported functions to avoid
clashes with shell variables and to avoid depending only on an environment
variable's contents to determine whether or not to interpret it as a shell
function.
(From OE-Core daisy rev: 6c51cc96d03df26d1c10867633e7a10dfbec7c45)
(From OE-Core rev: af1f65b57dbfcaf5fc7c254dce80ac55f3a632cb)
Signed-off-by: Sona Sarmadi <sona.sarmadi@enea.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The bash_4.2 recipe was missed when the fix was backported to the dora
branch.
Patch from OE-Core master rev: 76a2d6b83472995edbe967aed80f0fcbb784b3fc
by Khem Raj <raj.khem@gmail.com>
(From OE-Core rev: a71680ec6e12c17159336dc34d904cb70155d0d7)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The bash_4.2 recipe was missed when the fix was backported to the dora
branch.
Patch based on the one from OE-Core master rev
798d833c9d4bd9ab287fa86b85b4d5f128170ed3 by Ross Burton
<ross.burton@intel.com>, with the content replaced from the
appropriate upstream patch.
(From OE-Core rev: 74d45affd5cda2e388d42db3322b4a0d5aff07e8)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The bash Makefile defines a dependency on itself and tries to run configure,
causing error messages when running ptest on target:
make: *** No rule to make target `configure.in', needed by `configure'.
make: *** No rule to make target `aclocal.m4', needed by `configure'.
make: *** No rule to make target `config.h.in', needed by `configure'.
make: *** No rule to make target `Makefile.in', needed by `Makefile'.
make: Failed to remake makefile `Makefile'.
This patch edits out this dependency in the Makefile installed for ptest,
to get rid of these messages.
(From OE-Core rev: b5fe8c9ff330105337b003be0de2f970545d13ef)
Signed-off-by: Sona Sarmadi <sona.sarmadi@enea.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
On hosts with FORTIFY_SOURCES, stringize support is required, as it's used by
the macros to wrap functions (e.g. read and open in unistd.h). Those wrappers
use the STRING() macro from unistd.h. A header in the bash sources overrides
the unistd.h macro to 'x' when HAVE_STRINGIZE is not defined, causing the
wrappers to generate calls to 'xread' and 'xopen', which do not exist,
resulting in a failure to link.
Assume we have stringize support when cross-compiling, which works around the
issue.
It may be best for upstream to either give up on supporting compilers without
stringize support, or to not define STRING() at all when FORTIFY_SOURCES is
defined, letting the unistd.h one be used, instead.
(From OE-Core rev: f7a25dd72d1d463eb72d48c6f9dd968d376496c0)
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>