This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 218185 - Selinux denial of /bin/mount triggers tainted PF, resulting in GPF and spinlock.
Selinux denial of /bin/mount triggers tainted PF, resulting in GPF and spinlock.
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
6
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-02 16:28 EST by Richard Michael
Modified: 2015-01-04 17:29 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-12-18 23:10:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
syslog output showing several lockup/reboot cycles. (26.01 KB, application/x-gzip)
2006-12-02 16:28 EST, Richard Michael
no flags Details

  None (edit)
Description Richard Michael 2006-12-02 16:28:33 EST
Description of problem:
On hotplug of usb2 drive w/ reiserfs 3.6, selinux prevents, reporting: 

SELinux prevented /bin/mount from mounting a filesystem on the file
or directory "/" of type "unlabeled_t".

Immediately following, the kernel suffers a GPF, from the ksyslog:

kernel: general protection fault: 0000 [1] SMP

Shortly afterward, it seems there is a tainted page file, CPU1 suffers a
software lock, the kernel subsequently spinlocks on CPU1, and the system must be
hard rebooted, from the ksyslog:

kernel: BUG: spinlock lockup on CPU#1, pdflush/262, ffffffff8055e230 (Tainted:
PF    )

I've attached a portion of output from /var/log/messages, showing several
occurrences from my tests, with the reboots also shown inbetween to identify
hardware.


Version-Release number of selected component (if applicable):

uname -a
Linux desktop.domain 2.6.18-1.2849.fc6 #1 SMP Fri Nov 10 12:34:46 EST 2006
x86_64 x86_64 x86_64 GNU/Linux



How reproducible:


Steps to Reproduce:
1. Enable selinux, boot to desktop (Gnome).
2. Connect external USB harddrive with Reiserfs 3.6.
3. Wait for selinux to prevent auto /bin/mount call, GPFing/spinlocking kernel.
  

Solution/Workaround:

Pass selinux=0 to the kernel at boot, and the hotplug/mount event is handled
fine and appropriate icon appears on the desktop, etc..]

Additional info:

To instruct selinux to allow /bin/mount, I tried following the selinux suggested
command:

setsebool -P allow_mount_anyfile=1

This failed because DBUS was unable to contact the audit system, from the
(attached) syslog:

Dec  2 13:43:26 desktop dbus: Can't send to audit system: USER_AVC avc: 
received policyload notice (seqno=2) : exe="?" (sauid=81, hostname=?, addr=?
, terminal=?)
Dec  2 13:43:26 desktop dbus: Can't send to audit system: USER_AVC avc: 
received policyload notice (seqno=2) : exe="/bin/dbus-daemon" (sauid=500, ho
stname=?, addr=?, terminal=?)
Dec  2 13:43:27 desktop setsebool: The allow_mount_anyfile policy boolean was
changed to 1 by root

Software Versions:
rpm -qa | grep -i selinux

selinux-policy-2.4.5-3.fc6
libselinux-1.30.29-2
selinux-policy-targeted-2.4.5-3.fc6
libselinux-python-1.30.29-2
libselinux-1.30.29-2

rpm -qa | grep -i dbus

dbus-glib-devel-0.70-5.fc6
dbus-x11-1.0.1-2.fc6
dbus-glib-0.70-5.fc6
dbus-1.0.1-2.fc6
dbus-devel-1.0.1-2.fc6
dbus-python-0.70-6
dbus-1.0.1-2.fc6
dbus-glib-0.70-5.fc6

I consider the selinux problem to be a seperate bug, which I will file elsewhere.
Comment 1 Richard Michael 2006-12-02 16:28:34 EST
Created attachment 142670 [details]
syslog output showing several lockup/reboot cycles.
Comment 2 Dave Jones 2006-12-18 23:10:24 EST
Please take bugs from tainted kernels to the vendors of the binary modules you
use.   They have our source code, we don't have theirs, making this near
impossible to diagnose.
Comment 3 Richard Michael 2006-12-19 00:03:42 EST
(In reply to comment #2)
> Please take bugs from tainted kernels to the vendors of the binary modules you
> use.   They have our source code, we don't have theirs, making this near
> impossible to diagnose.
> 

I think the only module I'm using is the nvidia graphics driver.  If I
demonstrate the bug without it (I could use the XOrg nv module; or no X at all),
will that help?

Note You need to log in before you can comment on or make changes to this bug.