Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#57446 - [linux] linux-4.15.1-2 vsyscall=emulate kernel parameter ignored

Attached to Project: Arch Linux
Opened by Jacob Beck (jcjeb) - Friday, 09 February 2018, 19:51 GMT
Last edited by Doug Newgard (Scimmia) - Friday, 09 February 2018, 20:23 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To No-one
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description: In 4.15, the config parameter LEGACY_VSYSCALL_NONE is set by default. It should be possible to override it by setting "vsyscall=emulate" (or "vsyscall=native") on the kernel parameters line. While it is a security issue, any docker containers using a glibc version <= 2.13 will fail at the entrypoint without this setting. You can see where the docker developers have written it into their check script here: https://github.com/moby/moby/blob/master/contrib/check-config.sh#L235-L240

I appreciate the security benefits of the change to LEGACY_VSYSCALL_NONE, but it's valuable to be able to override it for legacy reasons.

An example of an openly available docker image running this version is the mongo 3.0 image, but anything based on centos6 should also fail.

Additional info:
* package version(s): 4.15.1-2

Steps to reproduce:
- Upgrade to linux 4.15
- Install docker
- run "docker run --rm -it mongo:3.0"

Your container will exit with 139 (SIGSEGV) and you'll get a systemd log message like this:

Process 7742 (docker-entrypoi) of user 0 dumped core.
Stack trace of thread 1:
#0 0xffffffffff600400 n/a (n/a)

I believe the cause of it is that CONFIG_X86_VSYSCALL_EMULATION is not set, and it defaults to "n", which is similar to setting vsyscall=none but without being able to override it from the cmdline. But I'm not a kernel expert by any means.

This is related to, but not the same as issue #57408 - different kernel config parameters are involved.
This task depends upon

Closed by  Doug Newgard (Scimmia)
Friday, 09 February 2018, 20:23 GMT
Reason for closing:  Duplicate
Additional comments about closing:   FS#57336 

Loading...