Bug 204848
| Summary: | Mount NFSv4 cause a OOPS in the SELinux code | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Steve Dickson <steved> |
| Component: | kernel | Assignee: | Eric Paris <eparis> |
| Status: | CLOSED RAWHIDE | QA Contact: | Brian Brock <bbrock> |
| Severity: | urgent | Docs Contact: | |
| Priority: | urgent | ||
| Version: | rawhide | CC: | dwalsh, jmorris, sgrubb, wtogami |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-09-26 19:08:14 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 150224, 205790 | ||
| Attachments: | |||
Created attachment 135334 [details]
Patch that detects a NULL sk pointer but does not solve the problem
I was under the impression that all struct sock would be created from sk_alloc which unconditionally allocats the sk_security. So getting null here is really quite surprising. I am able to reproduce and am looking at this bug now. i'm starting to think the issue is in rpc_mkpipe where we create an inode which passes I_ISSOCK() but I don't think has an sk or sk->sk_security If this kernel ever finishes building I'll add some insturmentation to find out if my hunch is right I do see that path.... so the question is what does rpc_get_inode() to call when the S_IFSOCK mod is set? Created attachment 135655 [details]
Patch that stops rpc_mkpipe from creating S_IFSOCK inodes that don't have sk buffers... something at drives SELinux nuts...
If this is the final patch, mine hasn't crashed but that doesn't make it right,
then we will need to fix the following AVC denial in policy.
audit(1157483505.359:6): avc: denied { read write } for pid=1959
comm="rpc.idmapd" name="idmap" dev=rpc_pipefs ino=739
scontext=root:system_r:rpcd_t:s0 tcontext=system_u:object_r:rpc_pipefs_t:s0
tclass=fifo_file
Created attachment 136032 [details]
policy file to allow rpcidmapd to use fifos
simply download and run
"semodule -i rpc_mkpipe.pp"
Fixed in selinux-policy-2.3.14-3 fixed and in RHEL5 kernel |
Description of problem: Using a rawhide kernel (2.6.17-1.2600) and a kernel from CVS (2.6.17-1.2608) an oops occurs when a NFS v4 filesystem is mounted. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1.mount -t nfs4 sever:/export /mnt/server/export 2. 3. Actual results: FS-Cache: Loaded FS-Cache: netfs 'nfs' registered for caching BUG: unable to handle kernel paging request at virtual address 6b6b6d6f printing eip: c04c96a3 *pde = 00000000 Oops: 0000 [#1] SMP last sysfs file: /block/sda/sda1/size Modules linked in: nfs lockd fscache nfs_acl hidp rfcomm l2cap bluetooth sunrpcdCPU: 1 EIP: 0060:[<c04c96a3>] Not tainted VLI EFLAGS: 00210246 (2.6.17-1.2608 #1) EIP is at selinux_file_permission+0xdb/0x12b eax: 6b6b6b6b ebx: f5d1727c ecx: 0000000c edx: 00000063 esi: 0000008c edi: bf90433c ebp: f7fb5f7c esp: f7fb5f64 ds: 007b es: 007b ss: 0068 Process rpc.idmapd (pid: 2031, ti=f7fb5000 task=c1948aa0 task.ti=f7fb5000) Stack: 00000004 00000000 f5d2ec34 f7287664 0000008c bf90433c f7fb5f94 c0473623 0000008c f7287664 fffffff7 00000000 f7fb5fb4 c0473ad5 f7fb5fa0 00000000 00000000 00000000 00000009 082097f0 f7fb5000 c0403faf 00000009 bf90433c Call Trace: [<c0473623>] vfs_read+0x87/0x155 [<c0473ad5>] sys_read+0x3b/0x60 [<c0403faf>] syscall_call+0x7/0xb DWARF2 unwinder stuck at syscall_call+0x7/0xb Leftover inexact backtrace: [<c0405379>] show_stack_log_lvl+0x8a/0x95 [<c04054b1>] show_registers+0x12d/0x19a [<c04056ae>] die+0x190/0x293 [<c0615335>] do_page_fault+0x3dc/0x4a4 [<c0404be1>] error_code+0x39/0x40 [<c0473623>] vfs_read+0x87/0x155 [<c0473ad5>] sys_read+0x3b/0x60 [<c0403faf>] syscall_call+0x7/0xb Code: b8 ff ff 85 c0 89 45 ec 75 66 8b 55 f0 0f b7 42 28 25 00 f0 00 00 3d 00 c Expected results: a mounted fileystem. Additional info: Attached is the patch seems to prevent the oops but does not necessarily solve the problem