The upstream commit to fix the issue is linked in the message below:
http://openwall.com/lists/oss-security/2017/01/11/8

Fixed in cauldron. Pushed asked.

The patch doesn't apply to 1.9.1 in MGA5. Do you want me to bump the version to 1.12.6 as well ? That may require other packages to be added/updated due to that.

Status: NEW => ASSIGNED

BTW I'm not able to tell whether 1.9.1 is also affected.

Fedora has issued an advisory for this on January 12:
https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/BQAXJMMLRU7DD2IMG47SR2K4BOFFG7FZ/

URL: (none) => https://lwn.net/Vulnerabilities/711582/

docker-1.12.6-1.mga6 was pushed, so Cauldron is fixed.

Version: Cauldron => 5

I've now proposed 17.03 for cauldron. However, I still don't know what to do for mga5. 19.1 is very old now (wrt the pace of delivery around docker) and I'm not even sure 1.12.6 would be relevant. And after that there are lots of changes that would need to be done, including new go versions for 17.03 e.g.

It looks like the two patches attached to the SuSE bug are needed:
https://bugzilla.suse.com/attachment.cgi?id=709048
https://bugzilla.suse.com/attachment.cgi?id=709049

I haven't really looked at the second one, but the first one looks like it could be applied with a little re-diffing.  That patch corresponds to the upstream commit mentioned in Comment 1.

I've applied the 2 commits, with the second one really adapted. Not sure whether it's correct as I'm not a go programmer. Builds correctly. Everything pushed, would appreciate a test from someone else.

(In reply to Bruno Cornec from comment #9)
> Everything pushed, would appreciate a test from someone else.

Like the QA team?  :D

Advisory:
========================

Updated docker packages fix security vulnerability:

The runc component used by `docker exec` feature of docker allowed additional
container processes to be ptraced by the pid 1 of the container. This allows
the main processes of the container, if running as root, to gain low-level
access to these new processes during initialization. An attacker can, depending
on the nature of the incoming process, leverage this to elevate access to the
host. This ranges from accessing host content through the file descriptors of
the incoming process to, potentially, a complete container escape by leveraging
memory access or syscall interception (CVE-2016-9962).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-9962
https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/BQAXJMMLRU7DD2IMG47SR2K4BOFFG7FZ/
========================

Updated packages in core/updates_testing:
========================
docker-1.9.1-1.2.mga5
docker-devel-1.9.1-1.2.mga5
docker-fish-completion-1.9.1-1.2.mga5
docker-logrotate-1.9.1-1.2.mga5
docker-unit-test-1.9.1-1.2.mga5
docker-vim-1.9.1-1.2.mga5
docker-zsh-completion-1.9.1-1.2.mga5

from docker-1.9.1-1.2.mga5.src.rpm

Make sure you're CC'd when you assign a bug to QA.

CC: (none) => bruno

Starting to test this on x86_64 by following a tutorial.  Attaching a progress file at some point.

CC: (none) => tarazed25

Created attachment 9442 [details]
First part of learning curve

Tutorial interrupted when docker behaviour diverged from expectations; probably occasioned by the mismatch in version numbers - tutorial lagging behind.

What should have been mentioned is that a PoC for this is available in the form of a special patch to be applied to local builds before and after the update.  There may be nobody in QA qualified for that task so we must fall back on the functionality tests.  Also, docker is strictly a 64-bit engine - no i586 testing needed.

Using some more up-to-date documentation (too much so actually) I extended the tutorial and shared a docker image online.  See attachment.

That should be enough to test functionality.  Shall run through it after the update.

Created attachment 9443 [details]
Functionality test part 2

Created attachment 9444 [details]
app.py and requirements.txt

These are needed to build the specimen Dockerfile.

docker is a big subject.  These tutorial tests have just scratched the surface but all looks well so far so letting it go.

An update for this issue has been pushed to the Mageia Updates repository.

http://advisories.mageia.org/MGASA-2017-0189.html

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED