5.0.0-27-generic: /proc/<pid>/maps: Pathnames are '/' inside a container

[Frederik Carlier]

Using kernel 5.0.0-27-generic on Ubuntu 18.04 in a container, every pathname in /proc/<pid>/maps is / instead of the mapped file path.

This appears to be a regression in 5.0.0-27-generic; it works on 5.0.0-25-generic. The problem can be reproduced in various Ubuntu releases, e.g. 18.04 and 19.04.

5.0.0-25-generic (working):

$ sudo docker run ubuntu cat /proc/1/maps
56324a3f5000-56324a3fd000 r-xp 00000000 fc:01 665673 /bin/cat
56324a5fc000-56324a5fd000 r--p 00007000 fc:01 665673 /bin/cat
56324a5fd000-56324a5fe000 rw-p 00008000 fc:01 665673 /bin/cat
56324a8eb000-56324a90c000 rw-p 00000000 00:00 0 [heap]
7f8ab5f91000-7f8ab6178000 r-xp 00000000 fc:01 666073 /lib/x86_64-linux-gnu/libc-2.27.so
7f8ab6178000-7f8ab6378000 ---p 001e7000 fc:01 666073 /lib/x86_64-linux-gnu/libc-2.27.so
7f8ab6378000-7f8ab637c000 r--p 001e7000 fc:01 666073 /lib/x86_64-linux-gnu/libc-2.27.so
7f8ab637c000-7f8ab637e000 rw-p 001eb000 fc:01 666073 /lib/x86_64-linux-gnu/libc-2.27.so
7f8ab637e000-7f8ab6382000 rw-p 00000000 00:00 0
7f8ab6382000-7f8ab63a9000 r-xp 00000000 fc:01 666055 /lib/x86_64-linux-gnu/ld-2.27.so
7f8ab6583000-7f8ab65a7000 rw-p 00000000 00:00 0
7f8ab65a9000-7f8ab65aa000 r--p 00027000 fc:01 666055 /lib/x86_64-linux-gnu/ld-2.27.so
7f8ab65aa000-7f8ab65ab000 rw-p 00028000 fc:01 666055 /lib/x86_64-linux-gnu/ld-2.27.so
7f8ab65ab000-7f8ab65ac000 rw-p 00000000 00:00 0
7ffc25954000-7ffc25975000 rw-p 00000000 00:00 0 [stack]
7ffc259f1000-7ffc259f4000 r--p 00000000 00:00 0 [vvar]
7ffc259f4000-7ffc259f5000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]

5.0.0-27-generic (broken):

$ sudo docker run ubuntu cat /proc/1/maps
55de0e052000-55de0e05a000 r-xp 00000000 fc:01 665673 /
55de0e259000-55de0e25a000 r--p 00007000 fc:01 665673 /
55de0e25a000-55de0e25b000 rw-p 00008000 fc:01 665673 /
55de0fcb3000-55de0fcd4000 rw-p 00000000 00:00 0 [heap]
7f7a8d881000-7f7a8da68000 r-xp 00000000 fc:01 666073 /
7f7a8da68000-7f7a8dc68000 ---p 001e7000 fc:01 666073 /
7f7a8dc68000-7f7a8dc6c000 r--p 001e7000 fc:01 666073 /
7f7a8dc6c000-7f7a8dc6e000 rw-p 001eb000 fc:01 666073 /
7f7a8dc6e000-7f7a8dc72000 rw-p 00000000 00:00 0
7f7a8dc72000-7f7a8dc99000 r-xp 00000000 fc:01 666055 /
7f7a8de73000-7f7a8de97000 rw-p 00000000 00:00 0
7f7a8de99000-7f7a8de9a000 r--p 00027000 fc:01 666055 /
7f7a8de9a000-7f7a8de9b000 rw-p 00028000 fc:01 666055 /
7f7a8de9b000-7f7a8de9c000 rw-p 00000000 00:00 0
7ffc744bd000-7ffc744de000 rw-p 00000000 00:00 0 [stack]
7ffc7452d000-7ffc74530000 r--p 00000000 00:00 0 [vvar]
7ffc74530000-7ffc74531000 r-xp 00000000 00:00 0 [vdso]

[Frederik Carlier (qmfrederik)]

This impacts applications which use /proc/<pid>/map to find out their location. For example, .NET Core applications use approach, and are currently broken in containers on Ubuntu running the 5.0.0-27-generic kernel. See https://github.com/dotnet/corefx/issues/40850 for more information.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Marc Wittke (mpwittke)]

confirmed to break on 5.0.0-1018-azure, last known good version is 5.0.0-1016-azure

[Frank Gynnild (frankgy)]

We're using Linux Azure VMs as Jenkins build agents, and currently all our .NET Core builds are broken due to this bug. Haven't yet found a way to control the kernel image for it, in order to downgrade. Please fix ASAP :-)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Mitch Dart (mitchdart)]

Our developers are unable to debug our applications because they use the vsdbg inside docker which makes use of the /proc/<pid>/maps. Even after enabling preview software for 5.0.0-28, the bug still exists. Our only option at this point is to roll back the Kernel.

[Michaël Lefevre (lefevre00)]

Confirm that it's break our docker container on azure.

Same container were running fine on 5.0.0-1014, break on 1018.
I've succeed to reproduce on a virtual box 18.04.3 image:
* default generic kernel to create your container : ok
* add azure.archive.ubuntu.com repo
* install linux-azure-5.0.0-1018
* reboot
* run your docker container again, not working any more

Used on azure scaleset, VM image created with cloudinit not usable anymore

[Radoslaw Jurewicz (radoslaw-jurewicz)]

My team has encountered this as well and it affects both our on-premise Linux as well as Azure VMs kernels. Last versions which were working for us are:
- In azure case 5.0.0-1016-azure
- In case of on-premise 5.0.0-25-generic
After upgrading to 5.0.0.-1018-azure and 5.0.0-28, respectively, both stopped working.

[Francesco Tamagni (mrmacete)]

Same issue with Frida running in docker on Ubuntu 19.04.

It stopped working from 5.0.0-27-generic, the issue persisted with 5.0.0-29-generic.

Booting with 5.0.0-25-generic is the current workaround.

[Ruben Labruyere (rmlabruyere)]

Encountered this as well. I have several TeamCity docker build agents which stopped working after updating the host machine, which is a Ubuntu Server 1804 Virtual Machine on Azure. Downgrading the Linux kernel fixed it for me.

[rob (clarity9999)]

github actions CI/CD is broken because of this as well

[Seth Forshee (sforshee)]

This is a duplicate of bug 1842382, patch submitted already:

https://lists.ubuntu.com/archives/kernel-team/2019-September/103893.html