The aslr failures here are showing the same repeated memory layout values for the case when the stack rlimit is set to unlimited, which is a similar failure to CVE-2016-3672 (https://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-3672.html), which was the same issue but on x86/x86_64 kernels. Looking at the relevant bits of the upstream kernel source, we can see in http://lxr.free-electrons.com/source/arch/powerpc/mm/mmap.c#L96 , when mmap_is_legacy is true (either 32 bit compat mode or unlimited stack size), an unrandomized value is used for the mmap base value.
This is not a regression per se, in that we recently expanded the aslr tests to look for CVE-2016-3672 (but on all arches).
ppc64le failure log: https:/ /objectstorage. prodstack4- 5.canonical. com/v1/ AUTH_77e2ada1e7 a84929a74ba3b87 153c0ac/ autopkgtest- xenial/ xenial/ ppc64el/ l/linux/ 20160620_ 155235@ /log.gz
The aslr failures here are showing the same repeated memory layout values for the case when the stack rlimit is set to unlimited, which is a similar failure to CVE-2016-3672 (https:/ /people. canonical. com/~ubuntu- security/ cve/2016/ CVE-2016- 3672.html), which was the same issue but on x86/x86_64 kernels. Looking at the relevant bits of the upstream kernel source, we can see in http:// lxr.free- electrons. com/source/ arch/powerpc/ mm/mmap. c#L96 , when mmap_is_legacy is true (either 32 bit compat mode or unlimited stack size), an unrandomized value is used for the mmap base value.
This is not a regression per se, in that we recently expanded the aslr tests to look for CVE-2016-3672 (but on all arches).