BUG: unable to handle kernel NULL pointer dereference at 0000000000000010

Bug #1439849 reported by Tyler Hicks
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
In Progress
High
Tyler Hicks

Bug Description

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

Revision history for this message
Tyler Hicks (tyhicks) wrote :
Revision history for this message
Brad Figg (brad-figg) wrote : Status changed to Confirmed

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
tags: removed: need-duplicate-check
Tyler Hicks (tyhicks)
description: updated
Revision history for this message
Tyler Hicks (tyhicks) wrote :

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.

Revision history for this message
Tyler Hicks (tyhicks) wrote :

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

Revision history for this message
Tyler Hicks (tyhicks) wrote :

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??

Revision history for this message
Chris J Arges (arges) wrote :

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.

tags: added: kernel-key
Revision history for this message
Tyler Hicks (tyhicks) wrote :

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.

Revision history for this message
Tyler Hicks (tyhicks) wrote :

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.

Changed in linux (Ubuntu):
assignee: nobody → Tyler Hicks (tyhicks)
importance: Critical → High
status: Confirmed → In Progress
Revision history for this message
Tyler Hicks (tyhicks) wrote :

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.

Revision history for this message
Tyler Hicks (tyhicks) wrote :

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

Revision history for this message
Tyler Hicks (tyhicks) wrote :

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().

penalvch (penalvch)
tags: added: kernel-fixed-upstream kernel-fixed-upstream-4.0-rc6
tags: added: kernel-bug-exists-upstream kernel-bug-exists-upstream-4.0-rc6
removed: kernel-fixed-upstream kernel-fixed-upstream-4.0-rc6
tags: added: bios-outdated-1.39
tags: added: kernel-da-key
removed: kernel-key
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.