Bug 477220 – sys-kernel/gentoo-sources-3.10.1: Oops in CIFS security_socket_recvmsg

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Alex Brandt (RETIRED) 2013-07-17 14:55:17 UTC]

When attempting to run an rsync process over a CIFS share with gentoo-sources-3.10.1 I received the following Oops message.  I have not verified if this is duplicated in vanilla-sources yet but will when I get time.

Reproducible: Always

Steps to Reproduce:
1. Install gentoo-sources-3.10.1
2. Boot generated kernel
3. Mount (I used autofs) a CIFS share and read from said share
Actual Results:  
The following Oops message:

Jul 16 23:42:52 [kernel] [52376.581266] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
Jul 16 23:42:52 [kernel] [52376.581396] IP: [<ffffffff81374516>] selinux_socket_recvmsg+0x6/0x20
Jul 16 23:42:52 [kernel] [52376.581485] PGD 2a601c067 PUD 2a6088067 PMD 0 
Jul 16 23:42:52 [kernel] [52376.581553] Oops: 0000 [#1] PREEMPT SMP 
Jul 16 23:42:52 [kernel] [52376.581615] Modules linked in: xt_LOG tun vboxnetadp(O) vboxnetflt(O) vboxdrv(O) uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core snd_hda_codec_hdmi brcmsmac cordic brcmutil snd_hda_codec_idt b43 ssb snd_hda_intel snd_hda_codec snd_hwdep hp_accel lis3lv02d
Jul 16 23:42:52 [kernel] [52376.581971] CPU: 0 PID: 16594 Comm: cifsd Tainted: G           O 3.10.1-gentoo #1
Jul 16 23:42:52 [kernel] [52376.582064] Hardware name: Hewlett-Packard HP EliteBook 8460p/161C, BIOS 68SCF Ver. F.08 08/26/2011
Jul 16 23:42:52 [kernel] [52376.582163] task: ffff8803fee48e00 ti: ffff88018f354000 task.ti: ffff88018f354000
Jul 16 23:42:52 [kernel] [52376.582245] RIP: 0010:[<ffffffff81374516>]  [<ffffffff81374516>] selinux_socket_recvmsg+0x6/0x20
Jul 16 23:42:52 [kernel] [52376.582350] RSP: 0018:ffff88018f355b58  EFLAGS: 00010286
Jul 16 23:42:52 [kernel] [52376.582409] RAX: ffffffff81e530a0 RBX: ffff88018f355bf0 RCX: 0000000000000000
Jul 16 23:42:52 [kernel] [52376.582487] RDX: 0000000000000002 RSI: ffff88018f355d20 RDI: 0000000000000000
Jul 16 23:42:52 [kernel] [52376.582565] RBP: ffff88018f355b68 R08: 0000000000004058 R09: 0000000000000000
Jul 16 23:42:52 [kernel] [52376.582642] R10: 0000000000000001 R11: 0000000000000002 R12: 0000000000000000
Jul 16 23:42:52 [kernel] [52376.582720] R13: ffff88018f355d20 R14: 0000000000004058 R15: 0000000000000000
Jul 16 23:42:52 [kernel] [52376.582807] FS:  0000000000000000(0000) GS:ffff88043dc00000(0000) knlGS:0000000000000000
Jul 16 23:42:52 [kernel] [52376.582895] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jul 16 23:42:52 [kernel] [52376.582959] CR2: 0000000000000020 CR3: 00000002b9d80000 CR4: 00000000000427f0
Jul 16 23:42:52 [kernel] [52376.583036] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Jul 16 23:42:52 [kernel] [52376.583113] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Jul 16 23:42:52 [kernel] [52376.583189] Stack:
Jul 16 23:42:52 [kernel] [52376.583216]  ffff88018f355b68 ffffffff81371191 ffff88018f355cc8 ffffffff8170bf25
Jul 16 23:42:52 [kernel] [52376.583312]  ffffffff82061580 0000000000000282 ffff88018f355be8 ffff88018f355be8
Jul 16 23:42:52 [kernel] [52376.583408]  ffff88018f355bb8 ffffffff8108dfb2 ffff88018f355bb8 ffffffff82061580
Jul 16 23:42:52 [kernel] [52376.583514] Call Trace:
Jul 16 23:42:52 [kernel] [52376.583553]  [<ffffffff81371191>] ? security_socket_recvmsg+0x11/0x20
Jul 16 23:42:52 [kernel] [52376.583630]  [<ffffffff8170bf25>] sock_recvmsg+0x75/0xe0
Jul 16 23:42:52 [kernel] [52376.583694]  [<ffffffff8108dfb2>] ? del_timer_sync+0x52/0x60
Jul 16 23:42:52 [kernel] [52376.583761]  [<ffffffff818f1122>] ? schedule_timeout+0x152/0x2f0
Jul 16 23:42:52 [kernel] [52376.583835]  [<ffffffff8170c10e>] kernel_recvmsg+0x3e/0x50
Jul 16 23:42:52 [kernel] [52376.583901]  [<ffffffff8127375b>] cifs_readv_from_socket+0x15b/0x270
Jul 16 23:42:52 [kernel] [52376.583977]  [<ffffffff81273892>] cifs_read_from_socket+0x22/0x30
Jul 16 23:42:52 [kernel] [52376.584047]  [<ffffffff812678a9>] cifs_readv_discard+0x69/0xa0
Jul 16 23:42:52 [kernel] [52376.584115]  [<ffffffff812679cb>] cifs_readv_receive+0xeb/0x3c0
Jul 16 23:42:52 [kernel] [52376.584194]  [<ffffffff81273a93>] cifs_demultiplex_thread+0x193/0x8e0
Jul 16 23:42:52 [kernel] [52376.584269]  [<ffffffff81273900>] ? dequeue_mid+0x60/0x60
Jul 16 23:42:52 [kernel] [52376.584334]  [<ffffffff810a29cb>] kthread+0xbb/0xc0
Jul 16 23:42:52 [kernel] [52376.584393]  [<ffffffff810a2910>] ? kthread_create_on_node+0x130/0x130
Jul 16 23:42:52 [kernel] [52376.584470]  [<ffffffff818f536c>] ret_from_fork+0x7c/0xb0
Jul 16 23:42:52 [kernel] [52376.584533]  [<ffffffff810a2910>] ? kthread_create_on_node+0x130/0x130
Jul 16 23:42:52 [kernel] [52376.584604] Code: fe ff ff 5d c3 55 ba 10 00 00 00 48 8b 77 20 48 89 e5 65 48 8b 04 25 00 b9 00 00 48 89 c7 e8 b2 fe ff ff 5d c3 55 ba 02 00 00 00 <48> 8b 77 20 48 89 e5 65 48 8b 04 25 00 b9 00 00 48 89 c7 e8 92 
Jul 16 23:42:52 [kernel] [52376.585138] RIP  [<ffffffff81374516>] selinux_socket_recvmsg+0x6/0x20
Jul 16 23:42:52 [kernel] [52376.585218]  RSP <ffff88018f355b58>
Jul 16 23:42:52 [kernel] [52376.585259] CR2: 0000000000000020
Jul 16 23:42:52 [kernel] [52376.599398] ---[ end trace a9c1e79954f8412b ]---


Expected Results:  
Correct read of the CIFS share.

I'll also be attaching my kernel configuration in case there are obvious problems with that causing this behavior.

[Comment 1 Alex Brandt (RETIRED) 2013-07-17 14:55:55 UTC]

Created attachment 353500 [details]
Kernel Configuration

[Comment 2 Mike Pagano 2013-07-17 17:56:29 UTC]

Last working kernel?
If you know the last working kernel, would you be able to do a git-bisect?
Would you be able to recompile with some debug settings and recreate?

[Comment 3 Alex Brandt (RETIRED) 2013-07-18 01:16:47 UTC]

Last known working kernel was 3.9.7.  I've not been running this process through the 3.9.8 and 3.10.0 updates.  I can give those kernels a go if you think it'd be useful (I assume yes).

I don't have time to do a git-bisect on my kernel right now but perhaps after next week I could (if we still need it).

I certainly can add some debugging statements and recreate the issue.  Any debugging settings in particular that I should enable?  Otherwise, I can just enable debugging in CIFS systems and see what else pops up.

[Comment 4 Alex Brandt (RETIRED) 2013-07-18 14:17:37 UTC]

I tested the kernel from gentoo-sources-3.10.0 last night and no Oops occurred with that kernel.  The process that caused the Oops on 3.10.1 ran without any problems.

Narrows down where the bisect needs to happen anyway.  Do you prefer bisects against upstream vanilla or another branch?

[Comment 5 Mike Pagano 2013-07-25 13:33:15 UTC]

vanilla

[Comment 6 Alex Brandt (RETIRED) 2013-07-31 15:33:59 UTC]

Looks like this no longer occurs as of 3.10.3-gentoo-r1.  Do we still want to track down the particular commit causing the issue or simply notate the as yet unstable kernels to not go stable?

[Comment 7 Tom Wijsman (TomWij) (RETIRED) 2013-08-06 17:19:03 UTC]

(In reply to Alex Brandt from comment #6)
> Looks like this no longer occurs as of 3.10.3-gentoo-r1.  Do we still want
> to track down the particular commit causing the issue or simply notate the
> as yet unstable kernels to not go stable?

The stabilization bug for 3.9 is currently blocked; which kernel we want to end up stabilizing might end up being decided in bug #478006, based on that decision we can then see whether to go through with your bisect or not.

[Comment 8 Tom Wijsman (TomWij) (RETIRED) 2013-08-12 17:23:56 UTC]

We plan to stabilize the next 3.10 release.