Ben Hutchings:
> On Thu, 2017-03-23 at 17:06 +0000, James Cowgill wrote:
> [...]
>> The reason the program and the heap are at these very high addresses is
>> that xsltproc is built with PIE and the kernel is treating the
>> executable like a mmap and grouping it with all the other libraries. In
>> d1fd836dcf00 ("mm: split ET_DYN ASLR from mmap ASLR") the behavior
>> changed and now the program and it's heap will be mapped at a lower
>> address so the bug does not affect newer kernels. Using "setarch -L" or
>> "setarch -R" is another workaround for this bug because that moves the
>> program so that there is a much larger gap between the heap and the stack.
>>
>> This might affect other applications as well. Effectively it means that
>> PIE executables which use lots of stack space might not work properly
>> with jessie's kernel. The chances the bug will be hit seems to vary
>> between arches however (depending on what each arch does in
>> arch_pick_mmap_layout and arch_randomize_brk) - mips64el seems to be hit
>> pretty frequently. In xsltproc's case, PIE was enabled some time ago
>> which is why this bug is quite old.
>>
>> I believe any of the following will fix this (but have not all been tested):
>> - Reduce the stack usage in xsltproc (the upstream bug)
>> - Upgrade the relevant buildds to Linux >= 4.1
>> - Apply d1fd836dcf00 to jessie's kernel
>
> That's part of a series of 10 commits covering multiple architectures.
> I already picked one of them as a dependency for fixing CVE-2016-3672,
> which leaves 9 to do. I think it is worth doing this in stable to
> support chroots and partial upgrades, but I would like to hear the
> release team ack/nak this in principle before I start preparing the
> change for Debian stable.
>
> Kees Cook quotes the list of commits here:
> http://lists.openwall.net/linux-kernel/2015/07/27/964
> (I can't find the original message).
>
> Ben.
>
>> - Disable PIE in xsltproc.
>> - Run xsltproc inside setarch -L / setarch -R
> [...]
>
Hi Ben,
Could you please file a pu bug for this? I fear that otherwise, it
might be overlooked for the next time the SRMs review the outstanding
stable update requests.
Thanks,
~Niels
