GPF in sidtab_context_to_sid

GPF in sidtab_context_to_sid

[Roberts, William C]

[-- Attachment #1: Type: text/plain, Size: 5335 bytes --]

I found a very similar oops online:
http://oops.kernel.org/oops/general-protection-fault-in-sidtab_context_to_sid/

Has anyone encountered this bug?

I had something reported to me very similar where the faulting instruction was:

0xffffffff8133c81e <+174>:   mov    0x14(%r12),%eax

Addr2line on vmlinux produced:
$ addr2line -f -e ./vmlinux ffffffff8133c81e
context_cmp
kernel/cht/security/selinux/ss/context.h:152

Actual Dump:

[131436.409639] general protection fault: 0000 [#1] PREEMPT SMP
[131436.416085] Modules linked in: tcp_diag inet_diag
atomisp_css2401a0_v21 videobuf_vmalloc videobuf_core bt_lpm
rfkill_gpio 8723bs(O) cfg80211 ov2680 ov8858_driver silead_ts ltr501
bmg160 ak09911 kxcjk_1013
[131436.436623] CPU: 3 PID: 3177 Comm: SettingsProvide Tainted: G
  W  O 3.14.70-x86_64-02246-g49319b8 #1
[131436.447500] Hardware name: XXX
CHTMRD.A6.002.016 09/20/2016
[131436.456542] task: ffff88006039cb30 ti: ffff88005e2ea000 task.ti:
ffff88005e2ea000
[131436.465000] RIP: 0010:[<ffffffff8133c81e>]
[131436.469579]  [<ffffffff8133c81e>] sidtab_context_to_sid+0xae/0x480
[131436.476783] RSP: 0018:ffff88005e2ebae0  EFLAGS: 00010286
[131436.482814] RAX: 00000000fff9f9f9 RBX: ffffffff82776540 RCX:
0000000000000000
[131436.490884] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
ffffffff82776540
[131436.498953] RBP: ffff88005e2ebb28 R08: ffff88005e2ebb88 R09:
0000000000000000
[131436.507022] R10: ffff88007826c000 R11: 2f2f2f2f2f2f2f2f R12:
fff9f9f9fff9f9f9
[131436.515091] R13: ffff88005e2ebba0 R14: ffff88005e2ebbb8 R15:
0000000000000068
[131436.523160] FS:  00000000d1efbe00(006b) GS:ffff880079380000(0063)
knlGS:00000000d1a77960
[131436.532297] CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
[131436.538813] CR2: 0000000072e67750 CR3: 000000005e1ba000 CR4:
00000000001007e0
[131436.546883] Last Branch Records:
[131436.550590]    to: [<ffffffff81aa9ac0>] general_protection+0x0/0x80
[131436.557700]  from: [<ffffffff8133c81e>] sidtab_context_to_sid+0xae/0x480
[131436.565292]    to: [<ffffffff8133c810>] sidtab_context_to_sid+0xa0/0x480
[131436.572885]  from: [<ffffffff8133c806>] sidtab_context_to_sid+0x96/0x480
[131436.580478]    to: [<ffffffff8133c800>] sidtab_context_to_sid+0x90/0x480
[131436.588070]  from: [<ffffffff8133c825>] sidtab_context_to_sid+0xb5/0x480
[131436.595662]    to: [<ffffffff8133c810>] sidtab_context_to_sid+0xa0/0x480
[131436.603255]  from: [<ffffffff8133c842>] sidtab_context_to_sid+0xd2/0x480
[131436.610847]    to: [<ffffffff8133c810>] sidtab_context_to_sid+0xa0/0x480
[131436.618439]  from: [<ffffffff8133c842>] sidtab_context_to_sid+0xd2/0x480
[131436.626031]    to: [<ffffffff8133c810>] sidtab_context_to_sid+0xa0/0x480
[131436.633624]  from: [<ffffffff8133c842>] sidtab_context_to_sid+0xd2/0x480
[131436.641216]    to: [<ffffffff8133c81e>] sidtab_context_to_sid+0xae/0x480
[131436.648810]  from: [<ffffffff8133c7ef>] sidtab_context_to_sid+0x7f/0x480
[131436.656401]    to: [<ffffffff8133c7e5>] sidtab_context_to_sid+0x75/0x480
[131436.663994]  from: [<ffffffff8133cabb>] sidtab_context_to_sid+0x34b/0x480
[131436.671684] Stack:
[131436.674023]  ffff88005e2ebb88 ffff88005e2ebb08 ffffffff8134938e
ffff88005e2ebc3c
[131436.682416]  0000000000000000 ffff88005e2ebb88 0000000000000010
ffff880060371ea8
[131436.690809]  ffff8800716d4968 ffff88005e2ebbf8 ffffffff8134372f
0000000600000000
[131436.699204] Call Trace:
[131436.702036]  [<ffffffff8134938e>] ? mls_context_isvalid+0x2e/0xb0
[131436.708944]  [<ffffffff8134372f>] security_compute_sid.part.10+0x43f/0x550
[131436.716727]  [<ffffffff81275d00>] ? search_dir+0x40/0x120
[131436.722851]  [<ffffffff8134388e>] security_compute_sid+0x4e/0x50
[131436.729660]  [<ffffffff81345d8d>] security_transition_sid+0x2d/0x40
[131436.736762]  [<ffffffff81330496>] may_create+0x96/0x100
[131436.742699]  [<ffffffff81330553>] selinux_inode_create+0x13/0x20
[131436.749509]  [<ffffffff8132bcef>] security_inode_create+0x1f/0x30
[131436.756417]  [<ffffffff811d146e>] vfs_create+0x8e/0x140
[131436.762353]  [<ffffffff811d1d01>] do_last+0x7e1/0x1210
[131436.768192]  [<ffffffff811cd71c>] ? link_path_walk+0x8c/0xfb0
[131436.774712]  [<ffffffff811ab3f1>] ? kmem_cache_alloc_trace+0xe1/0x1d0
[131436.782008]  [<ffffffff81333e4c>] ? selinux_file_alloc_security+0x3c/0x60
[131436.789692]  [<ffffffff811d27eb>] path_openat+0xbb/0x6d0
[131436.795724]  [<ffffffff811d0fb8>] ? SYSC_renameat+0xe8/0x3f0
[131436.802146]  [<ffffffff811d363a>] do_filp_open+0x3a/0xa0
[131436.808179]  [<ffffffff81aa8e78>] ? _raw_spin_unlock+0x18/0x40
[131436.814795]  [<ffffffff811e03b7>] ? __alloc_fd+0xa7/0x130
[131436.820925]  [<ffffffff811c090c>] do_sys_open+0x12c/0x220
[131436.827056]  [<ffffffff812176a1>] compat_SyS_openat+0x11/0x20
[131436.833574]  [<ffffffff81ab2f23>] sysenter_dispatch+0x7/0x1f
[131436.839997]  [<ffffffff8139b49b>] ? trace_hardirqs_on_thunk+0x3a/0x3c
[131436.847289] Code: 02 00 00 66 2e 0f 1f 84 00 00 00 00 00 41 8b 50
0c 85 d2 74 08 39 d0 0f 84 70 02 00 00 4d 8b 64 24 50 4d 85 e4 0f 84
92 02 00 00 <41> 8b 44 24 14 85 c0 75 d9 41 8b 48 0c 85 c9 75 e1 49 8b
00 49
[131436.869023] RIP
[131436.870977]  [<ffffffff8133c81e>] sidtab_context_to_sid+0xae/0x480
[131436.878180]  RSP <ffff88005e2ebae0>
[131436.882285] ---[ end trace 4c33bfa820f020fe ]---


[-- Attachment #2: Type: text/html, Size: 11405 bytes --]

Re: GPF in sidtab_context_to_sid

[Paul Moore]

On Tue, Nov 8, 2016 at 1:26 PM, Roberts, William C
<william.c.roberts@intel.com> wrote:
> I found a very similar oops online:
>
> http://oops.kernel.org/oops/general-protection-fault-in-sidtab_context_to_sid/
>
> Has anyone encountered this bug?
>
> I had something reported to me very similar where the faulting instruction
> was:
>
> 0xffffffff8133c81e <+174>:   mov    0x14(%r12),%eax
>
> Addr2line on vmlinux produced:
>
> $ addr2line -f -e ./vmlinux ffffffff8133c81e
> context_cmp
> kernel/cht/security/selinux/ss/context.h:152

I'm guessing you don't have a reproducer?

It looks like both these kernels are older (3.x), have you seen this
on anything recent?

-- 
paul moore
www.paul-moore.com

RE: GPF in sidtab_context_to_sid

[Roberts, William C]

> -----Original Message-----
> From: Paul Moore [mailto:paul@paul-moore.com]
> Sent: Tuesday, November 8, 2016 12:57 PM
> To: Roberts, William C <william.c.roberts@intel.com>
> Cc: selinux@tycho.nsa.gov
> Subject: Re: GPF in sidtab_context_to_sid
> 
> On Tue, Nov 8, 2016 at 1:26 PM, Roberts, William C <william.c.roberts@intel.com>
> wrote:
> > I found a very similar oops online:
> >
> > http://oops.kernel.org/oops/general-protection-fault-in-sidtab_context
> > _to_sid/
> >
> > Has anyone encountered this bug?
> >
> > I had something reported to me very similar where the faulting
> > instruction
> > was:
> >
> > 0xffffffff8133c81e <+174>:   mov    0x14(%r12),%eax
> >
> > Addr2line on vmlinux produced:
> >
> > $ addr2line -f -e ./vmlinux ffffffff8133c81e context_cmp
> > kernel/cht/security/selinux/ss/context.h:152
> 
> I'm guessing you don't have a reproducer?

Supposedly, I am digging that slowly out of the reporters. If I can use it to
reproduce, I'll let you know.

> 
> It looks like both these kernels are older (3.x), have you seen this on anything
> recent?

No.

> 
> --
> paul moore
> www.paul-moore.com