BUG: unable to handle kernel NULL pointer dereference at 0000000000000010

[Tyler Hicks]

I hit this bug as I'm logging in to an encrypted home account after booting with systemd. It results in a hung system immediately after the password authentication stage as pam_ecryptfs call mount.ecryptfs to mount the user's encrypted home directory.

I can't reproduce it in a VM. Booting with upstart works fine. I was previously booting with systemd without any problem so this may be due to a change in the 219-6ubuntu1 systemd update.

ProblemType: KernelOops
DistroRelease: Ubuntu 15.04
Package: linux-image-3.19.0-11-generic 3.19.0-11.11
ProcVersionSignature: Ubuntu 3.19.0-11.11-generic 3.19.3
Uname: Linux 3.19.0-11-generic x86_64
Annotation: Your system might become unstablenow and might need to be restarted.
ApportVersion: 2.17-0ubuntu1
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: tyhicks 3786 F.... pulseaudio
Date: Thu Apr 2 14:19:21 2015
DuplicateSignature: BUG: unable to handle kernel NULL pointer dereference at location RIP: 0010:location location propagate_one+0xc7/0x1e0
Failure: oops
InstallationDate: Installed on 2011-08-23 (1318 days ago)
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Release amd64 (20110427.1)
MachineType: LENOVO 4286CTO
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.19.0-11-generic root=UUID=bd144b12-0d78-4d1e-b69c-8d83ee663c8f ro quiet splash kaslr crashkernel=384M-:128M crashkernel=384M-:128M vt.handoff=7 init=/sbin/upstart
PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon.
RelatedPackageVersions: kerneloops-daemon 0.12+git20090217-3ubuntu8
SourcePackage: linux
Title: BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
UpgradeStatus: Upgraded to vivid on 2015-02-27 (34 days ago)
dmi.bios.date: 04/11/2013
dmi.bios.vendor: LENOVO
dmi.bios.version: 8DET68WW (1.38 )
dmi.board.asset.tag: Not Available
dmi.board.name: 4286CTO
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr8DET68WW(1.38):bd04/11/2013:svnLENOVO:pn4286CTO:pvrThinkPadX220:rvnLENOVO:rn4286CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 4286CTO
dmi.product.version: ThinkPad X220
dmi.sys.vendor: LENOVO

[Brad Figg (brad-figg)]

This change was made by a bot.

[Tyler Hicks (tyhicks)]

I've downgraded all of the systemd packages to version 219-4ubuntu10 and still hit this bug. I'm going to stop trying to determine what userspace change started triggering this bug and start looking for a kernel fix.

[Tyler Hicks (tyhicks)]

The v4.0-rc6-vivid mainline kernel build does not hit the BUG.

[Tyler Hicks (tyhicks)]

The v3.19.3-vivid mainline kernel build, which is the stable kernel that Ubuntu 3.19.0-11.11-generic is based on, does not hit the BUG. That possibly suggests something in our delta??

[Chris J Arges (arges)]

Do you have a proper kernel log with this bug? Or perhaps if you can setup crashdump on your laptop and trigger this it may make it easier to get information about the crash. Then identifying the delta may be easier.

[Tyler Hicks (tyhicks)]

Hey Chris - what other info are you wanting from the kernel log? The only relevant piece that I see in the log is attached to this bug as OopsText.txt.

I diffed the fs/ directory between stable kernel 3.19.3 and Ubuntu 3.19.0-11.11 last night and didn't see anything that stood out.

[Tyler Hicks (tyhicks)]

I've narrowed this down to some schroot sessions that were left open across a reboot. I believe that the trigger is the eCryptfs mount being propagated into the schroot sessions but I'm having trouble reproducing the BUG now.

[Tyler Hicks (tyhicks)]

It turns out that 3.19.3 stable is affected. The /etc/schroot/setup.d/10mount script has a bug in it that causes schroot sessions to not be restored when booting a non-Ubuntu kernel. After I manually fixed that bug, I was able to trigger the BUG on the 3.19.3 stable kernel.

To reproduce this issue, there needs to be two schroot sessions:

$ schroot -bn test1 -c vivid-amd64
$ schroot -bn test2 -c vivid-amd64

Reboot and attempt to log in as a used with an encrypted home directory to hit the BUG.

[Tyler Hicks (tyhicks)]

Now I can reproduce it on the v4.0-rc6-vivid mainline kernel build.

[Tyler Hicks (tyhicks)]

I've eliminated eCryptfs from the equation and can still trigger the BUG.

I set up the two schroot sessions and rebooted, as described in comment #9. Then I logged in as a user without an encrypted home and ran the following commands:

$ mkdir t
$ sudo mount -t tmpfs tmpfs t

That triggered the same BUG in propagate_one().