From: Stephen Smalley <sds@tycho.nsa.gov>
To: Paul Moore <paul@paul-moore.com>,
selinux@tycho.nsa.gov, mthode@mthode.org
Subject: Re: file access causes a kernel bug
Date: Wed, 29 Jan 2014 09:07:46 -0500 [thread overview]
Message-ID: <52E90B32.5010404@tycho.nsa.gov> (raw)
In-Reply-To: <1621615.vHn06J0duj@sifl>
On 01/29/2014 08:55 AM, Paul Moore wrote:
> On Wednesday, January 29, 2014 02:11:45 AM Matthew Thode wrote:
>> On 01/29/2014 02:04 AM, Matthew Thode wrote:
>>> This happens consistantly, just ls a particular dir and wheeeeee.
>>>
>>> [ 473.893141] ------------[ cut here ]------------
>>> [ 473.962110] kernel BUG at security/selinux/ss/services.c:654!
>>> [ 473.995314] invalid opcode: 0000 [#6] SMP
>>> [ 474.027196] Modules linked in:
>>> [ 474.058118] CPU: 0 PID: 8138 Comm: ls Tainted: G D I
>>> 3.13.0-grsec #1
>>> [ 474.116637] Hardware name: Supermicro X8ST3/X8ST3, BIOS 2.0
>>> 07/29/10
>>> [ 474.149768] task: ffff8805f50cd010 ti: ffff8805f50cd488 task.ti:
>>> ffff8805f50cd488
>>> [ 474.183707] RIP: 0010:[<ffffffff814681c7>] [<ffffffff814681c7>]
>>> context_struct_compute_av+0xce/0x308
>>> [ 474.219954] RSP: 0018:ffff8805c0ac3c38 EFLAGS: 00010246
>>> [ 474.252253] RAX: 0000000000000000 RBX: ffff8805c0ac3d94 RCX:
>>> 0000000000000100
>>> [ 474.287018] RDX: ffff8805e8aac000 RSI: 00000000ffffffff RDI:
>>> ffff8805e8aaa000
>>> [ 474.321199] RBP: ffff8805c0ac3cb8 R08: 0000000000000010 R09:
>>> 0000000000000006
>>> [ 474.357446] R10: 0000000000000000 R11: ffff8805c567a000 R12:
>>> 0000000000000006
>>> [ 474.419191] R13: ffff8805c2b74e88 R14: 00000000000001da R15:
>>> 0000000000000000
>>> [ 474.453816] FS: 00007f2e75220800(0000) GS:ffff88061fc00000(0000)
>>> knlGS:0000000000000000
>>> [ 474.489254] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>> [ 474.522215] CR2: 00007f2e74716090 CR3: 00000005c085e000 CR4:
>>> 00000000000207f0
>>> [ 474.556058] Stack:
>>> [ 474.584325] ffff8805c0ac3c98 ffffffff811b549b ffff8805c0ac3c98
>>> ffff8805f1190a40
>>> [ 474.618913] ffff8805a6202f08 ffff8805c2b74e88 00068800d0464990
>>> ffff8805e8aac860
>>> [ 474.653955] ffff8805c0ac3cb8 000700068113833a ffff880606c75060
>>> ffff8805c0ac3d94
>>> [ 474.690461] Call Trace:
>>> [ 474.723779] [<ffffffff811b549b>] ? lookup_fast+0x1cd/0x22a
>>> [ 474.778049] [<ffffffff81468824>] security_compute_av+0xf4/0x20b
>>> [ 474.811398] [<ffffffff8196f419>] avc_compute_av+0x2a/0x179
>>> [ 474.843813] [<ffffffff8145727b>] avc_has_perm+0x45/0xf4
>>> [ 474.875694] [<ffffffff81457d0e>] inode_has_perm+0x2a/0x31
>>> [ 474.907370] [<ffffffff81457e76>] selinux_inode_getattr+0x3c/0x3e
>>> [ 474.938726] [<ffffffff81455cf6>] security_inode_getattr+0x1b/0x22
>>> [ 474.970036] [<ffffffff811b057d>] vfs_getattr+0x19/0x2d
>>> [ 475.000618] [<ffffffff811b05e5>] vfs_fstatat+0x54/0x91
>>> [ 475.030402] [<ffffffff811b063b>] vfs_lstat+0x19/0x1b
>>> [ 475.061097] [<ffffffff811b077e>] SyS_newlstat+0x15/0x30
>>> [ 475.094595] [<ffffffff8113c5c1>] ? __audit_syscall_entry+0xa1/0xc3
>>> [ 475.148405] [<ffffffff8197791e>] system_call_fastpath+0x16/0x1b
>>> [ 475.179201] Code: 00 48 85 c0 48 89 45 b8 75 02 0f 0b 48 8b 45 a0 48
>>> 8b 3d 45 d0 b6 00 8b 40 08 89 c6 ff ce e8 d1 b0 06 00 48 85 c0 49 89 c7
>>> 75 02 <0f> 0b 48 8b 45 b8 4c 8b 28 eb 1e 49 8d 7d 08 be 80 01 00 00 e8
>>> [ 475.255884] RIP [<ffffffff814681c7>]
>>> context_struct_compute_av+0xce/0x308
>>> [ 475.296120] RSP <ffff8805c0ac3c38>
>>> [ 475.328734] ---[ end trace f076482e9d754adc ]---
>>>
>>
>> sorry, forgot to add, this is for 3.13.0 as well.
>>
>> ls ./.config/ipython/profile_default/
>> Segmentation fault
>
> Thanks for passing this along, but can you elaborate a bit more on this?
> Distribution? Kernel package? SELinux policy? Any unusual configuration?
> etc.
>
> I ask because I'm not seeing this problem on my system and it seems like a
> fairly basic thing to be broken; if there was an issue with 'ls' on 3.13 I
> expect we would be flooded with angry users right now ...
Does it happen on any filesystem other than ZFS?
Do you have any prior SELinux output leading up to this bug?
next prev parent reply other threads:[~2014-01-29 14:07 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-29 8:04 file access causes a kernel bug Matthew Thode
2014-01-29 8:11 ` Matthew Thode
2014-01-29 13:55 ` Paul Moore
2014-01-29 14:07 ` Stephen Smalley [this message]
2014-01-29 14:17 ` Stephen Smalley
2014-01-29 16:58 ` Matthew Thode
2014-01-29 21:36 ` Stephen Smalley
2014-01-29 22:35 ` Brian Behlendorf
2014-01-29 22:39 ` Richard Yao
2014-01-30 8:20 ` Matthew Thode
2014-01-30 13:43 ` Stephen Smalley
2014-01-30 15:38 ` Matthew Thode
2014-01-30 15:45 ` Stephen Smalley
2014-01-30 15:51 ` Matthew Thode
2014-01-30 16:41 ` Stephen Smalley
2014-01-30 17:07 ` Matthew Thode
2014-01-30 17:19 ` Paul Moore
2014-01-30 17:35 ` Matthew Thode
2014-01-30 19:19 ` Paul Moore
2014-02-04 3:41 ` Per Nystrom
2014-02-05 17:15 ` Matthew Thode
2014-02-05 17:18 ` Paul Moore
2014-01-30 17:27 ` Richard Yao
2014-01-30 18:10 ` Stephen Smalley
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=52E90B32.5010404@tycho.nsa.gov \
--to=sds@tycho.nsa.gov \
--cc=mthode@mthode.org \
--cc=paul@paul-moore.com \
--cc=selinux@tycho.nsa.gov \
/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.