From: Vasiliy Kulikov <segoon@openwall.com>
To: "Przemysław Pawełczyk" <przemyslaw@pawelczyk.it>
Cc: lkml <linux-kernel@vger.kernel.org>,
akpm@linux-foundation.org, Oleg Nesterov <oleg@redhat.com>
Subject: Re: [BUG] task->nsproxy was unexpectedly NULL (caught in exit_shm)
Date: Sat, 18 Feb 2012 21:39:50 +0400 [thread overview]
Message-ID: <20120218173950.GA12595@albatros> (raw)
In-Reply-To: <CAN8=baycwqAkTJxNpNzaO9G=TbEXeiEYCvWxiwvS+NpLRZi3xw@mail.gmail.com>
Hi Przemysław,
Thank you for the report!
(CC'ed Andrew and Oleg, overquoting for them the whole email)
On Sat, Feb 18, 2012 at 17:57 +0100, Przemysław Pawełczyk wrote:
> Hello.
>
> Below bug hit me today when I closed one of many tabs in Chrome.
> The kernel is from debian wheezy current kernel package:
> linux-image-3.2.0-1-amd64 (v3.2.4).
>
>
> Feb 18 11:28:38 debian kernel: [ 3392.815292] BUG: unable to handle
> kernel NULL pointer dereference at 0000000000000010
> Feb 18 11:28:38 debian kernel: [ 3392.815309] IP: [<ffffffff811581c3>]
> exit_shm+0xa/0x54
> Feb 18 11:28:38 debian kernel: [ 3392.815325] PGD 0
> Feb 18 11:28:38 debian kernel: [ 3392.815331] Oops: 0000 [#1] SMP
> Feb 18 11:28:38 debian kernel: [ 3392.815340] CPU 0
> Feb 18 11:28:38 debian kernel: [ 3392.815343] Modules linked in:
> pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) powernow_k8
> mperf cpufreq_stats cpufreq_conservative cpufreq_userspace
> cpufreq_powersave parport_pc ppdev lp parport binfmt_misc nfsd nfs
> lockd fscache auth_rpcgss nfs_acl sunrpc kvm_amd kvm fuse ext2 loop
> snd_hda_codec_hdmi nvidia(P) snd_hda_intel snd_hda_codec snd_intel8x0
> snd_hwdep snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm
> snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer
> snd_seq_device snd k8temp pcspkr edac_core edac_mce_amd soundcore
> evdev snd_page_alloc i2c_nforce2 i2c_core processor button ext3 jbd
> mbcache btrfs zlib_deflate crc32c libcrc32c dm_mirror dm_region_hash
> dm_log dm_mod usbhid hid sr_mod cdrom sd_mod crc_t10dif ohci_hcd
> ata_generic ahci pata_amd libahci pata_jmicron sata_nv thermal fan
> thermal_sys floppy ehci_hcd libata usbcore scsi_mod forcedeth
> usb_common [last unloaded: scs i_wait_scan]
> Feb 18 11:28:38 debian kernel: [ 3392.815476]
> Feb 18 11:28:38 debian kernel: [ 3392.815483] Pid: 3806, comm: chrome
> Tainted: P O 3.2.0-1-amd64 #1 Unknow Unknow/KN9
> Series(NF-CK804)
> Feb 18 11:28:38 debian kernel: [ 3392.815493] RIP:
> 0010:[<ffffffff811581c3>] [<ffffffff811581c3>] exit_shm+0xa/0x54
> Feb 18 11:28:38 debian kernel: [ 3392.815504] RSP:
> 0018:ffff88012de61ce8 EFLAGS: 00010292
> Feb 18 11:28:38 debian kernel: [ 3392.815509] RAX: 0000000000000000
> RBX: ffff880130264300 RCX: 0000000000000008
> Feb 18 11:28:38 debian kernel: [ 3392.815515] RDX: ffff88012e3b28c0
> RSI: ffff88010ef96480 RDI: ffff880130264300
> Feb 18 11:28:38 debian kernel: [ 3392.815520] RBP: 000000000000000f
> R08: ffff88012c4a3818 R09: ffff88012c4a38c8
> Feb 18 11:28:38 debian kernel: [ 3392.815526] R10: ffff88012c4a3a28
> R11: ffff88010ef96480 R12: ffff88010ef96480
> Feb 18 11:28:38 debian kernel: [ 3392.815531] R13: ffff88012fc56600
> R14: 0000000000000001 R15: 000000000000413c
> Feb 18 11:28:38 debian kernel: [ 3392.815538] FS:
> 00007f7610f2f700(0000) GS:ffff880137c00000(0000)
> knlGS:0000000000000000
> Feb 18 11:28:38 debian kernel: [ 3392.815544] CS: 0010 DS: 0000 ES:
> 0000 CR0: 000000008005003b
> Feb 18 11:28:38 debian kernel: [ 3392.815549] CR2: 0000000000000010
> CR3: 000000012e479000 CR4: 00000000000006f0
> Feb 18 11:28:38 debian kernel: [ 3392.815556] DR0: 0000000000000000
> DR1: 0000000000000000 DR2: 0000000000000000
> Feb 18 11:28:38 debian kernel: [ 3392.815561] DR3: 0000000000000000
> DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Feb 18 11:28:38 debian kernel: [ 3392.815568] Process chrome (pid:
> 3806, threadinfo ffff88012de60000, task ffff880131264300)
> Feb 18 11:28:38 debian kernel: [ 3392.815572] Stack:
> Feb 18 11:28:38 debian kernel: [ 3392.815576] 0000000000000000
> ffff880130264300 000000000000000f ffffffff81049af5
> Feb 18 11:28:38 debian kernel: [ 3392.815585] 000000000000192a
> ffff88012de61d08 ffff880131264300 ffffffff817a8508
> Feb 18 11:28:38 debian kernel: [ 3392.815594] 00007f7610f2e000
> ffff88010ef96480 0000000000000944 000000000000000f
> Feb 18 11:28:38 debian kernel: [ 3392.815604] Call Trace:
> Feb 18 11:28:38 debian kernel: [ 3392.815616] [<ffffffff81049af5>] ?
> do_exit+0x28b/0x732
> Feb 18 11:28:38 debian kernel: [ 3392.815626] [<ffffffff8104a21c>] ?
> do_group_exit+0x74/0x9e
> Feb 18 11:28:38 debian kernel: [ 3392.815635] [<ffffffff81055b5b>] ?
> get_signal_to_deliver+0x46d/0x48f
> Feb 18 11:28:38 debian kernel: [ 3392.815644] [<ffffffff810cff30>] ?
> handle_pte_fault+0x739/0x79f
> Feb 18 11:28:38 debian kernel: [ 3392.815655] [<ffffffff8100ddd3>] ?
> do_signal+0x38/0x610
> Feb 18 11:28:38 debian kernel: [ 3392.815663] [<ffffffff81037e98>] ?
> set_next_entity+0x32/0x55
> Feb 18 11:28:38 debian kernel: [ 3392.815672] [<ffffffff8100d01d>] ?
> paravirt_write_msr+0xb/0xe
> Feb 18 11:28:38 debian kernel: [ 3392.815679] [<ffffffff8100d694>] ?
> __switch_to+0x138/0x20e
> Feb 18 11:28:38 debian kernel: [ 3392.815690] [<ffffffff8106f2dc>] ?
> sys_futex+0x138/0x148
> Feb 18 11:28:38 debian kernel: [ 3392.815698] [<ffffffff8100e3e1>] ?
> do_notify_resume+0x25/0x68
> Feb 18 11:28:38 debian kernel: [ 3392.815707] [<ffffffff813459e0>] ?
> int_signal+0x12/0x17
> Feb 18 11:28:38 debian kernel: [ 3392.815713] Code: 48 8d bd c0 00 00
> 00 48 89 ea 48 c7 c6 b8 7e 15 81 e8 e9 f6 04 00 48 89 df 5b 5b 5d e9
> e9 a7 f0 ff 55 53 50 48 8b 87 78 04 00 00 <48> 8b 68 10 83 bd 98 00 00
> 00 00 74 39 48 8d 9d a0 00 00 00 48
> Feb 18 11:28:38 debian kernel: [ 3392.815783] RIP
> [<ffffffff811581c3>] exit_shm+0xa/0x54
> Feb 18 11:28:38 debian kernel: [ 3392.815792] RSP <ffff88012de61ce8>
> Feb 18 11:28:38 debian kernel: [ 3392.815795] CR2: 0000000000000010
> Feb 18 11:28:38 debian kernel: [ 3392.815801] ---[ end trace
> 1bd7e5ff0e6f1b66 ]---
> Feb 18 11:28:38 debian kernel: [ 3392.815807] Fixing recursive fault
> but reboot is needed!
>
>
> Relevant code:
>
>
> void exit_shm(struct task_struct *task)
>
> 311 {
> 0xffffffff811581b9 <+0>: 55 push %rbp
> 0xffffffff811581ba <+1>: 53 push %rbx
> 0xffffffff811581bb <+2>: 50 push %rax
>
> 312 struct ipc_namespace *ns = task->nsproxy->ipc_ns;
> 0xffffffff811581bc <+3>: 48 8b 87 78 04 00 00 mov
> 0x478(%rdi),%rax /* task->nsproxy */
> 0xffffffff811581c3 <+10>: 48 8b 68 10 mov
> 0x10(%rax),%rbp /* ->ipc_ns */
>
> 313
> 314 if (shm_ids(ns).in_use == 0)
> 0xffffffff811581c7 <+14>: 83 bd 98 00 00 00 00 cmpl $0x0,0x98(%rbp)
> 0xffffffff811581ce <+21>: 74 39 je
> 0xffffffff81158209 <exit_shm+80>
>
> 315 return;
> 316
> 317 /* Destroy all already created segments, but not mapped yet */
> 318 down_write(&shm_ids(ns).rw_mutex);
> 0xffffffff811581d0 <+23>: 48 8d 9d a0 00 00 00 lea 0xa0(%rbp),%rbx
> 0xffffffff811581d7 <+30>: 48 89 df mov %rbx,%rdi
> 0xffffffff811581da <+33>: e8 08 7e 1e 00 callq
> 0xffffffff8133ffe7 <down_write>
> ...
>
>
> So task->nsproxy was unexpectedly NULL atm.
> The bug happened only once so far.
I'm confused. How ->nsproxy can be NULL in do_exit()? AFAIU, it is not a
special process (i.e. init or udev), but a common chrome process.
Could it be missing get_nsproxy() somewhere? And as a result, freed
current->nsproxy while still having active users.
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
next prev parent reply other threads:[~2012-02-18 17:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-18 16:57 [BUG] task->nsproxy was unexpectedly NULL (caught in exit_shm) Przemysław Pawełczyk
2012-02-18 17:39 ` Vasiliy Kulikov [this message]
2012-02-18 18:24 ` Cyrill Gorcunov
2012-02-19 19:40 ` Przemysław Pawełczyk
2012-02-19 20:19 ` Cyrill Gorcunov
2012-02-19 20:40 ` Vasiliy Kulikov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120218173950.GA12595@albatros \
--to=segoon@openwall.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=przemyslaw@pawelczyk.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.