Bug 1525974

Summary:	Linux 4.14.3 breaks core dumping for processes in namespaces (systemd units) with SELinux
Product:	[Fedora] Fedora	Reporter:	Martin Pitt <mpitt>
Component:	kernel	Assignee:	Kernel Maintainer List <kernel-maint>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	27	CC:	airlied, ajax, bskeggs, ewk, hdegoede, ichavero, itamar, jarodwilson, jeremy, jglisse, john.j5live, jonathan, josef, kernel-maint, labbott, linville, mchehab, mjg59, steved
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-02-20 15:27:57 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 Martin Pitt 2017-12-14 14:13:10 UTC

Description of problem: Latest Fedora 26 and 27 kernel updates break  core dumping for processes in systemd units. On 4.13.16-302.fc27.x86_64 everything works as intended, on 4.14.3-300.fc27.x86_64 not any more.

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

kernel-4.14.5-300.fc27.x86_64

How reproducible: Always

Steps to Reproduce:
1. journalctl -f
2. systemctl start systemd-hostnamed
3. pkill -e -SEGV systemd-hostnam

Actual results:

journal shows no backtrace and coredumpctl shows no coredump.

Expected results:

Journal shows something like "Process 3271 (systemd-hostnam) of user 0 dumped core." and a backtrace.


Additional info:

 * This works for "default namespace" processes, like so:
   sleep 100 &
   pkill -e -SEGV sleep
   Then you get a core dump.

 * This works once you disable SELinux (setenforce 0). However, there are no SELinux violations logged.

 * This is not dependent on systemd-coredump. You can do

# cat <<EOF > /tmp/core.sh 
#!/bin/sh
echo "invoked core dump: $@" >> /tmp/log
cat > /tmp/core
echo "invoked core dump: $@ DONE" >> /tmp/log
EOF
# chmod 755 /tmp/core.sh
# echo "|/tmp/core.sh %P %u" > /proc/sys/kernel/core_pattern 

  and then run the above expriments again with the same result: core is dumped for sleep but not for systemd-hostnamed. So this is not an issue in systemd-coredump.

Comment 1 Martin Pitt 2017-12-14 15:01:05 UTC

The "in namespaces" part could be premature -- maybe it's also just a matter of core dump size. https://www.spinics.net/lists/kernel/msg2672293.html could be related (thanks to "grift" for pointing out).

Comment 2 Laura Abbott 2017-12-14 16:25:12 UTC

If you can do a bisection, that's going to be the fastest way to find what broke. Also, please test on a rawhide kernel to see if the problem is present there as well.

Comment 3 Martin Pitt 2017-12-18 11:38:33 UTC

F27 got updated from 4.14.3 to 4.14.5-300.fc27.x86_64, confirmed that the issue still exists with that.

Comment 4 Martin Pitt 2017-12-18 11:56:28 UTC

Confirmed with kernel 4.15.0-0.rc3.git0.1.fc28.x86_64 from rawhide (https://fedoraproject.org/wiki/RawhideKernelNodebug), same behaviour.

Comment 5 Laura Abbott 2017-12-18 23:12:17 UTC

Okay, I did a bisect and think I got a bad commit

git bisect start 'v4.14' 'v4.13'
# good: [15d8ffc96464f6571ecf22043c45fad659f11bdd] Merge tag 'mmc-v4.14' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
git bisect good 15d8ffc96464f6571ecf22043c45fad659f11bdd
# bad: [e90937e756938f03d37d4cae7c82316a3a425944] Merge tag 'armsoc-devicetree' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
git bisect bad e90937e756938f03d37d4cae7c82316a3a425944
# bad: [fd1d362600e2d2edb6262d8e05661424c1a315bf] ARM: implement memset32 & memset64
git bisect bad fd1d362600e2d2edb6262d8e05661424c1a315bf
# good: [c0da4fa0d1a54495d6055c009ac46b76d1da2c86] Merge tag 'media/v4.14-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
git bisect good c0da4fa0d1a54495d6055c009ac46b76d1da2c86
# good: [44ccba3f7b230af1bd7ebe173cbf5803df1df486] Merge tag 'gcc-plugins-v4.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux
git bisect good 44ccba3f7b230af1bd7ebe173cbf5803df1df486
# good: [2877cbffb79ed121a6bcc5edbe629d3aba36cd29] scsi: lpfc: Fix loop mode target discovery
git bisect good 2877cbffb79ed121a6bcc5edbe629d3aba36cd29
# good: [a45a1f3614182267803baadba657b59e2ddc0545] scsi: scsi-mq: Always unprepare before requeuing a request
git bisect good a45a1f3614182267803baadba657b59e2ddc0545
# bad: [8135d8926c08e553e39b0b040c6d01f0daef0676] mm: memory_hotplug: memory hotremove supports thp migration
git bisect bad 8135d8926c08e553e39b0b040c6d01f0daef0676
# bad: [0fb02e718f5fd88b175387bc2a9313b27609f0da] Merge tag 'audit-pr-20170907' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit
git bisect bad 0fb02e718f5fd88b175387bc2a9313b27609f0da
# bad: [e37fdb785a5f95ecadf43b773c97f676500ac7b8] exec: Use secureexec for setting dumpability
git bisect bad e37fdb785a5f95ecadf43b773c97f676500ac7b8
# good: [62874c3adf709b884ceb0c61c35ab3794b3b0e95] selinux: Refactor to remove bprm_secureexec hook
git bisect good 62874c3adf709b884ceb0c61c35ab3794b3b0e95
# good: [46d98eb4e1d2bc225f661879e0e157a952107598] commoncap: Refactor to remove bprm_secureexec hook
git bisect good 46d98eb4e1d2bc225f661879e0e157a952107598
# good: [2af622802696e1dbe28d81c8ea6355dc30800396] LSM: drop bprm_secureexec hook
git bisect good 2af622802696e1dbe28d81c8ea6355dc30800396
# first bad commit: [e37fdb785a5f95ecadf43b773c97f676500ac7b8] exec: Use secureexec for setting dumpability


It didn't revert cleanly but reverting several other dependent commits it did work. I'll send an e-mail to the author.

Comment 6 Laura Abbott 2018-01-03 00:32:05 UTC

There was a revert on part of the patch https://marc.info/?l=linux-kernel&m=151493531216097 , please test this if you get a chance

Comment 7 Martin Pitt 2018-02-20 15:27:57 UTC

Confirming that this works again on Fedora 27 kernel 4.14.16-300.fc27.x86_64. Thanks!