Bug 1433969

Summary:	coredump happens when starting kdump service with "path /" specified in /etc/kdump.conf
Product:	Red Hat Enterprise Linux 7	Reporter:	Xunlei Pang <xlpang>
Component:	policycoreutils	Assignee:	Petr Lautrbach <plautrba>
Status:	CLOSED DUPLICATE	QA Contact:	BaseOS QE Security Team <qe-baseos-security>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	7.4	CC:	dwalsh, kdump-team-bugs, lvrabec, mgrepl, mmalik, plautrba, ssekidde, xlpang
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-03-29 13:54:48 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Xunlei Pang 2017-03-20 13:34:03 UTC

Description of problem:
When specifying "path /" in /etc/kdump.conf, and restart kdump service,
we will get the following message:

kexec: unloaded kdump kernel
Stopping kdump: [OK]
pxl selinux_relabel: ///
*** Error in `restorecon': free(): invalid pointer: 0x00007f7f6869f1e1 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x7cfe1)[0x7f7f66afcfe1]
/lib64/libselinux.so.1(realpath_not_final+0xc0)[0x7f7f672b5750]
restorecon(+0x3a33)[0x7f7f676f9a33]
restorecon(+0x3bcb)[0x7f7f676f9bcb]
restorecon(+0x242c)[0x7f7f676f842c]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f7f66aa1b15]
restorecon(+0x267d)[0x7f7f676f867d]
======= Memory map: ========

... ...
7fbf7f375000-7fbf7f534000 rw-p 00000000 00:00 0                          [heap]
7ffd02d78000-7ffd02d99000 rw-p 00000000 00:00 0                          [stack]
7ffd02db0000-7ffd02db2000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
/usr/bin/kdumpctl: line 962:  8855 Aborted                 (core dumped) restorecon $_i

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


How reproducible:
kexec-tools-2.0.7-51.el7.x86_64

Steps to Reproduce:
1. in /etc/kdump.conf
   change default "path /var/crash" to "path /"
2. kdumpctl restart

Actual results:


Expected results:
no coredump happens, kdump can start properly.

Additional info:

Comment 2 Xunlei Pang 2017-03-27 06:20:30 UTC

The root cause is that "restorecon" generated the coredump.

I was able to reproduce it in the following way:
1) create a symbol link file, say
mkdir /restorecon
touch /restorecon/test
ln /restorecon/test -s /restorecon/link
2) then "restorecon /restorecon/link" or "restorecon /restorecon//link" or even more "/" appended to the second "/", it works well
3) but "restorecon //restorecon/link"(append multiple "/" at the very beginning) will surely trigger coredump

So the bug is due to some problem of "restorecon", but we could make a simple workaround by stripping all the duplicate "/".

Also we better not do the relabel in case of "/", as there are so many files(including procfs, sysfs, etc) under "/" which is really time-consuming and needless.

Comment 3 Xunlei Pang 2017-03-28 09:40:39 UTC

Besides the special "path /", It also affects kdump using "path /var/crash" if there happens to be some link file and needs to be relabelled, because our script generates two more "/" at the very beginning.

After discussion, we decide to reassign it to "restorecon" related component.

Comment 4 Milos Malik 2017-03-28 09:46:08 UTC

Which version of libselinux was installed on your machine, when the coredump appeared?

Comment 5 Milos Malik 2017-03-28 10:00:04 UTC

It's possible that you encountered BZ#1404644.

Comment 6 Xunlei Pang 2017-03-28 14:00:16 UTC

(In reply to Milos Malik from comment #4)
> Which version of libselinux was installed on your machine, when the coredump
> appeared?

I confirmed it has been fixed on latest rhel7.4(with the following RPMs):
policycoreutils-2.5-14.el7.x86_64
libselinux-2.5-11.el7.x86_64
libselinux-python-2.5-11.el7.x86_64
libselinux-utils-2.5-11.el7.x86_64

I think you can close it as CURRENTRELEASE, thanks!

Comment 7 Petr Lautrbach 2017-03-29 13:54:48 UTC


*** This bug has been marked as a duplicate of bug 1404644 ***