Behaviour change in reading /proc/modules could cause issues in userspace tools

Bug #1757217 reported by Jeff Lane 
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Confirmed
Medium
Unassigned
Bionic
Confirmed
Medium
Unassigned

Bug Description

This was discovered while investigating tracebacks in the cert suite. We have a script that parses /proc/modules and returns the information in a more human-readable format as part of the info gathering we do during cert testing.

On 4.13 and older kernels, this script was run as a normal user with no error. On 4.15, this script dumps a python trace because /proc/modules now returns a null reference instead of just a blank memory offset.

On 4.13 and older, when you read the file, you get something like this (root and non-root shown):

bladernr@galactica:~$ sudo cat /proc/modules |grep nls_iso8859
nls_iso8859_1 16384 1 - Live 0xffffffffc06b5000
bladernr@galactica:~$ cat /proc/modules |grep nls_iso8859
nls_iso8859_1 16384 1 - Live 0x0000000000000000

Note that non-root reading returns a memory offset of 0x0 which is easily parsable.

Now, on 4.15, this has changed:

ubuntu@xwing:~$ sudo cat /proc/modules |grep e1000e
e1000e 249856 0 - Live 0xffffffffc0225000
ptp 20480 2 igb,e1000e, Live 0xffffffffc00a9000
ubuntu@xwing:~$ cat /proc/modules |grep e1000e
e1000e 249856 0 - Live 0x (null)
ptp 20480 2 igb,e1000e, Live 0x (null)

Now, however, non-root reading returns a null reference which causes attempts to parse the offset to fail.

I imagine this is probably by design, and it's a minor bug, but I wanted to raise it as it could cause issues when running userspace tools that parse /proc/modules on 4.15.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: linux-image-4.15.0-12-generic 4.15.0-12.13
ProcVersionSignature: User Name 4.15.0-12.13-generic 4.15.7
Uname: Linux 4.15.0-12-generic x86_64
AlsaDevices:
 total 0
 crw-rw---- 1 root audio 116, 1 Mar 20 17:24 seq
 crw-rw---- 1 root audio 116, 33 Mar 20 17:24 timer
AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay'
ApportVersion: 2.20.8-0ubuntu10
Architecture: amd64
ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord': 'arecord'
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1:
Date: Tue Mar 20 17:59:51 2018
MachineType: LENOVO INVALID
PciMultimedia:

ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=C.UTF-8
 SHELL=/bin/bash
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-12-generic.efi.signed root=UUID=9fdf32ba-26ce-4d54-8457-dbd62057c7e9 ro
RelatedPackageVersions:
 linux-restricted-modules-4.15.0-12-generic N/A
 linux-backports-modules-4.15.0-12-generic N/A
 linux-firmware 1.173
RfKill: Error: [Errno 2] No such file or directory: 'rfkill': 'rfkill'
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 04/07/2017
dmi.bios.vendor: LENOVO
dmi.bios.version: FBKT97CUS
dmi.board.name: ThinkServer RS140
dmi.board.vendor: LENOVO
dmi.board.version: Not Defined
dmi.chassis.type: 7
dmi.chassis.vendor: LENOVO
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias: dmi:bvnLENOVO:bvrFBKT97CUS:bd04/07/2017:svnLENOVO:pnINVALID:pvrFFFFFFF:rvnLENOVO:rnThinkServerRS140:rvrNotDefined:cvnLENOVO:ct7:cvrToBeFilledByO.E.M.:
dmi.product.family: To be filled by O.E.M.
dmi.product.name: INVALID
dmi.product.version: FFFFFFF
dmi.sys.vendor: LENOVO

Revision history for this message
Jeff Lane  (bladernr) wrote :
description: updated
Revision history for this message
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote : Status changed to Confirmed

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.16 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.16-rc6

Changed in linux (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Incomplete
no longer affects: linux (Ubuntu Artful)
tags: added: kernel-da-key
Revision history for this message
Jeff Lane  (bladernr) wrote :

I tried 4.16 and the behaviour there seems to follow the old experiences:

ubuntu@xwing:~$ uname -a
Linux xwing 4.16.0-041600rc6-generic #201803182230 SMP Mon Mar 19 02:32:18 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
ubuntu@xwing:~$ cat /proc/modules |grep megaraid
megaraid_sas 139264 2 - Live 0x0000000000000000
ubuntu@xwing:~$ sudo cat /proc/modules |grep megaraid
megaraid_sas 139264 2 - Live 0xffffffffc0194000

reading /proc/modules as a non-root user once again returns a valid 0x0 memory offset without the Null reference that caused the problems before.

Changed in linux (Ubuntu Bionic):
status: Incomplete → Confirmed
Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

Can you test the latest upstream stable 4.15 kernel? That will tell us if the fix in mainline was already cc'd to stable. It can be downloaded from:

http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.15.12/

Revision history for this message
Jeff Lane  (bladernr) wrote :

Hi Joeseph,

I tried 4.15.12 mainline and it also does not have the null reference problem:

ubuntu@xwing:~$ uname -r
4.15.12-041512-generic
ubuntu@xwing:~$ cat /proc/modules |grep multipath
multipath 16384 0 - Live 0x0000000000000000
ubuntu@xwing:~$ sudo cat /proc/modules |grep multipath
multipath 16384 0 - Live 0xffffffffc0405000

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

That is good news. That means Bionic should get the fix through the normal stable update process.

The current Bionic -proposed kernel(4.15.0-13) has up to the 4.15.10 updates applied. It might be worth testing the proposed kernel to see if we already have the fix and don't have to wait for the 4.15.11 or 4.15.12 upstream updates.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.