Bug 490753 (mmap_zero_fedora)
| Summary: | Kernel assigns addresses less mmap_min_addr when not MAP_FIXED | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Simon Lewis <simon.lewis> |
| Component: | kernel | Assignee: | Justin M. Forbes <jforbes> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | rawhide | CC: | drepper, dwalsh, eparis, i, itamar, jakub, jam, jarod, jforbes, kernel-maint, mikhail.v.gavrilov, mtasaka, Robert-Martin, sgrubb, simon.lewis |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2026-01-26 13:00:33 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: | |||
|
Description
Simon Lewis
2009-03-17 20:01:55 UTC
Simon, could you try: # yum reinstall selinux-policy-targeted and then # fixfiles restore This is the second report of prelink trying to call mmap(addr<64k, MAP_FIXED); Why is prelink doing this? Prelink never assigns < 64KB as the base address of any library (see /var/log/prelink/prelink.log or prelink -pv for addresses it assigned) and the loads of segfaults of the ld-linux* processes are believed to be a recent kernel bug, so it is very well possible kernel is messing stuff in this case as well, or there is some badly linked binary with base address 0. If you can reproduce this, just try run prelink under strace -f to see with what arguments ld.so has been invoked and what it actually tried to mmap at address 0, then try to reproduce it with running ld.so with those arguments by hand. Hello Mgrepl, Eric and Jakub,
I reinstalled selinux-policy-targeted.noarch 0:3.5.13-48.fc10 as you suggested.
[root@hp550-01 ~]# fixfiles restore completed without any errors in terminal but produced the following AVC-Access-Denial:
Zusammenfassung:
SELinux hindert den setfiles daran, evtl. falsch gekennzeichnete Dateien zu
verwenden (/tmp/kde-simon/konsolehX3066.tmp).
Detaillierte Beschreibung:
SELinux verweigerte setfiles den Zugriff auf potentiell falsch gekennzeichnete
Dateien (/tmp/kde-simon/konsolehX3066.tmp). Dies bedeutet, dass SELinux setfiles
die Verwendung dieser Dateien untersagt. Es ist üblich, dass Benutzer Dateien
in Ihrem Benutzerverzeichnis oder in temporären Verzeichnissen editieren und
dann in Systemverzeichnisse verschieben (mv). Das Problem ist, dass diese dort
mit einem Dateikontext abgelegt werden, auf den bestimmte Anwendungen nicht
zugreifen dürfen.
Zugriff erlauben:
Wenn Sie setfiles den Zugriff auf diese Dateien erlauben möchten, müssen Sie
diese mit restorecon -v /tmp/kde-simon/konsolehX3066.tmp neu kennzeichnen. Sie
können auch gleich das ganze Verzeichnis mit restorecon -R -v /tmp/kde-simon
neu kennzeichnen.
Zusätzliche Informationen:
Quellkontext unconfined_u:unconfined_r:setfiles_t:s0
Zielkontext unconfined_u:object_r:user_tmp_t:s0
Zielobjekte /tmp/kde-simon/konsolehX3066.tmp [ file ]
Quelle setfiles
Quellen-Pfad /sbin/setfiles
Port <Unbekannt>
Host hp550-01
Quellen-RPM-Pakete policycoreutils-2.0.57-17.fc10
Ziel-RPM-Pakete
RPM-Richtlinie selinux-policy-3.5.13-48.fc10
SELinux aktiviert True
Richtlinienversion targeted
MLS aktiviert True
Enforcing-Modus Enforcing
Plugin-Name home_tmp_bad_labels
Hostname hp550-01
Plattform Linux hp550-01 2.6.27.19-170.2.35.fc10.x86_64 #1
SMP Mon Feb 23 13:00:23 EST 2009 x86_64 x86_64
Anzahl der Alarme 1
Zuerst gesehen Mi 18 Mär 2009 20:26:53 CET
Zuletzt gesehen Mi 18 Mär 2009 20:26:53 CET
Lokale ID 44beadda-41d8-416a-90eb-bea97c79a5cd
Zeilennummern
Raw-Audit-Meldungen
node=hp550-01 type=AVC msg=audit(1237404413.545:35): avc: denied { read } for pid=3204 comm="setfiles" path="/tmp/kde-simon/konsolehX3066.tmp" dev=sda6 ino=377356 scontext=unconfined_u:unconfined_r:setfiles_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file
node=hp550-01 type=AVC msg=audit(1237404413.545:35): avc: denied { read } for pid=3204 comm="setfiles" path="/tmp/kde-simon/konsoleSL3066.tmp" dev=sda6 ino=377357 scontext=unconfined_u:unconfined_r:setfiles_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file
node=hp550-01 type=AVC msg=audit(1237404413.545:35): avc: denied { read } for pid=3204 comm="setfiles" path="/tmp/kde-simon/konsolenn3066.tmp" dev=sda6 ino=377358 scontext=unconfined_u:unconfined_r:setfiles_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file
node=hp550-01 type=SYSCALL msg=audit(1237404413.545:35): arch=c000003e syscall=59 success=yes exit=0 a0=2223b30 a1=2210fd0 a2=220bf70 a3=7fffc50194e0 items=0 ppid=3192 pid=3204 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=1 comm="setfiles" exe="/sbin/setfiles" subj=unconfined_u:unconfined_r:setfiles_t:s0 key=(null)
Best regards, Simon
This AVC is unrelated to the mmap_zero avc and can be ignored. It is caused by a leaked file descriptor in konsole/kdebase, which has been reported to them several times. I'm seeing this problem too.
type=AVC msg=audit(1237820250.382:127): avc: denied { mmap_zero } for pid=20152 comm="ld-linux-x86-64" scontext=system_u:system_r:prelink_t:s0 tcontext=system_u:system_r:prelink_t:s0 tclass=memprotect
type=SYSCALL msg=audit(1237820250.382:127): arch=c000003e syscall=9 success=no exit=-13 a0=0 a1=600a78 a2=3 a3=32 items=0 ppid=17324 pid=20152 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="ld-linux-x86-64" exe="/lib64/ld-2.9.so" subj=system_u:system_r:prelink_t:s0 key=(null)
If you look at a3, its passing 0x32 which maps to MAP_ANONYMOUS|MAP_FIXED|MAP_PRIVATE and a0 is NULL so its asking for mappings to begin at zero address. A2 says PROT_READ|PROT_WRITE. The a1 argument shows a request for > 100Mb.
Review of /var/log/prelink/prelink.log shows a couple things:
/usr/sbin/prelink: /usr/bin/msntest: Could not parse `Inconsistency detected by ld.so: dl-load.c: 690: _dl_init_paths: Assertion `pelem->dirname[0] == '/'' failed!'
Laying out 830 libraries in virtual address space 0000003000000000-0000004000000000
Random base 0x000000306c800000
Assigned virtual address space slots for 64-bit x86-64 ELF libraries:
So, aside from that one app. nothing too interesting.
This is a kernel problem, dup of bug 507017 but it's an upstream problem. there is nothing wrong with prelink. I'm taking the bug as a remember I need to fix this upstream. This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping *** Bug 707390 has been marked as a duplicate of this bug. *** This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19 Is this still a problem with 3.9 based F19 kernels? Yes. Still a problem. *** Bug 970830 has been marked as a duplicate of this bug. *** *** Bug 809329 has been marked as a duplicate of this bug. *** *** Bug 1008852 has been marked as a duplicate of this bug. *** *** Bug 981862 has been marked as a duplicate of this bug. *** This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component. Is this still a problem with 6.18-based Fedora 43 kernels? It's... been a few years. The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days or the product is inactive and locked |