Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 446326 - =sys-kernel/hardened-sources-3.6.8 - unable to handle kernel NULL pointer dereference - vsftpd copy_process+0x7ec/0x1110
Summary: =sys-kernel/hardened-sources-3.6.8 - unable to handle kernel NULL pointer der...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: The Gentoo Linux Hardened Kernel Team (OBSOLETE)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-12-07 07:47 UTC by Alexey
Modified: 2013-09-27 11:06 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
kernel-config (kernel-config.txt,54.81 KB, text/plain)
2012-12-07 10:50 UTC, Alexey
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexey 2012-12-07 07:47:07 UTC
Gave a crash kernel after upgrade from 3.6.2 to 3.6.8 error "kernel: BUG: unable to handle kernel NULL pointer dereference"

Reproducible: Sometimes

Steps to Reproduce:
1. Compile sys-kernel/hardened-sources-3.6.8
2. Install kernel to /boot
3. Reboor
Two hours later, the kernel failed, but continued to work



Today log crash:

Dec  7 03:25:01 viva kernel: BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
Dec  7 03:25:01 viva kernel: IP: [<ffffffff810336d3>] dup_mm+0x243/0x420
Dec  7 03:25:01 viva kernel: PGD 0
Dec  7 03:25:01 viva kernel: Oops: 0000 [#1] SMP
Dec  7 03:25:01 viva kernel: CPU 0
Dec  7 03:25:01 viva kernel: Pid: 1992, comm: vsftpd Not tainted 3.6.8-homeweb #2 Supermicro X7DVL/X7DVL
Dec  7 03:25:01 viva kernel: RIP: 0010:[<ffffffff810336d3>]  [<ffffffff810336d3>] dup_mm+0x243/0x420
Dec  7 03:25:01 viva kernel: RSP: 0018:ffff8805f2defdc0  EFLAGS: 00010286
Dec  7 03:25:01 viva kernel: RAX: 0000000000000000 RBX: ffff880611c0f000 RCX: 0000000000000000
Dec  7 03:25:01 viva kernel: RDX: ffff8805f335ee00 RSI: ffff8805f3200370 RDI: ffff8805f33d4210
Dec  7 03:25:01 viva kernel: RBP: ffff880611c08000 R08: ffffffff81033664 R09: 000000000049ec33
Dec  7 03:25:01 viva kernel: R10: 0000000000001502 R11: 0000000000000000 R12: ffff8805f3200370
Dec  7 03:25:01 viva kernel: R13: ffff8805f33d4210 R14: ffff880611c0f000 R15: ffff880611c0f060
Dec  7 03:25:01 viva kernel: FS:  000064f8d2615700(0000) GS:ffff88062fc00000(0000) knlGS:0000000000000000
Dec  7 03:25:01 viva kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Dec  7 03:25:01 viva kernel: CR2: 0000000000000030 CR3: 00000005f2e75000 CR4: 00000000000407f0
Dec  7 03:25:01 viva kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Dec  7 03:25:01 viva kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Dec  7 03:25:01 viva kernel: Process vsftpd (pid: 1992, threadinfo ffff880610f483f0, task ffff880610f48000)
Dec  7 03:25:01 viva kernel: Stack:
Dec  7 03:25:01 viva kernel: ffff8805f2defe6c 0000000000000000 ffff880611c08060 0000000000000000
Dec  7 03:25:01 viva kernel: ffff880611c0f008 0000000000000000 ffff8805f2fe0000 0000000001200011
Dec  7 03:25:01 viva kernel: ffff8805f2fe0000 0000000000000000 000064f8d26159d0 0000000000000000
Dec  7 03:25:01 viva kernel: Call Trace:
Dec  7 03:25:01 viva kernel: [<ffffffff810340cc>] ? copy_process+0x7ec/0x1110
Dec  7 03:25:01 viva kernel: [<ffffffff81255169>] ? gr_attach_curr_ip+0xa9/0x130
Dec  7 03:25:01 viva kernel: [<ffffffff81034aca>] ? do_fork+0xaa/0x2f0
Dec  7 03:25:01 viva kernel: [<ffffffff8103b4e2>] ? sys_wait4+0xa2/0x100
Dec  7 03:25:01 viva kernel: [<ffffffff814bf803>] ? stub_clone+0x13/0x20
Dec  7 03:25:01 viva kernel: [<ffffffff814bf580>] ? system_call_fastpath+0x18/0x1d
Dec  7 03:25:01 viva kernel: Code: 49 8b 95 98 00 00 00 49 c7 45 20 00 00 00 00 49 c7 45 18 00 00 00 00 49 c7 85 a8 00 00 00 00 00 00 00 48 85 d2 74 5a 48 8b 42 18 <48> 8b 48 30 48 8b 82 c8 00 00 00 f0 48 ff 42 30 41 f6 45 31 08
Dec  7 03:25:01 viva kernel: RIP  [<ffffffff810336d3>] dup_mm+0x243/0x420
Dec  7 03:25:01 viva kernel: RSP <ffff8805f2defdc0>
Dec  7 03:25:01 viva kernel: CR2: 0000000000000030
Dec  7 03:25:01 viva kernel: ---[ end trace cdb149c9f3b103e9 ]---


Linux viva 3.6.8-hardened #3 SMP
x86_64
2xIntel(R) Xeon(R) CPU L5420 @ 2.50GHz GenuineIntel GNU/Linux
24 Gb RAM
Comment 1 Alexey 2012-12-07 10:50:42 UTC
Created attachment 331726 [details]
kernel-config
Comment 2 Anthony Basile gentoo-dev 2012-12-23 13:26:35 UTC
(In reply to comment #1)
> Created attachment 331726 [details]
> kernel-config

I think this is a known issue which is why 3.8.6 is off the tree.  Can you test 3.7.0 and see if you still hit this.  I'm guessing its gone.
Comment 3 Jaak Ristioja 2012-12-26 10:44:18 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > Created attachment 331726 [details]
> > kernel-config
> 
> I think this is a known issue which is why 3.8.6 is off the tree.  Can you
> test 3.7.0 and see if you still hit this.  I'm guessing its gone.

Could you please provide more information (or a link) about why 3.6.8 is off the tree? Thanks!
Comment 4 Anthony Basile gentoo-dev 2013-01-22 13:35:44 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > Created attachment 331726 [details]
> > > kernel-config
> > 
> > I think this is a known issue which is why 3.8.6 is off the tree.  Can you
> > test 3.7.0 and see if you still hit this.  I'm guessing its gone.
> 
> Could you please provide more information (or a link) about why 3.6.8 is off
> the tree? Thanks!

Can you test with hardened-sources-3.7.3 and see if this is gone.
Comment 5 Anthony Basile gentoo-dev 2013-06-24 21:27:58 UTC
I just marked 2.6.32-r170, 3.2.46-r1, 3.9.5 stable.  Please test and if this is still an issue reopen.
Comment 6 Jaak Ristioja 2013-06-25 05:37:11 UTC
(In reply to Anthony Basile from comment #5)
> I just marked 2.6.32-r170, 3.2.46-r1, 3.9.5 stable.  Please test and if this
> is still an issue reopen.

Can you still please explain and give us a reference about why you think this has been fixed in more recent versions of hardened-sources?
Comment 7 Anthony Basile gentoo-dev 2013-06-25 10:27:51 UTC
(In reply to Jaak Ristioja from comment #6)
> (In reply to Anthony Basile from comment #5)
> > I just marked 2.6.32-r170, 3.2.46-r1, 3.9.5 stable.  Please test and if this
> > is still an issue reopen.
> 
> Can you still please explain and give us a reference about why you think
> this has been fixed in more recent versions of hardened-sources?

There are 3 sources to this kernel: vanilla, genpatches and grsec patches.  At any given time there are issues with each source causing forward pressure eg right now the 3.8 series is not supported by grsec (look at their site https://grsecurity.net/download_stable.php) and vanilla says don't use anything before 3.8.13. (google for the multiple reasons).

Furthermore, grsec/pax team wants to look at their most recent releases.

There is no fix to this.  I've reopened and I'm cc-ing upstream.  They'll probably want to you to look at 3.9.7 which I just added to the tree.
Comment 8 PaX Team 2013-06-25 13:44:25 UTC
yeah, we'd like to know if this is something reproducible on more recent kernels that we support.
Comment 9 Anthony Basile gentoo-dev 2013-06-25 16:28:27 UTC
(In reply to Jaak Ristioja from comment #6)
> (In reply to Anthony Basile from comment #5)
> > I just marked 2.6.32-r170, 3.2.46-r1, 3.9.5 stable.  Please test and if this
> > is still an issue reopen.
> 
> Can you still please explain and give us a reference about why you think
> this has been fixed in more recent versions of hardened-sources?

To answer your question more directly, I don't remember the details but at the time I had reports in IRC that 3.6.8 hit a NULL pointer deref.  It may have been prometheanfire that told me.  This was not reported again upon update to later 3.8.x's.
Comment 10 PaX Team 2013-06-25 20:33:15 UTC
this was a refcounting bug in some vma->exec_file or similar accounting in grsec that could lead to NULL derefs and was fixed quickly at the time.
Comment 11 Anthony Basile gentoo-dev 2013-09-27 11:06:58 UTC
(In reply to PaX Team from comment #10)
> this was a refcounting bug in some vma->exec_file or similar accounting in
> grsec that could lead to NULL derefs and was fixed quickly at the time.

@reporter.  I'm going to assume following upstream's comment that this bug is gone.  Please reopen if you still hit it with the more recent hardened sources on the tree.