bug#27429: Stack clash (CVE-2017-1000366 etc)

[Mark H Weaver <mhw@netris.org>]

Leo Famulari <leo@famulari.name> writes:

> On Wed, Jun 21, 2017 at 07:52:27PM -0400, Leo Famulari wrote:
>> On Wed, Jun 21, 2017 at 12:50:45PM +0300, Efraim Flashner wrote:
>> > Had to make a small change to the patch, it turns out it couldn't build
>> > the source for glibc@2.21, so I changed the source to inherit from
>> > glibc@2.22 and not just from glibc. It doesn't change anything for the
>> > actual glibc@2.25.
>> > 
>> > -- 
>> > Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
>> > GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
>> > Confidentiality cannot be guaranteed on emails sent or received unencrypted
>> 
>> > From ef14fa6db5eaedabbaa092cbed2b6f8ee903837c Mon Sep 17 00:00:00 2001
>> > From: Efraim Flashner <efraim@flashner.co.il>
>> > Date: Mon, 19 Jun 2017 23:13:53 +0300
>> > Subject: [PATCH] gnu: glibc: Patch CVE-2017-1000366.
>> > 
>> > * gnu/packages/base.scm (glibc/linux)[replacement]: New field.
>> > (glibc-2.25-fixed): New variable.
>> > (glibc@2.24, glibc@2.23, glibc@2.22, glibc@2.21)[source]: Add patches.
>> > [replacement]: New field.
>> > (glibc-locales)[replacement]: New field.
>> > * gnu/packages/commencement.scm (cross-gcc-wrapper)[replacement]: New field.

The commit log should mention the two packages that were converted to
use 'package/inherit'.

>> > * gnu/packages/patches/glibc-CVE-2017-1000366.patch,
>> > gnu/packages/patches/glibc-reject-long-LD-AUDIT.patch,
>> > gnu/packages/patches/glibc-reject-long-LD-PRELOAD.patch: New files.
>> > * gnu/local.mk (dist_patch_DATA): Add them.

Also, this patch includes some other unrelated fixes, such as changing
"gnu" to "%D%" in local.mk.  It would be good to split those off into
separate commits.

>> Thanks, I'm building a bare-bones disk image to test this patch.
>
> Hm, I noticed the bootstrap binaries being downloaded, so I don't think
> this patch applies the graft without causing a full rebuild.

It's likely that this is because of the new behavior of Hydra, where
NARs that haven't been fetched in the last 14 days are deleted, and then
those substitutes will fail the next time they are requested.

In this system fetching substitutes that are not often requested will
often fail.  One must try to fetch them, and then wait a while for Hydra
to rebuild the NARs, and then try again later.  FWIW, I don't like this
approach, but it's what we have for now.

       Mark