Description of problem: Chromium from Flathub crashes when trying to display any page. It's totally broken. It's caused by this SELinux denial. SELinux is preventing chrome from using the 'execheap' accesses on a process. ***** Plugin allow_execheap (53.1 confidence) suggests ******************** If you do not think chrome should need to map heap memory that is both writable and executable. Then you need to report a bug. This is a potentially dangerous access. Do contact your security administrator and report this issue. ***** Plugin catchall_boolean (42.6 confidence) suggests ****************** If you want to allow selinuxuser to execheap Then you must tell SELinux about this by enabling the 'selinuxuser_execheap' boolean. Do setsebool -P selinuxuser_execheap 1 ***** Plugin catchall (5.76 confidence) suggests ************************** If you believe that chrome should be allowed execheap access on processes labeled unconfined_t by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'chrome' --raw | audit2allow -M my-chrome # semodule -X 300 -i my-chrome.pp Additional Information: Source Context unconfined_u:unconfined_r:unconfined_t:s0- s0:c0.c1023 Target Context unconfined_u:unconfined_r:unconfined_t:s0- s0:c0.c1023 Target Objects Unknown [ process ] Source chrome Source Path chrome Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-39.2-1.fc39.noarch Local Policy RPM selinux-policy-targeted-39.2-1.fc39.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 6.6.6-200.fc39.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Dec 11 17:29:08 UTC 2023 x86_64 Alert Count 32 First Seen 2023-12-13 22:57:57 CET Last Seen 2023-12-13 22:59:03 CET Local ID aee54079-4072-4f26-b02f-eec538034749 Raw Audit Messages type=AVC msg=audit(1702504743.407:448): avc: denied { execheap } for pid=112249 comm="chrome" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0 Hash: chrome,unconfined_t,unconfined_t,process,execheap Version-Release number of selected component: selinux-policy-targeted-39.2-1.fc39.noarch Additional info: reporter: libreport-2.17.11 reason: SELinux is preventing chrome from using the 'execheap' accesses on a process. package: selinux-policy-targeted-39.2-1.fc39.noarch component: selinux-policy hashmarkername: setroubleshoot type: libreport kernel: 6.6.6-200.fc39.x86_64 comment: Chromium from Flathub crashes when trying to display any page. It's totally broken. It's caused by this SELinux denial. component: selinux-policy // EDIT: A minimal reproducer is available in comment 138. The problem has been reported to a kernel mailing list here: https://lore.kernel.org/all/ZrPmoLKJEf1wiFmM@marcreisner.com/ Related Chromium issues (note that Chromium is not the cause): https://issues.chromium.org/issues/348464586 https://issues.chromium.org/issues/350117526 https://issues.chromium.org/issues/335524387
Created attachment 2004203 [details] File: description
Created attachment 2004204 [details] File: os_info
This looks similar to https://bugzilla.redhat.com/show_bug.cgi?id=2252391#c16.
Huh, that's interesting, I can't reproduce it anymore. I haven't updated the system, haven't rebooted it, I just suspended and resumed it. After a reboot cycle, I still can't reproduce it. Hmm, close as WORKSFORME, I guess? And I'll reopen it if I see it again?
In bug 2247299 we have a similar issue, but it is non-deterministic. I think the range that is being marked as executable can be different each run and the bug should only trigger when the end of it touches the heap boundary. So don't write it off just yet :)
*** Bug 2255248 has been marked as a duplicate of this bug. ***
*** Bug 2259677 has been marked as a duplicate of this bug. ***
*** Bug 2263153 has been marked as a duplicate of this bug. ***
This is still happening for me with kernel 6.9.4 (and it actually seems to have gotten worse with the 6.9 update) for Chrome and VS Code. It only happens sporadically and a restart typically fixes it.
Having the same issue. I was able to access several sites via chrome earlier today, but now getting the selinux errors when opening chrome. Restart has not corrected it.
i'm seeing the problem now with Chromium but not with Chrome. I have listed below output from setools and from my dnf update from yesterday which included chromium among various other apps. The se error is occurring on both my laptop and my desktop. -------------------------------------------------------------------------------- SELinux is preventing chromium-browse from using the execheap access on a process. ***** Plugin allow_execheap (53.1 confidence) suggests ******************** If you do not think chromium-browse should need to map heap memory that is both writable and executable. Then you need to report a bug. This is a potentially dangerous access. Do contact your security administrator and report this issue. ***** Plugin catchall_boolean (42.6 confidence) suggests ****************** If you want to allow selinuxuser to execheap Then you must tell SELinux about this by enabling the 'selinuxuser_execheap' boolean. Do setsebool -P selinuxuser_execheap 1 ***** Plugin catchall (5.76 confidence) suggests ************************** If you believe that chromium-browse should be allowed execheap access on processes labeled unconfined_t by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'chromium-browse' --raw | audit2allow -M my-chromiumbrowse # semodule -X 300 -i my-chromiumbrowse.pp Additional Information: Source Context unconfined_u:unconfined_r:unconfined_t:s0- s0:c0.c1023 Target Context unconfined_u:unconfined_r:unconfined_t:s0- s0:c0.c1023 Target Objects Unknown [ process ] Source chromium-browse Source Path chromium-browse Port <Unknown> Host <Unknown> Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-39.7-1.fc39.noarch Local Policy RPM selinux-policy-targeted-39.7-1.fc39.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name xps13-9305.woodhill.okemos.info Platform Linux xps13-9305.woodhill.okemos.info 6.9.6-100.fc39.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Jun 21 15:46:57 UTC 2024 x86_64 Alert Count 23 First Seen 2024-06-29 12:35:16 EDT Last Seen 2024-06-29 12:41:18 EDT Local ID a97dfbf0-17a7-4518-a150-62018bcb6d7b Raw Audit Messages type=AVC msg=audit(1719679278.243:781): avc: denied { execheap } for pid=11602 comm="chromium-browse" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0 Hash: chromium-browse,unconfined_t,unconfined_t,process,execheap ############################################################################ Transaction ID : 744 Begin time : Fri 28 Jun 2024 06:26:43 PM EDT Begin rpmdb : 53ab9898966ad44afa3acffc7278b50dac5b50cc1733f4c26fc767b95a7a1260 End time : Fri 28 Jun 2024 06:29:11 PM EDT (148 seconds) End rpmdb : f1fecd0941bd1938ba861750323548f47ac7e042a8eb962ff04a533d940621c2 User : Joseph Verreau <jverreau> Return-Code : Success Releasever : 39 Command Line : distro-sync Comment : Packages Altered: Install kernel-6.9.6-100.fc39.x86_64 @updates Install kernel-core-6.9.6-100.fc39.x86_64 @updates Install kernel-modules-6.9.6-100.fc39.x86_64 @updates Install kernel-modules-core-6.9.6-100.fc39.x86_64 @updates Install kernel-modules-extra-6.9.6-100.fc39.x86_64 @updates Upgrade opera-stable-111.0.5168.43-0.x86_64 @opera Upgraded opera-stable-111.0.5168.25-0.x86_64 @@System Upgrade slack-4.39.88-0.1.el8.x86_64 @slack Upgraded slack-4.38.125-0.1.el8.x86_64 @@System Upgrade ImageMagick-1:7.1.1.33-1.fc39.x86_64 @updates Upgraded ImageMagick-1:7.1.1.26-2.fc39.x86_64 @@System Upgrade ImageMagick-c++-1:7.1.1.33-1.fc39.x86_64 @updates Upgraded ImageMagick-c++-1:7.1.1.26-2.fc39.x86_64 @@System Upgrade ImageMagick-libs-1:7.1.1.33-1.fc39.x86_64 @updates Upgraded ImageMagick-libs-1:7.1.1.26-2.fc39.x86_64 @@System Upgrade alsa-lib-1.2.12-1.fc39.x86_64 @updates Upgraded alsa-lib-1.2.11-2.fc39.x86_64 @@System Upgrade alsa-ucm-1.2.12-1.fc39.noarch @updates Upgraded alsa-ucm-1.2.11-2.fc39.noarch @@System Upgrade alsa-utils-1.2.12-1.fc39.x86_64 @updates Upgraded alsa-utils-1.2.11-1.fc39.x86_64 @@System Upgrade chromium-126.0.6478.126-1.fc39.x86_64 @updates Upgraded chromium-126.0.6478.114-1.fc39.x86_64 @@System Upgrade chromium-common-126.0.6478.126-1.fc39.x86_64 @updates Upgraded chromium-common-126.0.6478.114-1.fc39.x86_64 @@System Upgrade container-selinux-2:2.232.1-1.fc39.noarch @updates Upgraded container-selinux-2:2.231.0-1.fc39.noarch @@System Upgrade firefox-127.0.2-1.fc39.x86_64 @updates Upgraded firefox-126.0-7.fc39.x86_64 @@System Upgrade firefox-langpacks-127.0.2-1.fc39.x86_64 @updates Upgraded firefox-langpacks-126.0-7.fc39.x86_64 @@System Upgrade firefox-wayland-127.0.2-1.fc39.x86_64 @updates Upgraded firefox-wayland-126.0-7.fc39.x86_64 @@System Upgrade freeglut-3.6.0-1.fc39.x86_64 @updates Upgraded freeglut-3.4.0-7.fc39.x86_64 @@System Upgrade grub2-common-1:2.06-121.fc39.noarch @updates Upgraded grub2-common-1:2.06-120.fc39.noarch @@System Upgrade grub2-efi-ia32-1:2.06-121.fc39.x86_64 @updates Upgraded grub2-efi-ia32-1:2.06-120.fc39.x86_64 @@System Upgrade grub2-efi-ia32-cdboot-1:2.06-121.fc39.x86_64 @updates Upgraded grub2-efi-ia32-cdboot-1:2.06-120.fc39.x86_64 @@System Upgrade grub2-efi-x64-1:2.06-121.fc39.x86_64 @updates Upgraded grub2-efi-x64-1:2.06-120.fc39.x86_64 @@System Upgrade grub2-efi-x64-cdboot-1:2.06-121.fc39.x86_64 @updates Upgraded grub2-efi-x64-cdboot-1:2.06-120.fc39.x86_64 @@System Upgrade grub2-pc-1:2.06-121.fc39.x86_64 @updates Upgraded grub2-pc-1:2.06-120.fc39.x86_64 @@System Upgrade grub2-pc-modules-1:2.06-121.fc39.noarch @updates Upgraded grub2-pc-modules-1:2.06-120.fc39.noarch @@System Upgrade grub2-tools-1:2.06-121.fc39.x86_64 @updates Upgraded grub2-tools-1:2.06-120.fc39.x86_64 @@System Upgrade grub2-tools-efi-1:2.06-121.fc39.x86_64 @updates Upgraded grub2-tools-efi-1:2.06-120.fc39.x86_64 @@System Upgrade grub2-tools-extra-1:2.06-121.fc39.x86_64 @updates Upgraded grub2-tools-extra-1:2.06-120.fc39.x86_64 @@System Upgrade grub2-tools-minimal-1:2.06-121.fc39.x86_64 @updates Upgraded grub2-tools-minimal-1:2.06-120.fc39.x86_64 @@System Upgrade ibus-typing-booster-2.25.9-3.fc39.noarch @updates Upgraded ibus-typing-booster-2.25.8-1.fc39.noarch @@System Upgrade keepassxc-2.7.9-1.fc39.x86_64 @updates Upgraded keepassxc-2.7.8-2.fc39.x86_64 @@System Upgrade kernel-tools-6.9.6-100.fc39.x86_64 @updates Upgraded kernel-tools-6.9.5-100.fc39.x86_64 @@System Upgrade kernel-tools-libs-6.9.6-100.fc39.x86_64 @updates Upgraded kernel-tools-libs-6.9.5-100.fc39.x86_64 @@System Upgrade langtable-0.0.67-1.fc39.noarch @updates Upgraded langtable-0.0.66-1.fc39.noarch @@System Upgrade libldb-2.8.1-1.fc39.x86_64 @updates Upgraded libldb-2.8.0-1.fc39.x86_64 @@System Upgrade libmaxminddb-1.10.0-1.fc39.x86_64 @updates Upgraded libmaxminddb-1.9.1-1.fc39.x86_64 @@System Upgrade libopenmpt-0.7.8-1.fc39.x86_64 @updates Upgraded libopenmpt-0.7.6-1.fc39.x86_64 @@System Upgrade libsmbclient-2:4.19.7-1.fc39.x86_64 @updates Upgraded libsmbclient-2:4.19.6-1.fc39.x86_64 @@System Upgrade libwbclient-2:4.19.7-1.fc39.x86_64 @updates Upgraded libwbclient-2:4.19.6-1.fc39.x86_64 @@System Upgrade python3-dns-2.6.1-1.fc39.noarch @updates Upgraded python3-dns-2.4.2-1.fc39.noarch @@System Upgrade python3-langtable-0.0.67-1.fc39.noarch @updates Upgraded python3-langtable-0.0.66-1.fc39.noarch @@System Upgrade python3-perf-6.9.6-100.fc39.x86_64 @updates Upgraded python3-perf-6.9.5-100.fc39.x86_64 @@System Upgrade samba-client-2:4.19.7-1.fc39.x86_64 @updates Upgraded samba-client-2:4.19.6-1.fc39.x86_64 @@System Upgrade samba-client-libs-2:4.19.7-1.fc39.x86_64 @updates Upgraded samba-client-libs-2:4.19.6-1.fc39.x86_64 @@System Upgrade samba-common-2:4.19.7-1.fc39.noarch @updates Upgraded samba-common-2:4.19.6-1.fc39.noarch @@System Upgrade samba-common-libs-2:4.19.7-1.fc39.x86_64 @updates Upgraded samba-common-libs-2:4.19.6-1.fc39.x86_64 @@System Upgrade thunderbird-115.12.1-1.fc39.x86_64 @updates Upgraded thunderbird-115.11.0-1.fc39.x86_64 @@System Upgrade thunderbird-librnp-rnp-115.12.1-1.fc39.x86_64 @updates Upgraded thunderbird-librnp-rnp-115.11.0-1.fc39.x86_64 @@System Upgrade upower-1.90.4-1.fc39.x86_64 @updates Upgraded upower-1.90.2-3.fc39.x86_64 @@System Upgrade upower-libs-1.90.4-1.fc39.x86_64 @updates Upgraded upower-libs-1.90.2-3.fc39.x86_64 @@System Upgrade youtube-dl-2024.06.11.git0153b38-1.fc39.noarch @updates Upgraded youtube-dl-2023.08.04.git86e3cf5-1.20230815git86e3cf5.fc39.noarch @@System Reason Change kernel-6.8.9-200.fc39.x86_64 @updates Removed kernel-6.8.8-200.fc39.x86_64 @@System Reason Change kernel-core-6.8.9-200.fc39.x86_64 @updates Removed kernel-core-6.8.8-200.fc39.x86_64 @@System Reason Change kernel-modules-6.8.9-200.fc39.x86_64 @updates Removed kernel-modules-6.8.8-200.fc39.x86_64 @@System Reason Change kernel-modules-core-6.8.9-200.fc39.x86_64 @updates Removed kernel-modules-core-6.8.8-200.fc39.x86_64 @@System Reason Change kernel-modules-extra-6.8.9-200.fc39.x86_64 @updates Removed kernel-modules-extra-6.8.8-200.fc39.x86_64 @@System Scriptlet output: 1 Redirecting to /bin/systemctl start atd.service jverreau@xps13-9305:~$
Bug #2263153 has been marked of a duplicate of this bug, even though they're about different programs: ThreadPoolForeg (whatever it exactly is, I couldn't locate it) vs. chrome. This is fine by me (I have no clue but I'll trust the merger), but there are more similar issues when searching for 'execheap': 2247299 SELinux is preventing wine-preloader from using the 'execheap' accesses on a process. 2294839 Intermittent SELinux execheap denial breaks chromium 2254434 SELinux is preventing chrome from using the 'execheap' accesses on a process. <= this one 2281516 SELinux is preventing wine-preloader from using the 'execheap' accesses on a process. 2293753 SELinux is preventing chrome from using the 'execheap' accesses on a process. 2293851 SELinux is preventing wine-preloader from using the 'execheap' accesses on a process. 2294015 SELinux is preventing code from using the 'execheap' accesses on a process. They're all from end of June/beginning of July so probably related to the upgrade to F40, and I've been hit all of them. According to my limited tests, it happens when you start a certain program (related to Chromium/Electron apparently) for the first time during a session. It can happen hundreds of time if not thousands within a very short time span, and it's annoying (not saying it's not justified, I can't judge, but a secure solution would be appreciated).
On Fedora30, upgrading to Chromium 1.26 resulted in this error too. The heapexec selinux error shows up in other flatpaks too (trying to use MS Teams failed for instance). Chromium reports "[15189:1:0705/090808.694952:ERROR:v8_initializer.cc(809)] V8 process OOM (Failed to reserve virtual memory for CodeRange)." each time selinux blocks it. It does not depend on what site Chromium tries to load - even a about:blank results in this error.
(In reply to Peter Larsen from comment #13) > On Fedora30, upgrading to Chromium 1.26 resulted in this error too. The > heapexec selinux error shows up in other flatpaks too (trying to use MS > Teams failed for instance). > > Chromium reports "[15189:1:0705/090808.694952:ERROR:v8_initializer.cc(809)] > V8 process OOM (Failed to reserve virtual memory for CodeRange)." each time > selinux blocks it. It does not depend on what site Chromium tries to load - > even a about:blank results in this error. Responding to myself. A reinstall of Chromium 1.26 removed this error. The package fully validated before I did this - however now I can launch chromium without getting the SELinux error or see the OOM error from Chromium.
Ondrej, The issue reproduces quite well with google-chrome-stable-126.0.6478.126-1.x86_64 and kernel-6.9.7-200.fc40.x86_64, a few times per hour. Is it still the same root cause? type=PROCTITLE msg=audit(8.7.2024 09:30:50.097:438) : proctitle=/opt/google/chrome/chrome --type=renderer --crashpad-handler-pid=3489 --enable-crash-reporter=, --extension-process --origin-tri type=SYSCALL msg=audit(8.7.2024 09:30:50.097:438) : arch=x86_64 syscall=pkey_mprotect success=yes exit=0 a0=0x561ae0000000 a1=0x20000000 a2=0x7 a3=0x1 items=0 ppid=3522 pid=5929 auid=username uid=username gid=username euid=username suid=username fsuid=username egid=username sgid=username fsgid=username tty=(none) ses=3 comm=chrome exe=/opt/google/chrome/chrome subj=staff_u:staff_r:staff_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(8.7.2024 09:30:50.097:438) : avc: denied { execheap } for pid=5929 comm=chrome scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tclass=process permissive=1 chrome 5929 [005] 355.411840: avc:selinux_audited: requested=0x8000000 denied=0x8000000 audited=0x8000000 result=0 scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tclass=process ffffffffbb771276 avc_audit_post_callback+0x216 ([kernel.kallsyms]) ffffffffbb771276 avc_audit_post_callback+0x216 ([kernel.kallsyms]) ffffffffbb79cceb common_lsm_audit+0x2ab ([kernel.kallsyms]) ffffffffbb772753 slow_avc_audit+0xb3 ([kernel.kallsyms]) ffffffffbb77302f avc_has_perm+0xbf ([kernel.kallsyms]) ffffffffbb77655e selinux_file_mprotect+0x9e ([kernel.kallsyms]) ffffffffbb76d22d security_file_mprotect+0x3d ([kernel.kallsyms]) ffffffffbb40f462 do_mprotect_pkey+0x342 ([kernel.kallsyms]) ffffffffbb40f750 __x64_sys_pkey_mprotect+0x20 ([kernel.kallsyms]) ffffffffbc1874b2 do_syscall_64+0x82 ([kernel.kallsyms]) ffffffffbc20012f entry_SYSCALL_64_after_hwframe+0x76 ([kernel.kallsyms]) 7f574bd08cc3 pkey_mprotect+0x13 (/usr/lib64/libc.so.6) 561abfc6fefc [unknown] (/opt/google/chrome/chrome) 561ab9871c44 [unknown] (/opt/google/chrome/chrome) 561ab972b497 [unknown] (/opt/google/chrome/chrome) 561ab93bb06e [unknown] (/opt/google/chrome/chrome) 561ab93b842f [unknown] (/opt/google/chrome/chrome) 561ab93b7f6a [unknown] (/opt/google/chrome/chrome) 561ab93b7230 [unknown] (/opt/google/chrome/chrome) 561ab93b6a97 [unknown] (/opt/google/chrome/chrome) 561aba1148ae [unknown] (/opt/google/chrome/chrome) 561aba79b3e2 [unknown] (/opt/google/chrome/chrome) 561ab976b5f5 [unknown] (/opt/google/chrome/chrome) 561ab976fb67 [unknown] (/opt/google/chrome/chrome)
Reassigning to kernel for further investigation. It is not clear where the problem is, but is seems the previous fix for https://bugzilla.redhat.com/show_bug.cgi?id=2252391 was not sufficient. The same denial was reported for in chrome, chromium, visual studio, wine, and seems to appear also in F39 with 6.9 kernel. Surely they may not have the same root cause, but the symptoms are identical. https://bugzilla.redhat.com/show_bug.cgi?id=2247299#c43 says: > As mentioned in the linked Fedora thread, this notification is appearing across a wide range of applications. > As of right now we have Wine, Proton, VS Code, Signal, Obsidian, Slack, and Discord.
*** Bug 2281516 has been marked as a duplicate of this bug. ***
*** Bug 2293753 has been marked as a duplicate of this bug. ***
*** Bug 2293851 has been marked as a duplicate of this bug. ***
*** Bug 2294015 has been marked as a duplicate of this bug. ***
*** Bug 2295190 has been marked as a duplicate of this bug. ***
*** Bug 2295749 has been marked as a duplicate of this bug. ***
*** Bug 2296170 has been marked as a duplicate of this bug. ***
*** Bug 2297123 has been marked as a duplicate of this bug. ***
*** Bug 2297337 has been marked as a duplicate of this bug. ***
*** Bug 2247299 has been marked as a duplicate of this bug. ***
*** Bug 2294760 has been marked as a duplicate of this bug. ***
Was getting this sealerts for vscode. Did a dnf update today and restarted and all the SE Alerts stopped for vscode. Currently running Fedora 40, with kernel 6.9.8-200.fc40.x86_64 Was running 6.9.5 before.
See also bug 2298223,
*** Bug 2298223 has been marked as a duplicate of this bug. ***
I'm getting SELinux denials about exechead since june, when I was still using f39. Nowadays, with Fedora 40, I'm receiving frequently the execheap denial when launching obsidian (flatpak), vscode (rpm) or google-chrome (rpm). The program crashes at start, I get flooded with SELinux alerts, and then I relaunch the application. There's some info that I can provide to help?
Those are so, I think, Elektron apps. In addition to these selinux things, my symptoms often include the fact that I can't type into those apps. I can click, or paste text into them, but not type. So far I've read it looks to be ibus-related, but I haven't confirmed that yet. I don't know if that info helps.
*** Bug 2294839 has been marked as a duplicate of this bug. ***
(In reply to Zdenek Pytela from comment #16) > Reassigning to kernel for further investigation. It is not clear where the > problem is, but is seems the previous fix for > https://bugzilla.redhat.com/show_bug.cgi?id=2252391 was not sufficient. > > The same denial was reported for in chrome, chromium, visual studio, wine, > and seems to appear also in F39 with 6.9 kernel. Surely they may not have > the same root cause, but the symptoms are identical. > > https://bugzilla.redhat.com/show_bug.cgi?id=2247299#c43 says: I just upgraded to 6.9.9-100.fc39.x86_64, and Chromium v.126 is working again. VS Code is still trying to access execheap and throwing SELinux violations, but is (mostly) functional.
(In reply to Oliver Sampson from comment #34) > (In reply to Zdenek Pytela from comment #16) > > Reassigning to kernel for further investigation. It is not clear where the > > problem is, but is seems the previous fix for > > https://bugzilla.redhat.com/show_bug.cgi?id=2252391 was not sufficient. > > > > The same denial was reported for in chrome, chromium, visual studio, wine, > > and seems to appear also in F39 with 6.9 kernel. Surely they may not have > > the same root cause, but the symptoms are identical. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2247299#c43 says: > > > I just upgraded to 6.9.9-100.fc39.x86_64, and Chromium v.126 is working > again. VS Code is still trying to access execheap and throwing SELinux > violations, but is (mostly) functional. FWIW, there's a message in VS Code from the spell check plugin: ATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory [Error - 7:35:29 PM] Server initialization failed. Message: Pending response rejected since connection got disposed Code: -32097 [Info - 7:35:29 PM] Connection to server got closed. Server will restart. true [Error - 7:35:29 PM] Code Spell Checker client: couldn't create connection to server. Message: Pending response rejected since connection got disposed Code: -32097
I'm also unable to successfully launch Google Chrome (not Chromium) due to SeLinux. It sort of launches except all the extensions crash and you cannot open any websites. I'm using 6.9.4-200.fc40.x86_64 and selinux-policy-targeted-40.24-1.fc40. Will update to Linux 6.9.10 later today (it hasn't hit mirrors yet). This is also being discussed here and here: https://discussion.fedoraproject.org/t/repeated-security-messages-from-selinux/120424 https://www.reddit.com/r/Fedora/comments/1dmbg3r/fresh_install_selinux_keeps_killing_off_chrome/
Corresponding Chromium bugs: https://issues.chromium.org/issues?q=execheap
*** Bug 2298698 has been marked as a duplicate of this bug. ***
What's weird about this bug is that you launch Chrome/Chromium once, all of its extensions crash. You close it and launch it again, and it works.
*** Bug 2299131 has been marked as a duplicate of this bug. ***
*** Bug 2299552 has been marked as a duplicate of this bug. ***
I can no longer reproduce this bug with Google Chrome Version 127.0.6533.72 (Official Build) (64-bit)
*** Bug 2299824 has been marked as a duplicate of this bug. ***
I can't run ProtonMail or Signal-Desktop due to SELinux blocking Electron. ``` SELinux is preventing wine-preloader from using the execheap access on a process. ***** Plugin allow_execheap (53.1 confidence) suggests ******************** If you do not think wine-preloader should need to map heap memory that is both writable and executable. Then you need to report a bug. This is a potentially dangerous access. Do contact your security administrator and report this issue. ***** Plugin catchall_boolean (42.6 confidence) suggests ****************** If you want to allow unconfined executables to make their heap memory executable. Doing this is a really bad idea. Probably indicates a badly coded executable, but could indicate an attack. This executable should be reported in bugzillaSELinux is preventing wine-preloader from using the execheap access on a process. ***** Plugin allow_execheap (53.1 confidence) suggests ******************** If you do not think wine-preloader should need to map heap memory that is both writable and executable. Then you need to report a bug. This is a potentially dangerous access. Do contact your security administrator and report this issue. ***** Plugin catchall_boolean (42.6 confidence) suggests ****************** If you want to allow unconfined executables to make their heap memory executable. Doing this is a really bad idea. Probably indicates a badly coded executable, but could indicate an attack. This executable should be reported in bugzilla Then you must tell SELinux about this by enabling the 'selinuxuser_execheap' boolean. Do setsebool -P selinuxuser_execheap 1 ***** Plugin catchall (5.76 confidence) suggests ************************** If you believe that wine-preloader should be allowed execheap access on processes labeled unconfined_t by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'wine-preloader' --raw | audit2allow -M my-winepreloader # semodule -X 300 -i my-winepreloader.pp Additional Information: Source Context unconfined_u:unconfined_r:unconfined_t:s0- s0:c0.c1023 Target Context unconfined_u:unconfined_r:unconfined_t:s0- s0:c0.c1023 Target Objects Unknown [ process ] Source wine-preloader Source Path wine-preloader Port <Unknown> Host localhost Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-40.24-1.fc40.noarch Local Policy RPM selinux-policy-targeted-40.24-1.fc40.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name localhost Platform Linux localhost 6.9.10-200.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jul 18 21:39:30 UTC 2024 x86_64 Alert Count 1712 First Seen 2024-06-28 00:07:55 CEST Last Seen 2024-07-26 19:04:03 CEST Local ID d3e577ff-f396-466e-a576-8f1ff4500aa7 Raw Audit Messages type=AVC msg=audit(1722013443.587:1297): avc: denied { execheap } for pid=9183 comm="electron-mail" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0 Hash: wine-preloader,unconfined_t,unconfined_t,process,execheap Then you must tell SELinux about this by enabling the 'selinuxuser_execheap' boolean. Do setsebool -P selinuxuser_execheap 1 ***** Plugin catchall (5.76 confidence) suggests ************************** If you believe that wine-preloader should be allowed execheap access on processes labeled unconfined_t by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'wine-preloader' --raw | audit2allow -M my-winepreloader # semodule -X 300 -i my-winepreloader.pp Additional Information: Source Context unconfined_u:unconfined_r:unconfined_t:s0- s0:c0.c1023 Target Context unconfined_u:unconfined_r:unconfined_t:s0- s0:c0.c1023 Target Objects Unknown [ process ] Source wine-preloader Source Path wine-preloader Port <Unknown> Host localhost Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-40.24-1.fc40.noarch Local Policy RPM selinux-policy-targeted-40.24-1.fc40.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name localhost Platform Linux localhost 6.9.10-200.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jul 18 21:39:30 UTC 2024 x86_64 Alert Count 1712 First Seen 2024-06-28 00:07:55 CEST Last Seen 2024-07-26 19:04:03 CEST Local ID d3e577ff-f396-466e-a576-8f1ff4500aa7 Raw Audit Messages type=AVC msg=audit(1722013443.587:1297): avc: denied { execheap } for pid=9183 comm="electron-mail" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0 Hash: wine-preloader,unconfined_t,unconfined_t,process,execheap ``` ``` SELinux is preventing check from mmap_zero access on the memprotect labeled spc_t. ***** Plugin mmap_zero (53.1 confidence) suggests ************************* If you do not think check should need to mmap low memory in the kernel. Then you may be under attack by a hacker, this is a very dangerous access. Do contact your security administrator and report this issue. ***** Plugin catchall_boolean (42.6 confidence) suggests ****************** If you want to control the ability to mmap a low area of the address space, as configured by /proc/sys/vm/mmap_min_addr. Then you must tell SELinux about this by enabling the 'mmap_low_allowed' boolean. Do setsebool -P mmap_low_allowed 1 ***** Plugin catchall (5.76 confidence) suggests ************************** If you believe that check should be allowed mmap_zero access on memprotect labeled spc_t by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'check' --raw | audit2allow -M my-check # semodule -X 300 -i my-check.pp Additional Information: Source Context system_u:system_r:spc_t:s0 Target Context system_u:system_r:spc_t:s0 Target Objects Unknown [ memprotect ] Source check Source Path check Port <Unknown> Host localhost Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-40.24-1.fc40.noarch Local Policy RPM container-selinux-2.232.1-1.fc40.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name localhost Platform Linux localhost 6.9.10-200.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jul 18 21:39:30 UTC 2024 x86_64 Alert Count 817 First Seen 2023-05-17 18:13:54 CEST Last Seen 2024-07-26 18:37:30 CEST Local ID 44edc8d8-4fce-488e-af88-1c6fa3d63746 Raw Audit Messages type=AVC msg=audit(1722011850.707:218): avc: denied { mmap_zero } for pid=1946 comm="check" scontext=system_u:system_r:spc_t:s0 tcontext=system_u:system_r:spc_t:s0 tclass=memprotect permissive=0 Hash: check,spc_t,spc_t,memprotect,mmap_zero ```
It may have something to do with this other crash: ``` signal-desktop killed by SIGABRT $'/snap/signal-desktop/671/opt/Signal/signal-desktop --type=renderer --enable-crash-reporter=347fc2cd-26b1-47bd-8f4e-668b3b6a31df,no_channel --user-data-dir=/home/user/snap/signal-desktop/671/.config/Signal --app-path=/snap/signal-desktop/671/opt/Signal/resources/app.asar --no-sandbox --no-zygote --enable-blink-features=CSSPseudoDir,CSSLogical --disable-blink-features=Accelerated2dCanvas,AcceleratedSmallCanvases --no-sandbox --disable-gpu-compositing --lang=en-US --num-raster-threads=2 --enable-main-frame-before-activation --renderer-client-id=4 --time-ticks-at-unix-epoch=-1721945177113981 --launch-time-ticks=39464225146 --shared-files=v8_context_snapshot_data:100 --field-trial-handle=3,i,12870250522838319901,8977146239023795160,262144 --enable-features=kWebSQLAccess --disable-features=HardwareMediaKeyHandling,SpareRendererForSitePerProcess --variations-seed-version' executable: /snap/signal-desktop/671/opt/Signal/signal-desktop type-analyzer: CCpp/abrt-journal-core kernel: 6.9.9-200.fc40.x86_64 container_cmdline: $'/snap/signal-desktop/671/opt/Signal/signal-desktop --no-sandbox --no-sandbox' cgroup: 0::/user.slice/user-1000.slice/user/app.slice/snap.signal-desktop.signal-desktop-a5a70cbd-4997-4b5e-8715-61d180662c78.scope runlevel N 5 duphash: bdb19e2b26c97c775715798101215d2dc4cbbf5e journald_cursor: s=f1a8a6611f0b4ebfa5d31fc7d9b4d256;i=3624e762;b=7a04e60df6774344a870b56aa22a9b04;m=9307791d7;t=61e22cb125754;x=fbe49c4cbb9081a4 osrelease: Fedora release 40 (Forty) architecture: x86_64 abrt_version: 2.17.5 User Logs: --jul 26 11:03:56 localhost signal-desktop_signal-desktop.desktop[15673]: Set Windows Application User Model ID (AUMID) { AUMID: 'org.whispersystems.signal-desktop' } jul 26 11:03:56 localhost signal-desktop_signal-desktop.desktop[15673]: NODE_ENV production jul 26 11:03:56 localhost signal-desktop_signal-desktop.desktop[15673]: NODE_CONFIG_DIR /snap/signal-desktop/671/opt/Signal/resources/app.asar/config jul 26 11:03:56 localhost signal-desktop_signal-desktop.desktop[15673]: NODE_CONFIG {} jul 26 11:03:56 localhost signal-desktop_signal-desktop.desktop[15673]: ALLOW_CONFIG_MUTATIONS undefined jul 26 11:03:56 localhost signal-desktop_signal-desktop.desktop[15673]: HOSTNAME localhost jul 26 11:03:56 localhost signal-desktop_signal-desktop.desktop[15673]: NODE_APP_INSTANCE undefined jul 26 11:03:56 localhost signal-desktop_signal-desktop.desktop[15673]: SUPPRESS_NO_CONFIG_WARNING undefined jul 26 11:03:56 localhost signal-desktop_signal-desktop.desktop[15673]: SIGNAL_ENABLE_HTTP undefined jul 26 11:03:56 localhost signal-desktop_signal-desktop.desktop[15673]: userData: /home/user/snap/signal-desktop/671/.config/Signal jul 26 11:03:56 localhost signal-desktop_signal-desktop.desktop[15673]: config/get: Successfully read user config file jul 26 11:03:56 localhost signal-desktop_signal-desktop.desktop[15673]: config/get: Successfully read ephemeral config file jul 26 11:03:57 localhost signal-desktop[15673]: Failed to load module "xapp-gtk3-module" jul 26 11:03:57 localhost signal-desktop[15673]: GTK+ module /snap/signal-desktop/671/gnome-platform/usr/lib/gtk-2.0/modules/libcanberra-gtk-module.so cannot be loaded. GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process is not supported. jul 26 11:03:57 localhost signal-desktop[15673]: Failed to load module "canberra-gtk-module" jul 26 11:03:57 localhost signal-desktop[15673]: Failed to load module "pk-gtk-module" jul 26 11:03:57 localhost signal-desktop[15673]: GTK+ module /snap/signal-desktop/671/gnome-platform/usr/lib/gtk-2.0/modules/libcanberra-gtk-module.so cannot be loaded. GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process is not supported. jul 26 11:03:57 localhost signal-desktop[15673]: Failed to load module "canberra-gtk-module" jul 26 11:03:57 localhost signal-desktop[15673]: Failed to load module "pk-gtk-module" jul 26 11:04:03 localhost signal-desktop_signal-desktop.desktop[16062]: <--- Last few GCs ---> jul 26 11:04:03 localhost signal-desktop_signal-desktop.desktop[16062]: [16062:0x1ae000590000] 2300 ms: Mark-Compact (reduce) 51.6 (70.1) -> 51.4 (54.6) MB, pooled: 0 MB, 64.86 / 0.02 ms (average mu = 0.434, current mu = 0.003) last resort; GC in old space requested jul 26 11:04:03 localhost signal-desktop_signal-desktop.desktop[16062]: [16062:0x1ae000590000] 2340 ms: Mark-Compact (reduce) 51.4 (54.6) -> 49.3 (54.1) MB, pooled: 0 MB, 40.18 / 0.00 ms (average mu = 0.312, current mu = 0.001) last resort; GC in old space requested jul 26 11:04:03 localhost signal-desktop_signal-desktop.desktop[16062]: <--- JS stacktrace ---> jul 26 11:04:03 localhost signal-desktop_signal-desktop.desktop[16062]: FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory jul 26 11:04:03 localhost signal-desktop_signal-desktop.desktop[16062]: ----- Native stack trace ----- jul 26 11:04:05 localhost signal-desktop_signal-desktop.desktop[15673]: Render process is gone: Error: Reason: crashed, Exit Code: 134 jul 26 11:04:05 localhost signal-desktop_signal-desktop.desktop[15673]: at App.<anonymous> (/snap/signal-desktop/671/opt/Signal/resources/app.asar/app/global_errors.js:88:7) jul 26 11:04:05 localhost signal-desktop_signal-desktop.desktop[15673]: at App.emit (node:events:518:28) jul 26 11:04:05 localhost signal-desktop_signal-desktop.desktop[15673]: at WebContents.<anonymous> (node:electron/js2c/browser_init:2:83836) jul 26 11:04:05 localhost signal-desktop_signal-desktop.desktop[15673]: at WebContents.emit (node:events:518:28) -- Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Address sizes: 39 bits physical, 48 bits virtual Byte Order: Little Endian CPU(s): 4 On-line CPU(s) list: 0-3 Vendor ID: GenuineIntel BIOS Vendor ID: Intel(R) Corporation Model name: Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz BIOS Model name: Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz None CPU @ 2.5GHz BIOS CPU family: 205 CPU family: 6 Model: 142 Thread(s) per core: 2 Core(s) per socket: 2 Socket(s): 1 Stepping: 9 CPU(s) scaling MHz: 100% CPU max MHz: 3100,0000 CPU min MHz: 400,0000 BogoMIPS: 5399,81 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp vnmi md_clear flush_l1d arch_capabilities Virtualization: VT-x L1d cache: 64 KiB (2 instances) L1i cache: 64 KiB (2 instances) L2 cache: 512 KiB (2 instances) L3 cache: 3 MiB (1 instance) NUMA node(s): 1 NUMA node0 CPU(s): 0-3 Vulnerability Gather data sampling: Mitigation; Microcode Vulnerability Itlb multihit: KVM: Mitigation: VMX disabled Vulnerability L1tf: Mitigation; PTE Inversion; VMX conditional cache flushes, SMT vulnerable Vulnerability Mds: Mitigation; Clear CPU buffers; SMT vulnerable Vulnerability Meltdown: Mitigation; PTI Vulnerability Mmio stale data: Mitigation; Clear CPU buffers; SMT vulnerable Vulnerability Reg file data sampling: Not affected Vulnerability Retbleed: Mitigation; IBRS Vulnerability Spec rstack overflow: Not affected Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization Vulnerability Spectre v2: Mitigation; IBRS; IBPB conditional; STIBP conditional; RSB filling; PBRSB-eIBRS Not affected; BHI Not affected Vulnerability Srbds: Mitigation; Microcode Vulnerability Tsx async abort: Not affected
Had the issue again on my second boot this morning, trying to run ProtonMail and FreeTube. ``` SELinux is preventing check from mmap_zero access on the memprotect labeled spc_t. Plugin: mmap_zero SELinux has denied the check the ability to mmap low area of the kernel address space. The ability to mmap a low area of the address space is configured by /proc/sys/kernel/mmap_min_addr. Preventing such mappings helps protect against exploiting null deref bugs in the kernel. All applications that need this access should have already had policy written for them. If a compromised application tries to modify the kernel, this AVC would be generated. This is a serious issue. Your system may very well be compromised. If you do not think check should need to mmap low memory in the kernel. you may be under attack by a hacker, this is a very dangerous access. Contact your security administrator and report this issue. ``` ``` SELinux is preventing check from mmap_zero access on the memprotect labeled spc_t. ***** Plugin mmap_zero (53.1 confidence) suggests ************************* SELinux is preventing check from mmap_zero access on the memprotect labeled spc_t. Plugin: mmap_zero SELinux has denied the check the ability to mmap low area of the kernel address space. The ability to mmap a low area of the address space is configured by /proc/sys/kernel/mmap_min_addr. Preventing such mappings helps protect against exploiting null deref bugs in the kernel. All applications that need this access should have already had policy written for them. If a compromised application tries to modify the kernel, this AVC would be generated. This is a serious issue. Your system may very well be compromised. If you do not think check should need to mmap low memory in the kernel. you may be under attack by a hacker, this is a very dangerous access. Contact your security administrator and report this issue. If you do not think check should need to mmap low memory in the kernel. Then you may be under attack by a hacker, this is a very dangerous access. Do contact your security administrator and report this issue. ***** Plugin catchall_boolean (42.6 confidence) suggests ****************** If you want to control the ability to mmap a low area of the address space, as configured by /proc/sys/vm/mmap_min_addr. Then you must tell SELinux about this by enabling the 'mmap_low_allowed' boolean. Do setsebool -P mmap_low_allowed 1 ***** Plugin catchall (5.76 confidence) suggests ************************** If you believe that check should be allowed mmap_zero access on memprotect labeled spc_t by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'check' --raw | audit2allow -M my-check # semodule -X 300 -i my-check.pp Additional Information: Source Context system_u:system_r:spc_t:s0 Target Context system_u:system_r:spc_t:s0 Target Objects Unknown [ memprotect ] Source check Source Path check Port <Unknown> Host t570.fedora Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-40.24-1.fc40.noarch Local Policy RPM container-selinux-2.232.1-1.fc40.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name t570.fedora Platform Linux t570.fedora 6.9.10-200.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jul 18 21:39:30 UTC 2024 x86_64 Alert Count 3 First Seen 2024-07-27 07:06:22 CEST Last Seen 2024-07-27 08:07:32 CEST Local ID 1d91f36a-15aa-47eb-92ff-22b8875b6bfb Raw Audit Messages type=AVC msg=audit(1722060452.585:232): avc: denied { mmap_zero } for pid=1951 comm="check" scontext=system_u:system_r:spc_t:s0 tcontext=system_u:system_r:spc_t:s0 tclass=memprotect permissive=0 Hash: check,spc_t,spc_t,memprotect,mmap_zero ``` ``` SELinux is preventing freetube from using the execheap access on a process. Plugin: allow_execheap The freetube application attempted to change the access protection of memory on the heap (e.g., allocated using malloc). This is a potential security problem. Applications should not be doing this. Applications are sometimes coded incorrectly and request this permission. The SELinux Memory Protection Tests web page explains how to remove this requirement. If freetube does not work and you need it to work, you can configure SELinux temporarily to allow this access until the application is fixed. Please file a bug report against this package. If you do not think freetube should need to map heap memory that is both writable and executable. you need to report a bug. This is a potentially dangerous access. Contact your security administrator and report this issue. ``` ``` SELinux is preventing freetube from using the execheap access on a process. ***** Plugin allow_execheap (53.1 confidence) suggests ******************** If you do not think freetube should need to map heap memory that is both writable and executable. Then you need to report a bug. This is a potentially dangerous access. Do contact your security administrator and report this issue. ***** Plugin catchall_boolean (42.6 confidence) suggests ****************** If you want to allow unconfined executables to make their heap memory executable. Doing this is a really bad idea. Probably indicates a badly coded executable, but could indicate an attack. This executable should be reported in bugzilla Then you must tell SELinux about this by enabling the 'selinuxuser_execheap' boolean. Do setsebool -P selinuxuser_execheap 1 ***** Plugin catchall (5.76 confidence) suggests ************************** If you believe that freetube should be allowed execheap access on processes labeled unconfined_t by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'freetube' --raw | audit2allow -M my-freetube # semodule -X 300 -i my-freetube.pp Additional Information: Source Context unconfined_u:unconfined_r:unconfined_t:s0- s0:c0.c1023 Target Context unconfined_u:unconfined_r:unconfined_t:s0- s0:c0.c1023 Target Objects Unknown [ process ] Source freetube Source Path freetube Port <Unknown> Host t570.fedora Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-40.24-1.fc40.noarch Local Policy RPM selinux-policy-targeted-40.24-1.fc40.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name t570.fedora Platform Linux t570.fedora 6.9.10-200.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jul 18 21:39:30 UTC 2024 x86_64 Alert Count 116 First Seen 2024-07-26 23:09:10 CEST Last Seen 2024-07-27 08:15:31 CEST Local ID cd6ac61e-0a10-429f-822a-489840b5bc19 Raw Audit Messages type=AVC msg=audit(1722060931.867:360): avc: denied { execheap } for pid=4817 comm=50726F746F6E204D61696C20426574 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0 Hash: freetube,unconfined_t,unconfined_t,process,execheap ``` But then a second attempt at running ProtonMail, as well as Signal-Desktop, did not trigger the error. Later on, the issue triggered again, seemingly randomly and without perceptible effect, while I was running Freetube. ``` SELinux is preventing freetube from using the execheap access on a process. ***** Plugin allow_execheap (53.1 confidence) suggests ******************** If you do not think freetube should need to map heap memory that is both writable and executable. Then you need to report a bug. This is a potentially dangerous access. Do contact your security administrator and report this issue. ***** Plugin catchall_boolean (42.6 confidence) suggests ****************** If you want to allow unconfined executables to make their heap memory executable. Doing this is a really bad idea. Probably indicates a badly coded executable, but could indicate an attack. This executable should be reported in bugzilla Then you must tell SELinux about this by enabling the 'selinuxuser_execheap' boolean. Do setsebool -P selinuxuser_execheap 1 ***** Plugin catchall (5.76 confidence) suggests ************************** If you believe that freetube should be allowed execheap access on processes labeled unconfined_t by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'freetube' --raw | audit2allow -M my-freetube # semodule -X 300 -i my-freetube.pp Additional Information: Source Context unconfined_u:unconfined_r:unconfined_t:s0- s0:c0.c1023 Target Context unconfined_u:unconfined_r:unconfined_t:s0- s0:c0.c1023 Target Objects Unknown [ process ] Source freetube Source Path freetube Port <Unknown> Host t570.fedora Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-40.24-1.fc40.noarch Local Policy RPM selinux-policy-targeted-40.24-1.fc40.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name t570.fedora Platform Linux t570.fedora 6.9.10-200.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jul 18 21:39:30 UTC 2024 x86_64 Alert Count 117 First Seen 2024-07-26 23:09:10 CEST Last Seen 2024-07-27 08:47:20 CEST Local ID cd6ac61e-0a10-429f-822a-489840b5bc19 Raw Audit Messages type=AVC msg=audit(1722062840.260:459): avc: denied { execheap } for pid=9793 comm="slack" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0 Hash: freetube,unconfined_t,unconfined_t,process,execheap ```
(In reply to fen.giroux from comment #44) > Raw Audit Messages > type=AVC msg=audit(1722011850.707:218): avc: denied { mmap_zero } for pid=1946 comm="check" scontext=system_u:system_r:spc_t:s0 tcontext=system_u:system_r:spc_t:s0 tclass=memprotect permissive=0 That looks like Bug 2297712. What do you get for this? $ dnf -Cq list --installed qemu-user-static\*
When this issue is hit, Chromium spits out this error: [26921:1:0727/153659.413941:ERROR:v8_initializer.cc(792)] V8 process OOM (Failed to reserve virtual memory for CodeRange). This is coming from this line of code in v8: https://github.com/v8/v8/blob/main/src/heap/heap.cc#L5646 My best guess is that the part of code that is causing the execheap is this one, where exec permissions are set on the heap. https://github.com/v8/v8/blob/main/src/heap/code-range.cc#L242 Looking at blame, it could be one of these commits: https://github.com/v8/v8/commit/536571f811e9a51756b4b71f471dd3436b97a6bf https://github.com/v8/v8/commit/9da8b31f3b52d50c897207d727918545aed2dc34 I downloaded two separate builds of Chromium that are before and after this change, and verified that this package fails: https://www.googleapis.com/download/storage/v1/b/chromium-browser-snapshots/o/Linux_x64%2F1278692%2Fchrome-linux.zip?generation=1711497934327743&alt=media It also provided the following errors when it failed (probably because it's a dev build): libva error: /usr/lib64/dri/virtio_gpu_drv_video.so init failed [30580:30580:0727/161502.886545:ERROR:viz_main_impl.cc(167)] Exiting GPU process due to errors during initialization [30611:1:0727/161503.018919:ERROR:v8_initializer.cc(812)] V8 process OOM (Failed to reserve virtual memory for CodeRange). [30610:1:0727/161503.014690:ERROR:v8_initializer.cc(812)] V8 process OOM (Failed to reserve virtual memory for CodeRange). [0727/161503.079701:ERROR:file_io_posix.cc(145)] open /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq: No such file or directory (2) [0727/161503.080438:ERROR:file_io_posix.cc(145)] open /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq: No such file or directory (2) Received signal 4 ILL_ILLOPN 563ba5a2d60d #0 0x563ba59ee762 [0727/161503.264789:ERROR:file_io_posix.cc(145)] open /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq: No such file or directory (2) [0727/161503.278359:ERROR:file_io_posix.cc(145)] open /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq: No such file or directory (2) base::debug::CollectStackTrace() #1 0x563ba59dc322 Received signal 4 ILL_ILLOPN 563ba5a2d60d #0 0x563ba59ee762 base::debug::StackTrace::StackTrace() #2 0x563ba59ee181 base::debug::CollectStackTrace() #1 0x563ba59dc322 base::debug::(anonymous namespace)::StackDumpSignalHandler() #3 0x7fe4a358ddc0 (/usr/lib64/libc.so.6+0x19dbf) #4 0x563ba5a2d60d base::debug::StackTrace::StackTrace() #2 0x563ba59ee181 partition_alloc::internal::OnNoMemoryInternal() #5 0x563ba5a2d619 base::debug::(anonymous namespace)::StackDumpSignalHandler() #3 0x7fe4a358ddc0 (/usr/lib64/libc.so.6+0x19dbf) #4 0x563ba5a2d60d partition_alloc::TerminateBecauseOutOfMemory() #6 0x563ba5a2d636 partition_alloc::internal::OnNoMemoryInternal() #5 0x563ba5a2d619 partition_alloc::internal::OnNoMemory() #7 0x563ba8e871c0 partition_alloc::TerminateBecauseOutOfMemory() #6 0x563ba5a2d636 blink::ReportV8OOMError() #8 0x563ba24ce1bd v8::internal::V8::FatalProcessOutOfMemory() #9 0x563ba266a3a9 v8::internal::(anonymous namespace)::InitProcessWideCodeRange() #10 0x563ba774eeb0 partition_alloc::internal::OnNoMemory() #7 0x563ba8e871c0 v8::base::CallOnceImpl() #11 0x563ba266a2bf v8::internal::CodeRange::EnsureProcessWideCodeRange() #12 0x563ba26d579f v8::internal::Heap::SetUp() #13 0x563ba2641b69 v8::internal::Isolate::Init() #14 0x563ba2642789 v8::internal::Isolate::InitWithSnapshot() #15 0x563ba2ab8696 v8::internal::Snapshot::Initialize() #16 0x563ba24f3d07 v8::Isolate::Initialize() #17 0x563ba7b3c128 blink::ReportV8OOMError() #8 0x563ba24ce1bd v8::internal::V8::FatalProcessOutOfMemory() #9 0x563ba266a3a9 v8::internal::(anonymous namespace)::InitProcessWideCodeRange() #10 0x563ba774eeb0 gin::IsolateHolder::IsolateHolder() #18 0x563ba7b3be80 gin::IsolateHolder::IsolateHolder() #19 0x563ba9bdb925 v8::base::CallOnceImpl() #11 0x563ba266a2bf v8::internal::CodeRange::EnsureProcessWideCodeRange() #12 0x563ba26d579f v8::internal::Heap::SetUp() #13 0x563ba2641b69 v8::internal::Isolate::Init() #14 0x563ba2642789 v8::internal::Isolate::InitWithSnapshot() #15 0x563ba2ab8696 v8::internal::Snapshot::Initialize() #16 0x563ba24f3d07 v8::Isolate::Initialize() #17 0x563ba7b3c128 blink::V8PerIsolateData::V8PerIsolateData() #20 0x563ba9bdc240 gin::IsolateHolder::IsolateHolder() #18 0x563ba7b3be80 gin::IsolateHolder::IsolateHolder() #19 0x563ba9bdb925 blink::V8PerIsolateData::Initialize() #21 0x563ba8e87358 blink::V8PerIsolateData::V8PerIsolateData() #20 0x563ba9bdc240 blink::V8Initializer::InitializeMainThread() #22 0x563babcee2c4 content::RenderThreadImpl::InitializeWebKit() #23 0x563babcecf27 blink::V8PerIsolateData::Initialize() #21 0x563ba8e87358 blink::V8Initializer::InitializeMainThread() #22 0x563babcee2c4 content::RenderThreadImpl::Init() #24 0x563babcee0c3 content::RenderThreadImpl::RenderThreadImpl() #25 0x563babd1a594 content::RenderThreadImpl::InitializeWebKit() #23 0x563babcecf27 content::RendererMain() #26 0x563ba4e3e455 [30628:1:0727/161505.170072:ERROR:v8_initializer.cc(812)] V8 process OOM (Failed to reserve virtual memory for CodeRange). content::RenderThreadImpl::Init() #24 0x563babcee0c3 content::RunZygote() #27 0x563ba4e3ed54 [0727/161505.379972:ERROR:file_io_posix.cc(145)] open /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq: No such file or directory (2) [0727/161505.396322:ERROR:file_io_posix.cc(145)] open /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq: No such file or directory (2) Received signal 4 ILL_ILLOPN 563ba5a2d60d #0 0x563ba59ee762 [30540:30540:0727/161505.478039:ERROR:object_proxy.cc(576)] Failed to call method: org.freedesktop.ScreenSaver.GetActive: object_path= /org/freedesktop/ScreenSaver: org.freedesktop.DBus.Error.NotSupported: This method is not part of the idle inhibition specification: https://specifications.freedesktop.org/idle-inhibit-spec/latest/ content::RunOtherNamedProcessTypeMain() #28 0x563ba4e3fded base::debug::CollectStackTrace() #1 0x563ba59dc322 content::ContentMainRunnerImpl::Run() #29 0x563ba4e3d804 content::RunContentProcess() #30 0x563ba4e3da47 content::RenderThreadImpl::RenderThreadImpl() #25 0x563babd1a594 base::debug::StackTrace::StackTrace() #2 0x563ba59ee181 content::ContentMain() #31 0x563ba0fd935b content::RendererMain() #26 0x563ba4e3e455 base::debug::(anonymous namespace)::StackDumpSignalHandler() #3 0x7fe4a358ddc0 (/usr/lib64/libc.so.6+0x19dbf) #4 0x563ba5a2d60d content::RunZygote() #27 0x563ba4e3ed54 partition_alloc::internal::OnNoMemoryInternal() #5 0x563ba5a2d619 content::RunOtherNamedProcessTypeMain() #28 0x563ba4e3fded ChromeMain #32 0x7fe4a3577248 __libc_start_call_main #33 0x7fe4a357730b __libc_start_main_alias_2 #34 0x563ba0fd902a content::ContentMainRunnerImpl::Run() #29 0x563ba4e3d804 partition_alloc::TerminateBecauseOutOfMemory() #6 0x563ba5a2d636 content::RunContentProcess() #30 0x563ba4e3da47 partition_alloc::internal::OnNoMemory() #7 0x563ba8e871c0 content::ContentMain() #31 0x563ba0fd935b _start r8: 0000000000000000 r9: 00003120000acaf0 r10: 0000000000000000 r11: 0000000000000293 r12: 00007ffcd11f1ca0 r13: 00007ffcd11fa760 r14: 0000563b9e7d1207 r15: 00007ffcd11f1ca0 di: 00007ffcd11f1c48 si: 0000000000000000 bp: 00007ffcd11f1c50 bx: 0000000000000000 dx: 0000000000000000 ax: 0000000000000000 cx: 0000000000000004 sp: 00007ffcd11f1c40 ip: 0000563ba5a2d60d efl: 0000000000010202 cgf: 002b000000000033 erf: 0000000000000000 trp: 0000000000000006 msk: 0000000000000000 cr2: 0000000000000000 [end of stack trace] ../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall nr=0x25 arg1=0x5 arg2=0x7ffcd11f0770 arg3=0x0 arg4=0x8 Received signal 11 SEGV_MAPERR 000007005025 #0 0x563ba59ee762 blink::ReportV8OOMError() #8 0x563ba24ce1bd base::debug::CollectStackTrace() #1 0x563ba59dc322 v8::internal::V8::FatalProcessOutOfMemory() #9 0x563ba266a3a9 v8::internal::(anonymous namespace)::InitProcessWideCodeRange() #10 0x563ba774eeb0 base::debug::StackTrace::StackTrace() #2 0x563ba59ee181 v8::base::CallOnceImpl() #11 0x563ba266a2bf ChromeMainv8::internal::CodeRange::EnsureProcessWideCodeRange() #12 0x563ba26d579f #32 0x7fe4a3577248 __libc_start_call_main #33 0x7fe4a357730b __libc_start_main_alias_2 #34 0x563ba0fd902a v8::internal::Heap::SetUp() #13 0x563ba2641b69 v8::internal::Isolate::Init() #14 0x563ba2642789 v8::internal::Isolate::InitWithSnapshot() #15 0x563ba2ab8696 v8::internal::Snapshot::Initialize() #16 0x563ba24f3d07 v8::Isolate::Initialize() #17 0x563ba7b3c128 base::debug::(anonymous namespace)::StackDumpSignalHandler() #3 0x7fe4a358ddc0 (/usr/lib64/libc.so.6+0x19dbf) #4 0x563ba78d9294 sandbox::CrashSIGSYS_Handler() #5 0x563ba78dc54a gin::IsolateHolder::IsolateHolder() #18sandbox::Trap::SigSys() #6 0x7fe4a358ddc0 0x563ba7b3be80 (/usr/lib64/libc.so.6+0x19dbf) #7 0x7fe4a363224b __GI_alarm #8 0x563ba59ee6d8 base::debug::(anonymous namespace)::StackDumpSignalHandler() #9 0x7fe4a358ddc0 (/usr/lib64/libc.so.6+0x19dbf) #10 0x563ba5a2d60d _start r8: 0000000000000000 r9: 00003120000ad090 r10: 0000000000000000 r11: 0000000000000293 r12: 00007ffcd11f1ca0 r13: 00007ffcd11fa760 r14: 0000563b9e7d1207 r15: 00007ffcd11f1ca0 di: 00007ffcd11f1c48 si: 0000000000000000 bp: 00007ffcd11f1c50 bx: 0000000000000000 dx: 0000000000000000 ax: 0000000000000000 cx: 0000000000000004 sp: 00007ffcd11f1c40 ip: 0000563ba5a2d60d efl: 0000000000010202 cgf: 002b000000000033 erf: 0000000000000000 trp: 0000000000000006 msk: 0000000000000000 cr2: 0000000000000000 [end of stack trace] ../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall nr=0x25 arg1=0x5 arg2=0x7ffcd11f0770 arg3=0x0 arg4=0x8 Received signal 11 SEGV_MAPERR 000007005025 #0 0x563ba59ee762 partition_alloc::internal::OnNoMemoryInternal() #11 0x563ba5a2d619 libva error: /usr/lib64/dri/virtio_gpu_drv_video.so init failed [30629:30629:0727/161507.227659:ERROR:viz_main_impl.cc(167)] Exiting GPU process due to errors during initialization base::debug::CollectStackTrace() #1 0x563ba59dc322 gin::IsolateHolder::IsolateHolder()partition_alloc::TerminateBecauseOutOfMemory() #19 0x563ba9bdb925 #12 0x563ba5a2d636 base::debug::StackTrace::StackTrace() #2 0x563ba59ee181 partition_alloc::internal::OnNoMemory() #13 0x563ba8e871c0 base::debug::(anonymous namespace)::StackDumpSignalHandler() #3 0x7fe4a358ddc0 (/usr/lib64/libc.so.6+0x19dbf) #4 0x563ba78d9294 blink::ReportV8OOMError()blink::V8PerIsolateData::V8PerIsolateData() #20 0x563ba9bdc240 #14 0x563ba24ce1bd v8::internal::V8::FatalProcessOutOfMemory() #15 0x563ba266a3a9 v8::internal::(anonymous namespace)::InitProcessWideCodeRange() #16 0x563ba774eeb0 sandbox::CrashSIGSYS_Handler() #5 0x563ba78dc54a sandbox::Trap::SigSys() #6 0x7fe4a358ddc0 (/usr/lib64/libc.so.6+0x19dbf) #7 0x7fe4a363224b __GI_alarm #8 0x563ba59ee6d8 v8::base::CallOnceImpl() #17 0x563ba266a2bf blink::V8PerIsolateData::Initialize() #21 0x563ba8e87358 v8::internal::CodeRange::EnsureProcessWideCodeRange() #18 0x563ba26d579f v8::internal::Heap::SetUp() #19 0x563ba2641b69 blink::V8Initializer::InitializeMainThread() #22 0x563babcee2c4 base::debug::(anonymous namespace)::StackDumpSignalHandler() #9 0x7fe4a358ddc0 (/usr/lib64/libc.so.6+0x19dbf) #10 0x563ba5a2d60d v8::internal::Isolate::Init() #20 0x563ba2642789 v8::internal::Isolate::InitWithSnapshot() #21 0x563ba2ab8696 v8::internal::Snapshot::Initialize() #22 0x563ba24f3d07 partition_alloc::internal::OnNoMemoryInternal()v8::Isolate::Initialize() #11 0x563ba5a2d619 #23 0x563ba7b3c128 content::RenderThreadImpl::InitializeWebKit() #23 0x563babcecf27 partition_alloc::TerminateBecauseOutOfMemory() #12 0x563ba5a2d636 gin::IsolateHolder::IsolateHolder() #24 0x563ba7b3be80 partition_alloc::internal::OnNoMemory() #13 0x563ba8e871c0 gin::IsolateHolder::IsolateHolder() #25 0x563ba9bdb925 content::RenderThreadImpl::Init() #24 0x563babcee0c3 content::RenderThreadImpl::RenderThreadImpl() #25 0x563babd1a594 blink::V8PerIsolateData::V8PerIsolateData() #26 0x563ba9bdc240 blink::ReportV8OOMError() #14 0x563ba24ce1bd v8::internal::V8::FatalProcessOutOfMemory() #15 0x563ba266a3a9 v8::internal::(anonymous namespace)::InitProcessWideCodeRange() #16 0x563ba774eeb0 content::RendererMain() #26 0x563ba4e3e455 content::RunZygote() #27 0x563ba4e3ed54 blink::V8PerIsolateData::Initialize() #27 0x563ba8e87358 v8::base::CallOnceImpl() #17 0x563ba266a2bf v8::internal::CodeRange::EnsureProcessWideCodeRange() #18 0x563ba26d579f content::RunOtherNamedProcessTypeMain() #28 0x563ba4e3fded v8::internal::Heap::SetUp() #19 0x563ba2641b69 v8::internal::Isolate::Init() #20 0x563ba2642789 v8::internal::Isolate::InitWithSnapshot() #21 0x563ba2ab8696 content::ContentMainRunnerImpl::Run() #29 0x563ba4e3d804 blink::V8Initializer::InitializeMainThread()v8::internal::Snapshot::Initialize() #22 0x563ba24f3d07 #28 0x563babcee2c4 v8::Isolate::Initialize() #23 0x563ba7b3c128 content::RunContentProcess() #30 0x563ba4e3da47 content::RenderThreadImpl::InitializeWebKit() #29 0x563babcecf27 content::ContentMain() #31 0x563ba0fd935b gin::IsolateHolder::IsolateHolder() #24 0x563ba7b3be80 content::RenderThreadImpl::Init() #30 0x563babcee0c3 gin::IsolateHolder::IsolateHolder() #25 0x563ba9bdb925 libva error: /usr/lib64/dri/virtio_gpu_drv_video.so init failed ChromeMain #32 0x7fe4a3577248 __libc_start_call_main #33 0x7fe4a357730b __libc_start_main_alias_2 #34 0x563ba0fd902a [30655:30655:0727/161509.788414:ERROR:viz_main_impl.cc(167)] Exiting GPU process due to errors during initialization content::RenderThreadImpl::RenderThreadImpl() #31 0x563babd1a594 blink::V8PerIsolateData::V8PerIsolateData() #26 0x563ba9bdc240 content::RendererMain() #32 0x563ba4e3e455 _start r8: 0000000000000000 r9: 00003120000addb0 r10: 0000000000000000 r11: 0000000000000293 r12: 00007ffcd11f1ca0 r13: 00007ffcd11fa760 r14: 0000563b9e7d1207 r15: 00007ffcd11f1ca0 di: 00007ffcd11f1c48 si: 0000000000000000 bp: 00007ffcd11f1c50 bx: 0000000000000000 dx: 0000000000000000 ax: 0000000000000000 cx: 0000000000000004 sp: 00007ffcd11f1c40 ip: 0000563ba5a2d60d efl: 0000000000010202 cgf: 002b000000000033 erf: 0000000000000000 trp: 0000000000000006 msk: 0000000000000000 cr2: 0000000000000000 [end of stack trace] ../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall nr=0x25 arg1=0x5 arg2=0x7ffcd11f0770 arg3=0x0 arg4=0x8 Received signal 11 SEGV_MAPERR 000007005025 #0 0x563ba59ee762 content::RunZygote() #33 0x563ba4e3ed54 blink::V8PerIsolateData::Initialize() #27 0x563ba8e87358 base::debug::CollectStackTrace() #1 0x563ba59dc322 content::RunOtherNamedProcessTypeMain() #34 0x563ba4e3fded base::debug::StackTrace::StackTrace() #2 0x563ba59ee181 content::ContentMainRunnerImpl::Run() #35 0x563ba4e3d804 blink::V8Initializer::InitializeMainThread() #28 0x563babcee2c4 base::debug::(anonymous namespace)::StackDumpSignalHandler() #3 0x7fe4a358ddc0 (/usr/lib64/libc.so.6+0x19dbf) #4 0x563ba78d9294 content::RunContentProcess() #36 0x563ba4e3da47 sandbox::CrashSIGSYS_Handler() #5 0x563ba78dc54a content::ContentMain() #37 0x563ba0fd935b sandbox::Trap::SigSys() #6 0x7fe4a358ddc0 (/usr/lib64/libc.so.6+0x19dbf) #7 0x7fe4a363224b __GI_alarm #8 0x563ba59ee6d8 content::RenderThreadImpl::InitializeWebKit() #29 0x563babcecf27 base::debug::(anonymous namespace)::StackDumpSignalHandler() #9 0x7fe4a358ddc0 (/usr/lib64/libc.so.6+0x19dbf) #10 0x563ba5a2d60d partition_alloc::internal::OnNoMemoryInternal() #11 0x563ba5a2d619 libva error: /usr/lib64/dri/virtio_gpu_drv_video.so init failed partition_alloc::TerminateBecauseOutOfMemory() #12 0x563ba5a2d636 partition_alloc::internal::OnNoMemory() #13 0x563ba8e871c0 ChromeMain #38 0x7fe4a3577248 __libc_start_call_main #39 0x7fe4a357730b __libc_start_main_alias_2 #40 0x563ba0fd902a content::RenderThreadImpl::Init() #30 0x563babcee0c3 blink::ReportV8OOMError() #14 0x563ba24ce1bd v8::internal::V8::FatalProcessOutOfMemory() #15 0x563ba266a3a9 v8::internal::(anonymous namespace)::InitProcessWideCodeRange() #16 0x563ba774eeb0 _start r8: 0000000000000025 r9: 0000000000000025 r10: 0000000000000025 r11: 0000000000000246 r12: 0000312000018600 r13: 00007ffcd11f0200 r14: 0000000000000025 r15: 0000000000000003 di: 0000000000000002 si: 0000563b9eba8828 bp: 00007ffcd11f0100 bx: 00007ffcd11f0130 dx: 0000000000000001 ax: 0000000000005000 cx: 0000000007005025 sp: 00007ffcd11f00f0 ip: 0000563ba78d9294 efl: 0000000000010202 cgf: 002b000000000033 erf: 0000000000000006 trp: 000000000000000e msk: 0000000000000008 cr2: 0000000007005025 [end of stack trace] ../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall nr=0x25 arg1=0x5 arg2=0x7ffcd11eec30 arg3=0x0 arg4=0x8 v8::base::CallOnceImpl() #17 0x563ba266a2bf v8::internal::CodeRange::EnsureProcessWideCodeRange() #18 0x563ba26d579f v8::internal::Heap::SetUp() #19 0x563ba2641b69 v8::internal::Isolate::Init() #20 0x563ba2642789 content::RenderThreadImpl::RenderThreadImpl()v8::internal::Isolate::InitWithSnapshot() #31 0x563babd1a594 #21 0x563ba2ab8696 v8::internal::Snapshot::Initialize() #22 0x563ba24f3d07 v8::Isolate::Initialize() #23 0x563ba7b3c128 gin::IsolateHolder::IsolateHolder() #24 0x563ba7b3be80 content::RendererMain() #32 0x563ba4e3e455 gin::IsolateHolder::IsolateHolder() #25 0x563ba9bdb925 blink::V8PerIsolateData::V8PerIsolateData() #26 0x563ba9bdc240 content::RunZygote() #33 0x563ba4e3ed54 content::RunOtherNamedProcessTypeMain() #34 0x563ba4e3fded blink::V8PerIsolateData::Initialize() #27 0x563ba8e87358 content::ContentMainRunnerImpl::Run() #35 0x563ba4e3d804 blink::V8Initializer::InitializeMainThread() #28 0x563babcee2c4 content::RunContentProcess() #36 0x563ba4e3da47 content::ContentMain() #37 0x563ba0fd935b content::RenderThreadImpl::InitializeWebKit() #29 0x563babcecf27 ChromeMain #38 0x7fe4a3577248 __libc_start_call_main #39 0x7fe4a357730b __libc_start_main_alias_2 #40 0x563ba0fd902a content::RenderThreadImpl::Init() #30 0x563babcee0c3 content::RenderThreadImpl::RenderThreadImpl() #31 0x563babd1a594 _start r8: 0000000000000025 r9: 0000000000000025 r10: 0000000000000025 r11: 0000000000000246 r12: 0000312000018600 r13: 00007ffcd11f0200 r14: 0000000000000025 r15: 0000000000000003 di: 0000000000000002 si: 0000563b9eba8828 bp: 00007ffcd11f0100 bx: 00007ffcd11f0130 dx: 0000000000000001 ax: 0000000000005000 cx: 0000000007005025 sp: 00007ffcd11f00f0 ip: 0000563ba78d9294 efl: 0000000000010202 cgf: 002b000000000033 erf: 0000000000000006 trp: 000000000000000e msk: 0000000000000008 cr2: 0000000007005025 [end of stack trace] ../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall nr=0x25 arg1=0x5 arg2=0x7ffcd11eec30 arg3=0x0 arg4=0x8 content::RendererMain() #32 0x563ba4e3e455 content::RunZygote() #33 0x563ba4e3ed54 content::RunOtherNamedProcessTypeMain() #34 0x563ba4e3fded content::ContentMainRunnerImpl::Run() #35 0x563ba4e3d804 content::RunContentProcess() #36 0x563ba4e3da47 content::ContentMain() #37 0x563ba0fd935b ChromeMain #38 0x7fe4a3577248 __libc_start_call_main #39 0x7fe4a357730b __libc_start_main_alias_2 #40 0x563ba0fd902a _start r8: 0000000000000025 r9: 0000000000000025 r10: 0000000000000025 r11: 0000000000000246 r12: 0000312000018600 r13: 00007ffcd11f0200 r14: 0000000000000025 r15: 0000000000000003 di: 0000000000000002 si: 0000563b9eba8828 bp: 00007ffcd11f0100 bx: 00007ffcd11f0130 dx: 0000000000000001 ax: 0000000000005000 cx: 0000000007005025 sp: 00007ffcd11f00f0 ip: 0000563ba78d9294 efl: 0000000000010202 cgf: 002b000000000033 erf: 0000000000000006 trp: 000000000000000e msk: 0000000000000008 cr2: 0000000007005025 [end of stack trace] ../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall nr=0x25 arg1=0x5 arg2=0x7ffcd11eec30 arg3=0x0 arg4=0x8 [30708:1:0727/161516.389369:ERROR:v8_initializer.cc(812)] V8 process OOM (Failed to reserve virtual memory for CodeRange). [0727/161516.471585:ERROR:file_io_posix.cc(145)] open /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq: No such file or directory (2) [0727/161516.474769:ERROR:file_io_posix.cc(145)] open /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq: No such file or directory (2) Received signal 4 ILL_ILLOPN 563ba5a2d60d #0 0x563ba59ee762 base::debug::CollectStackTrace() #1 0x563ba59dc322 base::debug::StackTrace::StackTrace() #2 0x563ba59ee181 base::debug::(anonymous namespace)::StackDumpSignalHandler() #3 0x7fe4a358ddc0 (/usr/lib64/libc.so.6+0x19dbf) #4 0x563ba5a2d60d partition_alloc::internal::OnNoMemoryInternal() #5 0x563ba5a2d619 partition_alloc::TerminateBecauseOutOfMemory() #6 0x563ba5a2d636 partition_alloc::internal::OnNoMemory() #7 0x563ba8e871c0 [30540:30540:0727/161517.069966:ERROR:service_worker_task_queue.cc(247)] DidStartWorkerFail gphhapmejobijbbhgpjhcjognlahblep: 3 blink::ReportV8OOMError() #8 0x563ba24ce1bd v8::internal::V8::FatalProcessOutOfMemory() #9 0x563ba266a3a9 v8::internal::(anonymous namespace)::InitProcessWideCodeRange() #10 0x563ba774eeb0 v8::base::CallOnceImpl() #11 0x563ba266a2bf v8::internal::CodeRange::EnsureProcessWideCodeRange() #12 0x563ba26d579f v8::internal::Heap::SetUp() #13 0x563ba2641b69 v8::internal::Isolate::Init() #14 0x563ba2642789 v8::internal::Isolate::InitWithSnapshot() #15 0x563ba2ab8696 v8::internal::Snapshot::Initialize() #16 0x563ba24f3d07 v8::Isolate::Initialize() #17 0x563ba7b3c128 gin::IsolateHolder::IsolateHolder() #18 0x563ba7b3be80 gin::IsolateHolder::IsolateHolder() #19 0x563ba9bdb925 blink::V8PerIsolateData::V8PerIsolateData() #20 0x563ba9bdc240 blink::V8PerIsolateData::Initialize() #21 0x563ba8e87358 blink::V8Initializer::InitializeMainThread() #22 0x563babcee2c4 content::RenderThreadImpl::InitializeWebKit() #23 0x563babcecf27 content::RenderThreadImpl::Init() #24 0x563babcee0c3 content::RenderThreadImpl::RenderThreadImpl() #25 0x563babd1a594 content::RendererMain() #26 0x563ba4e3e455 content::RunZygote() #27 0x563ba4e3ed54 content::RunOtherNamedProcessTypeMain() #28 0x563ba4e3fded content::ContentMainRunnerImpl::Run() #29 0x563ba4e3d804 content::RunContentProcess() #30 0x563ba4e3da47 content::ContentMain() #31 0x563ba0fd935b ChromeMain #32 0x7fe4a3577248 __libc_start_call_main #33 0x7fe4a357730b __libc_start_main_alias_2 #34 0x563ba0fd902a _start r8: 0000000000000000 r9: 00003120000acb90 r10: 0000000000000000 r11: 0000000000000293 r12: 00007ffcd11f1ca0 r13: 00007ffcd11fa760 r14: 0000563b9e7d1207 r15: 00007ffcd11f1ca0 di: 00007ffcd11f1c48 si: 0000000000000000 bp: 00007ffcd11f1c50 bx: 0000000000000000 dx: 0000000000000000 ax: 0000000000000000 cx: 0000000000000004 sp: 00007ffcd11f1c40 ip: 0000563ba5a2d60d efl: 0000000000010202 cgf: 002b000000000033 erf: 0000000000000000 trp: 0000000000000006 msk: 0000000000000000 cr2: 0000000000000000 [end of stack trace] ../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall nr=0x25 arg1=0x5 arg2=0x7ffcd11f0770 arg3=0x0 arg4=0x8 Received signal 11 SEGV_MAPERR 000007005025 But this package never fails: https://www.googleapis.com/download/storage/v1/b/chromium-browser-snapshots/o/Linux_x64%2F1275350%2Fchrome-linux.zip?generation=1710899169649141&alt=media So it would appear to be an issue with Chromium/V8, not the Linux kernel.
(In reply to reisner.marc from comment #48) > So it would appear to be an issue with Chromium/V8, not the Linux kernel. See the list of duplicates at the top of the bug report.
It's been well-established that all of these issues are on Chromium based applications (including Electron based applications)
The SELinux description of the wine-preloader execheap violation attempt says this is an attempt "to allow unconfined executables to make their heap memory exeucutable" and that "Doing this is a really bad idea" and probably the result of "a badly coded executable". Sure sounds like something in Chrome that might become exploitable by rogue or infected websites or Extensions to execute arbitrary dynamic code to the detriment of the integrity of the running system. It doesn't really make any difference whether this is the result of SELinux recognizing an exposure that should be restricted and tightening the rules, or a recent change in Chrome that has started to require occasional use of this level of authority -- either way the Chrome browser is wanting to do something that could be a potential security & availability issue on the system running Chrome, should there be bugs or a design flaw in Chrome that permitted the dynamic execution of code from an untrusted or infected source. Obviously one way to make the error disappear would be to alter the SELinux rules to allow Chrome to to have this level of access; but the much safer course is to eliminate Chrome's need for this access -- and possibly fail more gracefully if there is some web page or AddOn Extension flaw responsible for the failure. It's interesting that the usual response I see is some failure to load a web page and the SELinux error when I follow a link in a document or email that starts Chrome, but if I restart Chrome enough times it seems to start running normally with no more SELinux errors. It's almost as if some offending process finally gives up stops running until another day.
(In reply to reisner.marc from comment #50) > It's been well-established that all of these issues are on Chromium based applications (including Electron based applications) See if you can make your case in 30 lines of exposition with carefully chosen snippets of relevant debug output instead of in 379 lines of mostly raw debug output, as in Comment 48. Create an attachment for that.
(In reply to reisner.marc from comment #50) > It's been well-established that all of these issues are on Chromium based applications (including Electron based applications) Now that I have chromium installed in an F41 Workstation VM, what is your exact reproducer? Chromium has dozens, if not hundreds of settings, including some that explicitly refer to memory or that allocate memory: Performance:Memory Saver Performance:Preload pages, in particular. See, also: System:Continue running background apps when Chromium is closed How do you have those configured?
I also have a fresh rawhide 41 VM. I didn't configure anything. Very easy to repro(In reply to Steve from comment #53) > (In reply to reisner.marc from comment #50) > > It's been well-established that all of these issues are on Chromium based applications (including Electron based applications) > > Now that I have chromium installed in an F41 Workstation VM, what is your > exact reproducer? > > Chromium has dozens, if not hundreds of settings, including some that > explicitly refer to memory or that allocate memory: > > Performance:Memory Saver > Performance:Preload pages, in particular. > > See, also: > > System:Continue running background apps when Chromium is closed > > How do you have those configured? I also installed a fresh rawhide F41 VM. I was going to start doing a kernel bisect but I figured I'd first try a Chromium bisect. After looking through the Chromium source code to find where it sets execute permissions using mprotect(2), I did not find many parts of the code base that did that. So I found a fairly recent commit (from March) that I thought might be suspect and downloaded a Chromium build from before and after that commit. The SELinux execheap denial does not happen every time you start Chrome/Chromium but it eventually happens after restarting it many times. So it's actually difficult to do a bisect because it doesn't happen every single time. However, as I mentioned, I wasn't able to reproduce the execheap denial on the older build and the newer build triggered it immediately. Reproducing doesn't require any particular configuration - I have no configuration at all in my fresh install of rawhide. I'm not sure why you're bringing a completely different issue (related to mmap_zero) into this bug that many people have reported. I just noticed that there wasn't much movement on this BZ so I tried my hand at debugging, hoping it was helpful. This probably needs to ultimately be reported to the Chromium project. Additionally, in reviewing the code that triggers the execheap denials, it is not doing anything particularly novel, and the original problem patch just looked like a refactor. So it doesn't make sense that this would be a kernel bug. In fact, I'm not sure that the original fix for this issue makes any sense (changing >= to > and <= to <), though I am very very far from understanding any of this mm code.
Thanks, Marc. I just reproduced it in an F41 Workstation VM. After starting chromium from the command-line, I browsed to getfedora.org. No chromium-based applications are involved. $ /usr/bin/chromium-browser [4015:1:0728/013722.235750:ERROR:v8_initializer.cc(809)] V8 process OOM (Failed to reserve virtual memory for CodeRange). ... $ sudo ausearch -i -ts recent -m avc ---- type=PROCTITLE msg=audit(07/28/2024 01:37:22.235:252) : proctitle=/usr/lib64/chromium-browser/chromium-browser --type=renderer --crashpad-handler-pid=3954 --enable-crash-reporter=,Fedora Project type=SYSCALL msg=audit(07/28/2024 01:37:22.235:252) : arch=x86_64 syscall=mprotect success=no exit=EACCES(Permission denied) a0=0x557ee0000000 a1=0x20000000 a2=PROT_READ|PROT_WRITE|PROT_EXEC a3=0x20000000 items=0 ppid=3963 pid=4015 auid=joeblow uid=joeblow gid=joeblow euid=joeblow suid=joeblow fsuid=joeblow egid=joeblow sgid=joeblow fsgid=joeblow tty=pts0 ses=3 comm=chromium-browse exe=/usr/lib64/chromium-browser/chromium-browser subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(07/28/2024 01:37:22.235:252) : avc: denied { execheap } for pid=4015 comm=chromium-browse scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0 ---- type=PROCTITLE msg=audit(07/28/2024 01:37:22.260:253) : proctitle=/usr/lib64/chromium-browser/chromium-browser --type=renderer --crashpad-handler-pid=3954 --enable-crash-reporter=,Fedora Project type=SYSCALL msg=audit(07/28/2024 01:37:22.260:253) : arch=x86_64 syscall=mprotect success=no exit=EACCES(Permission denied) a0=0x557ee0000000 a1=0x20000000 a2=PROT_READ|PROT_WRITE|PROT_EXEC a3=0x20000000 items=0 ppid=3963 pid=4021 auid=joeblow uid=joeblow gid=joeblow euid=joeblow suid=joeblow fsuid=joeblow egid=joeblow sgid=joeblow fsgid=joeblow tty=pts0 ses=3 comm=chromium-browse exe=/usr/lib64/chromium-browser/chromium-browser subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(07/28/2024 01:37:22.260:253) : avc: denied { execheap } for pid=4021 comm=chromium-browse scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0 Tested in an F41 Workstation VM with: chromium-126.0.6478.182-2.fc41.x86_64 selinux-policy-41.11-1.fc41.noarch systemd-256.4-1.fc41.x86_64 kernel 6.11.0-0.rc0.20240726git1722389b0d86.14.fc41.x86_64
(In reply to reisner.marc from comment #54) > This probably needs to ultimately be reported to the Chromium project. I completely agree. I don't have the authority to change the component to "chromium", but some of the CC members do. > I'm not sure why you're bringing a completely different issue (related to mmap_zero) into this bug that many people have reported. I didn't. Fen reported it in Comment 44, so I referred him to Bug 2297712. However, I just noticed that all those qemu-user-static packages are installed in my F41 Workstation VM. $ dnf -C list --installed qemu-user-static\* They can be safely removed, because nothing depends on them.
Marc: See if you have any core files: $ ls -1 /var/lib/systemd/coredump/core.chromium* /var/lib/systemd/coredump/core.chromium-browse.1000.d83abb89aacf4f65bd4a3d2e5b0de8d9.4015.1722130642000000.zst /var/lib/systemd/coredump/core.chromium-browse.1000.d83abb89aacf4f65bd4a3d2e5b0de8d9.4021.1722130642000000.zst I extracted one with: $ xdg-open /var/lib/systemd/coredump/core.chromium-browse.1000.d83abb89aacf4f65bd4a3d2e5b0de8d9.4015.1722130642000000.zst It isn't empty, but gdb wouldn't show a backtrace. You clearly know a lot more about gdb than I do, so maybe you can get something out of them. BTW, abrt didn't see those. I found them after running "locate chromium".
I have a number of core dumps. There actually looks to be two per crash, but they look very similar. Looks like they need to be zstd decompressed. Here is the backtrace from the last one: #0 0x0000563ba78d9294 in sandbox::CrashSIGSYS_Handler(arch_seccomp_data const&, void*) () #1 0x0000563ba78dc54a in sandbox::Trap::SigSys(int, siginfo_t*, ucontext_t*) () #2 <signal handler called> #3 0x00007fe4a363224b in __GI_alarm () at ../sysdeps/unix/syscall-template.S:120 #4 0x0000563ba59ee6d8 in base::debug::(anonymous namespace)::StackDumpSignalHandler(int, siginfo_t*, void*) () #5 <signal handler called> #6 0x0000563ba78d9294 in sandbox::CrashSIGSYS_Handler(arch_seccomp_data const&, void*) () #7 0x0000563ba78dc54a in sandbox::Trap::SigSys(int, siginfo_t*, ucontext_t*) () #8 <signal handler called> #9 0x00007fe4a363224b in __GI_alarm () at ../sysdeps/unix/syscall-template.S:120 #10 0x0000563ba59ee6d8 in base::debug::(anonymous namespace)::StackDumpSignalHandler(int, siginfo_t*, void*) () #11 <signal handler called> #12 0x0000563ba5a2d60d in partition_alloc::internal::OnNoMemoryInternal(unsigned long) () #13 0x0000563ba5a2d619 in partition_alloc::TerminateBecauseOutOfMemory(unsigned long) () #14 0x0000563ba5a2d636 in partition_alloc::internal::OnNoMemory(unsigned long) () #15 0x0000563ba8e871c0 in blink::ReportV8OOMError(char const*, v8::OOMDetails const&) () #16 0x0000563ba24ce1bd in v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) () #17 0x0000563ba266a3a9 in v8::internal::(anonymous namespace)::InitProcessWideCodeRange(v8::PageAllocator*, unsigned long) () #18 0x0000563ba774eeb0 in v8::base::CallOnceImpl(std::__Cr::atomic<unsigned char>*, std::__Cr::function<void ()>) () #19 0x0000563ba266a2bf in v8::internal::CodeRange::EnsureProcessWideCodeRange(v8::PageAllocator*, unsigned long) () #20 0x0000563ba26d579f in v8::internal::Heap::SetUp(v8::internal::LocalHeap*) () #21 0x0000563ba2641b69 in v8::internal::Isolate::Init(v8::internal::SnapshotData*, v8::internal::SnapshotData*, v8::internal::SnapshotData*, bool) () #22 0x0000563ba2642789 in v8::internal::Isolate::InitWithSnapshot(v8::internal::SnapshotData*, v8::internal::SnapshotData*, v8::internal::SnapshotData*, bool) () #23 0x0000563ba2ab8696 in v8::internal::Snapshot::Initialize(v8::internal::Isolate*) () #24 0x0000563ba24f3d07 in v8::Isolate::Initialize(v8::Isolate*, v8::Isolate::CreateParams const&) () #25 0x0000563ba7b3c128 in gin::IsolateHolder::IsolateHolder(scoped_refptr<base::SingleThreadTaskRunner>, gin::IsolateHolder::AccessMode, gin::IsolateHolder::IsolateType, std::__Cr::unique_ptr<v8::Isolate::CreateParams, std::__Cr::default_delete<v8::Isolate::CreateParams> >, gin::IsolateHolder::IsolateCreationMode, scoped_refptr<base::SingleThreadTaskRunner>) () #26 0x0000563ba7b3be80 in gin::IsolateHolder::IsolateHolder(scoped_refptr<base::SingleThreadTaskRunner>, gin::IsolateHolder::AccessMode, gin::IsolateHolder::AllowAtomicsWaitMode, gin::IsolateHolder::IsolateType, gin::IsolateHolder::IsolateCreationMode, void* (*)(char const*, int, int, unsigned long), void (*)(void*, int), scoped_refptr<base::SingleThreadTaskRunner>) () #27 0x0000563ba9bdb925 in blink::V8PerIsolateData::V8PerIsolateData(scoped_refptr<base::SingleThreadTaskRunner>, scoped_refptr<base::SingleThreadTaskRunner>, blink::V8PerIsolateData::V8ContextSnapshotMode, void* (*)(char const*, int, int, unsigned long), void (*)(void*, int)) () #28 0x0000563ba9bdc240 in blink::V8PerIsolateData::Initialize(scoped_refptr<base::SingleThreadTaskRunner>, scoped_refptr<base::SingleThreadTaskRunner>, blink::V8PerIsolateData::V8ContextSnapshotMode, void* (*)(char const*, int, int, unsigned long), void (*)(void*, int)) () #29 0x0000563ba8e87358 in blink::V8Initializer::InitializeMainThread() () #30 0x0000563babcee2c4 in content::RenderThreadImpl::InitializeWebKit(mojo::BinderMap*) () #31 0x0000563babcecf27 in content::RenderThreadImpl::Init() () #32 0x0000563babcee0c3 in content::RenderThreadImpl::RenderThreadImpl(base::RepeatingCallback<void ()>, std::__Cr::unique_ptr<blink::scheduler::WebThreadScheduler, std::__Cr::default_delete<blink::scheduler::WebThreadScheduler> >) () #33 0x0000563babd1a594 in content::RendererMain(content::MainFunctionParams) () #34 0x0000563ba4e3e455 in content::RunZygote(content::ContentMainDelegate*) () #35 0x0000563ba4e3ed54 in content::RunOtherNamedProcessTypeMain(std::__Cr::basic_string<char, std::__Cr::char_traits<char>, std::__Cr::allocator<char> > const&, content::MainFunctionParams, content::ContentMainDelegate*) () #36 0x0000563ba4e3fded in content::ContentMainRunnerImpl::Run() () #37 0x0000563ba4e3d804 in content::RunContentProcess(content::ContentMainParams, content::ContentMainRunner*) () #38 0x0000563ba4e3da47 in content::ContentMain(content::ContentMainParams) () #39 0x0000563ba0fd935b in ChromeMain () #40 0x00007fe4a3577248 in __libc_start_call_main (main=main@entry=0x563ba0fd90f0 <main>, argc=argc@entry=5, argv=argv@entry=0x7ffcd11fc3b8) at ../sysdeps/nptl/libc_start_call_main.h:58 #41 0x00007fe4a357730b in __libc_start_main_impl (main=0x563ba0fd90f0 <main>, argc=5, argv=0x7ffcd11fc3b8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffcd11fc3a8) at ../csu/libc-start.c:360 #42 0x0000563ba0fd902a in _start () The interesting frames in this backtrace are 16 and 17 - it's pretty clear that it's crashing at this line: https://github.com/v8/v8/blob/536571f811e9a51756b4b71f471dd3436b97a6bf/src/heap/code-range.cc#L476 The only reason it would crash with FatalProcessOutOfMemory is because InitReservation returns false. And the InitReservation method is the one that had the change in March that is suspect. However, it's not that helpful to look at a coredump from March, so I also reproduced on the most recent Chromium build (https://download-chromium.appspot.com/). Here is the backtrace: #0 0x00005594a814f604 in sandbox::CrashSIGSYS_Handler(arch_seccomp_data const&, void*) () #1 0x00005594a81528bd in sandbox::Trap::SigSys(int, siginfo_t*, ucontext_t*) () #2 <signal handler called> #3 0x00007f1d417e824b in __GI_alarm () at ../sysdeps/unix/syscall-template.S:120 #4 0x00005594a61619b8 in base::debug::(anonymous namespace)::StackDumpSignalHandler(int, siginfo_t*, void*) () #5 <signal handler called> #6 0x00005594a814f604 in sandbox::CrashSIGSYS_Handler(arch_seccomp_data const&, void*) () #7 0x00005594a81528bd in sandbox::Trap::SigSys(int, siginfo_t*, ucontext_t*) () #8 <signal handler called> #9 0x00007f1d417e824b in __GI_alarm () at ../sysdeps/unix/syscall-template.S:120 #10 0x00005594a61619b8 in base::debug::(anonymous namespace)::StackDumpSignalHandler(int, siginfo_t*, void*) () #11 <signal handler called> #12 0x00005594a61a1a2d in partition_alloc::internal::OnNoMemoryInternal(unsigned long) () #13 0x00005594a61a1a39 in partition_alloc::TerminateBecauseOutOfMemory(unsigned long) () #14 0x00005594a61a1a56 in partition_alloc::internal::OnNoMemory(unsigned long) () #15 0x00005594a9738c20 in blink::ReportV8OOMError(char const*, v8::OOMDetails const&) () #16 0x00005594a279551d in v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) () #17 0x00005594a2a7fe42 in v8::internal::(anonymous namespace)::InitCodeRangeOnce(std::__Cr::unique_ptr<v8::internal::CodeRange, std::__Cr::default_delete<v8::internal::CodeRange> >*, v8::PageAllocator*, unsigned long) () #18 0x00005594a7fb18b0 in v8::base::CallOnceImpl(std::__Cr::atomic<unsigned char>*, std::__Cr::function<void ()>) () #19 0x00005594a2a7fd2c in v8::internal::IsolateGroup::EnsureCodeRange(unsigned long) () #20 0x00005594a29aee7c in v8::internal::Heap::SetUp(v8::internal::LocalHeap*) () #21 0x00005594a2920730 in v8::internal::Isolate::Init(v8::internal::SnapshotData*, v8::internal::SnapshotData*, v8::internal::SnapshotData*, bool) () #22 0x00005594a2921479 in v8::internal::Isolate::InitWithSnapshot(v8::internal::SnapshotData*, v8::internal::SnapshotData*, v8::internal::SnapshotData*, bool) () #23 0x00005594a2db6385 in v8::internal::Snapshot::Initialize(v8::internal::Isolate*) () #24 0x00005594a27bf9b2 in v8::Isolate::Initialize(v8::Isolate*, v8::Isolate::CreateParams const&) () #25 0x00005594a839b4e5 in gin::IsolateHolder::IsolateHolder(scoped_refptr<base::SingleThreadTaskRunner>, gin::IsolateHolder::AccessMode, gin::IsolateHolder::IsolateType, std::__Cr::unique_ptr<v8::Isolate::CreateParams, std::__Cr::default_delete<v8::Isolate::CreateParams> >, gin::IsolateHolder::IsolateCreationMode, scoped_refptr<base::SingleThreadTaskRunner>) () #26 0x00005594a839b250 in gin::IsolateHolder::IsolateHolder(scoped_refptr<base::SingleThreadTaskRunner>, gin::IsolateHolder::AccessMode, gin::IsolateHolder::AllowAtomicsWaitMode, gin::IsolateHolder::IsolateType, gin::IsolateHolder::IsolateCreationMode, void* (*)(char const*, int, int, unsigned long), void (*)(void*, int), scoped_refptr<base::SingleThreadTaskRunner>) () #27 0x00005594aa522b82 in blink::V8PerIsolateData::V8PerIsolateData(scoped_refptr<base::SingleThreadTaskRunner>, scoped_refptr<base::SingleThreadTaskRunner>, blink::V8PerIsolateData::V8ContextSnapshotMode, void* (*)(char const*, int, int, unsigned long), void (*)(void*, int)) () #28 0x00005594aa523510 in blink::V8PerIsolateData::Initialize(scoped_refptr<base::SingleThreadTaskRunner>, scoped_refptr<base::SingleThreadTaskRunner>, blink::V8PerIsolateData::V8ContextSnapshotMode, void* (*)(char const*, int, int, unsigned long), void (*)(void*, int)) () #29 0x00005594a9738db8 in blink::V8Initializer::InitializeMainThread() () #30 0x00005594ac532b94 in content::RenderThreadImpl::InitializeWebKit(mojo::BinderMap*) () #31 0x00005594ac53181e in content::RenderThreadImpl::Init() () #32 0x00005594ac532997 in content::RenderThreadImpl::RenderThreadImpl(base::RepeatingCallback<void ()>, std::__Cr::unique_ptr<blink::scheduler::WebThreadScheduler, std::__Cr::default_delete<blink::scheduler::WebThreadScheduler> >) () #33 0x00005594ac55fad7 in content::RendererMain(content::MainFunctionParams) () #34 0x00005594a55e034a in content::RunZygote(content::ContentMainDelegate*) () #35 0x00005594a55e0c78 in content::RunOtherNamedProcessTypeMain(std::__Cr::basic_string<char, std::__Cr::char_traits<char>, std::__Cr::allocator<char> > const&, content::MainFunctionParams, --Type <RET> for more, q to quit, c to continue without paging--c content::ContentMainDelegate*) () #36 0x00005594a55e1e07 in content::ContentMainRunnerImpl::Run() () #37 0x00005594a55df6d2 in content::RunContentProcess(content::ContentMainParams, content::ContentMainRunner*) () #38 0x00005594a55df917 in content::ContentMain(content::ContentMainParams) () #39 0x00005594a11be380 in ChromeMain () #40 0x00007f1d4172d248 in __libc_start_call_main (main=main@entry=0x5594a11be0f0 <main>, argc=argc@entry=5, argv=argv@entry=0x7fff11e11c28) at ../sysdeps/nptl/libc_start_call_main.h:58 #41 0x00007f1d4172d30b in __libc_start_main_impl (main=0x5594a11be0f0 <main>, argc=5, argv=0x7fff11e11c28, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff11e11c18) at ../csu/libc-start.c:360 #42 0x00005594a11be02a in _start () This time it is pointing to an issue here: https://github.com/v8/v8/blob/e2e9a750521e5c6c3c1fcddd24a37c6d5846f1bb/src/init/isolate-group.cc#L153 However, it still looks like the problematic method is InitReservation, because that method returning false is the only way that FatalProcessOutOfMemory is called. I am not an expert in any of this, just a casual observer trying to contribute to an issue that many people using Fedora are having. I could open a bug report with Chromium and communicate my findings but I am not sure I am the best person to do so as I am not that familiar with the SELinux/kernel side of things. I also am no expert on Chromium/v8 code, just literate in `git blame` and looking at stack traces.
Well, nevermind. I was also able to reproduce on the build I couldn't originally reproduce on. Just takes a lot of tries.
Marc: Thanks for looking at the core dumps. The two core dumps correspond to the two AVCs. They are linked by the PIDs. Comment 55 shows pid=4015 and pid=4021 in the two AVCs. In Comment 57, those PIDs are in the two core dump file names.
(In reply to reisner.marc from comment #58) > I could open a bug report with Chromium and communicate my findings but I am not sure I am the best person to do so as I am not that familiar with the SELinux/kernel side of things. Thanks for all your help with this. We don't need to debug this further or even open an upstream bug report -- only make a case that the Fedora Bugzilla component should be changed to "chromium". And I believe that you have done that. Indeed, there already is such a bug under the "chromium" component, albeit with much less detail than this one: Bug 2299033 - SELinux is preventing chromium-browse from using the execheap access on a process.
This strace command captured the syscall traces for the three processes (12501, 12502, 12592) that triggered "execheap" AVCs. Attachments to follow. $ strace -ff -o cb-1.strace /usr/bin/chromium-browser $ sudo ausearch -i -ts recent -m avc ---- type=PROCTITLE msg=audit(07/28/2024 07:29:16.722:905) : proctitle=/usr/lib64/chromium-browser/chromium-browser --type=renderer --crashpad-handler-pid=12438 --enable-crash-reporter=,Fedora Projec type=SYSCALL msg=audit(07/28/2024 07:29:16.722:905) : arch=x86_64 syscall=mprotect success=no exit=EACCES(Permission denied) a0=0x55b5e0000000 a1=0x20000000 a2=PROT_READ|PROT_WRITE|PROT_EXEC a3=0x20000000 items=0 ppid=12447 pid=12501 auid=joeblow uid=joeblow gid=joeblow euid=joeblow suid=joeblow fsuid=joeblow egid=joeblow sgid=joeblow fsgid=joeblow tty=pts0 ses=3 comm=chromium-browse exe=/usr/lib64/chromium-browser/chromium-browser subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(07/28/2024 07:29:16.722:905) : avc: denied { execheap } for pid=12501 comm=chromium-browse scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0 ---- type=PROCTITLE msg=audit(07/28/2024 07:29:16.730:906) : proctitle=/usr/lib64/chromium-browser/chromium-browser --type=renderer --crashpad-handler-pid=12438 --enable-crash-reporter=,Fedora Projec type=SYSCALL msg=audit(07/28/2024 07:29:16.730:906) : arch=x86_64 syscall=mprotect success=no exit=EACCES(Permission denied) a0=0x55b5e0000000 a1=0x20000000 a2=PROT_READ|PROT_WRITE|PROT_EXEC a3=0x20000000 items=0 ppid=12447 pid=12502 auid=joeblow uid=joeblow gid=joeblow euid=joeblow suid=joeblow fsuid=joeblow egid=joeblow sgid=joeblow fsgid=joeblow tty=pts0 ses=3 comm=chromium-browse exe=/usr/lib64/chromium-browser/chromium-browser subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(07/28/2024 07:29:16.730:906) : avc: denied { execheap } for pid=12502 comm=chromium-browse scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0 ---- type=PROCTITLE msg=audit(07/28/2024 07:29:26.987:909) : proctitle=/usr/lib64/chromium-browser/chromium-browser --type=renderer --crashpad-handler-pid=12438 --enable-crash-reporter=,Fedora Projec type=SYSCALL msg=audit(07/28/2024 07:29:26.987:909) : arch=x86_64 syscall=mprotect success=no exit=EACCES(Permission denied) a0=0x55b5e0000000 a1=0x20000000 a2=PROT_READ|PROT_WRITE|PROT_EXEC a3=0x20000000 items=0 ppid=12447 pid=12592 auid=joeblow uid=joeblow gid=joeblow euid=joeblow suid=joeblow fsuid=joeblow egid=joeblow sgid=joeblow fsgid=joeblow tty=pts0 ses=3 comm=chromium-browse exe=/usr/lib64/chromium-browser/chromium-browser subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(07/28/2024 07:29:26.987:909) : avc: denied { execheap } for pid=12592 comm=chromium-browse scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0
Created attachment 2040642 [details] strace log for process 12501
Created attachment 2040643 [details] strace log for process 12502
Created attachment 2040644 [details] strace log for process 12592
The three attached strace logs are somewhat redundant, but all three show the mprotect() syscall that returns the EACCES corresponding to the "execheap" AVC. Note that lines 463 and 465 show syscalls that return an error. Chromium could be erroneously ignoring those error returns. The write() in line 472 is for the error message that is displayed on the terminal. $ fgrep -n -C8 EACCES cb-1.strace.12501 458-mprotect(0x1d9c0058c000, 32768, PROT_READ|PROT_WRITE) = 0 459-mprotect(0x1d9c00594000, 32768, PROT_READ|PROT_WRITE) = 0 460-getpid() = 1 461-mprotect(0x1d9c0059c000, 65536, PROT_READ|PROT_WRITE) = 0 462-gettid() = 1 463-openat(AT_FDCWD, "/proc/self/maps", O_RDONLY) = -1 EPERM (Operation not permitted) 464-mmap(0x55b5e0000000, 536870912, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x55b5e0000000 465-prctl(PR_SET_VMA, PR_SET_VMA_ANON_NAME, 0x55b5e0000000, 536870912, "v8") = -1 EINVAL (Invalid argument) 466:mprotect(0x55b5e0000000, 536870912, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EACCES (Permission denied) 467-socketpair(AF_UNIX, SOCK_SEQPACKET, 0, [18, 26]) = 0 468-sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\20\0\0\0 \0\0\0\10\0\0\0L\363\245f\0\0\0\0", iov_len=20}], msg_iovlen=1, msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, cmsg_data=[26]}], msg_controllen=20, msg_flags=0}, MSG_NOSIGNAL) = 20 469-close(26) = 0 470-recvmsg(18, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="0\0\0\0\20\0\0\0\35\0\0\0\7\0\0\0\34\0\0\0\6\0\0\0|\0\0\0\0\0\0\0"..., iov_len=512}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 52 471-close(18) = 0 472-write(2, "[12501:1:0728/072916.723814:ERRO"..., 123) = 123 473---- SIGTRAP {si_signo=SIGTRAP, si_code=SI_KERNEL, si_addr=NULL} --- 474-gettid() = 1
BTW, most of cb-1.strace.12501 is a sequence of these: --- SIGILL {si_signo=SIGILL, si_code=ILL_ILLOPN, si_addr=0x55b59c7bd146} --- That suggests a bug in the way signal handling is implemented.
There are two bug reports on Chromium itself: https://issues.chromium.org/issues/348464586 https://issues.chromium.org/issues/350117526
(In reply to Thomas Duckworth from comment #68) > There are two bug reports on Chromium itself: > https://issues.chromium.org/issues/348464586 > https://issues.chromium.org/issues/350117526 Thanks for pointing that out. Marc: Here is an automated reproducer. This shell script repeatedly starts and kills chromium-browser. Eventually, an AVC will occur. For convenience, resize your terminal window so that it occupies the lower half of the desktop and resize chromium so that it occupies the upper half. $ cat x1.sh #!/usr/bin/bash while [ 1 ] ; do date echo @ chromium-browser /usr/bin/chromium-browser & sleep 5 echo @ pkill chromium pkill chromium sleep 1 done
(In reply to Steve from comment #69) > This shell script repeatedly starts and kills chromium-browser. Eventually, an AVC will occur. Disabling the kernel's virtual memory randomizer seems to suppress the AVCs. Procedure: $ sudo su Get current value: # cat /proc/sys/kernel/randomize_va_space 2 Disable: # echo 0 > /proc/sys/kernel/randomize_va_space From another terminal tab, run the shell script in Comment 69 (not as root). Tip: If you don't want to watch the script while it is running, run aureport in a terminal tab so that you can compare the report with a later report: $ sudo aureport -ts boot -a | tail -1 Documentation: " norandmaps Don't use address space randomization. Equivalent to echo 0 > /proc/sys/kernel/randomize_va_space" The kernel’s command-line parameters https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html
*** Bug 2300189 has been marked as a duplicate of this bug. ***
*** Bug 2300243 has been marked as a duplicate of this bug. ***
*** Bug 2301000 has been marked as a duplicate of this bug. ***
Still occurs with kernel 6.11.0-0.rc1.20240730git94ede2a3e913.17.fc41.x86_64: https://bodhi.fedoraproject.org/updates/FEDORA-2024-5630b0ad30 BTW, there is a kernel upstream bug report dated 2023-12-12 with a C code reproducer: Bug_218258 - SELinux mprotect EACCES/execheap for memory segment directly adjacent to heap https://bugzilla.kernel.org/show_bug.cgi?id=218258 The bug report also links to a commit dated 2023-12-12 that was merged with the kernel mainline: mm: fix VMA heap bounds checking https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d3bb89ea9c13e5a98d2b7a0ba8e50a77893132cb
*** Bug 2299033 has been marked as a duplicate of this bug. ***
@omosnace Hi, can you please check whether the commit from comment 74 is present in currently stable kernels in Fedora? Anyone else, can you try to confirm whether this bug still occurs if you install and run kernel 6.5 or older? (Because the kernel bugzilla claims it started happening in kernel 6.6). This would help to determine whether this is still a kernel issue (perhaps the fix from comment 74 didn't fix it completely), or whether it might be a genuine problem caused by the chromium stack.
No AVCs with 100 iterations of my robo-reproducer and kernel 6.5.12-300.fc39.x86_64: https://koji.fedoraproject.org/koji/buildinfo?buildID=2322803 And here is an updated robo-reproducer script that adds an iteration counter: $ cat cb-execheap-test-1.sh #!/usr/bin/bash # $Revision: 1.3 $ n=1 while [ 1 ] ; do echo -e "\n> $((n++))" date uname -r echo @ chromium-browser /usr/bin/chromium-browser & sleep 5 echo @ pkill chromium pkill chromium sleep 1 done Usage is simple: $ ./cb-execheap-test-1.sh > 1 Wed Jul 31 08:04:23 AM UTC 2024 6.5.12-300.fc39.x86_64 @ chromium-browser libva error: /usr/lib64/dri/virtio_gpu_drv_video.so init failed [25600:25600:0731/080424.126219:ERROR:object_proxy.cc(576)] Failed to call method: org.freedesktop.ScreenSaver.GetActive: object_path= /org/freedesktop/ScreenSaver: org.freedesktop.DBus.Error.NotSupported: This method is not part of the idle inhibition specification: https://specifications.freedesktop.org/idle-inhibit-spec/latest/ @ pkill chromium ... Press control-c to terminate.
It would also be useful is someone else could confirm that no "execheap" AVCs occur when the kernel's virtual memory randomizer is disabled. Comment 70 describes the procedure. Detailed documentation is here: Documentation for /proc/sys/kernel/ randomize_va_space https://www.kernel.org/doc/html/latest/admin-guide/sysctl/kernel.html?highlight=kptr_restrict#randomize-va-space
(In reply to Steve from comment #78) > It would also be useful is someone else could confirm that no "execheap" > AVCs occur when the kernel's virtual memory randomizer is disabled. I will try that. Regarding Comment #77 was that with randomize_va_space set to 2 or 0? Because I can confirm I am still seeing this problem with kernel-6.9.12-200.fc40.x86_64 and randomize_va_space set to its default of 2. In my case it is from an Electron App (Discord).
(In reply to Ian Laurie from comment #79) > I will try that. Regarding Comment #77 was that with randomize_va_space set to 2 or 0? Because I can confirm I am still seeing this problem with kernel-6.9.12-200.fc40.x86_64 and randomize_va_space set to its default of 2. In my case it is from an Electron App (Discord). In Comment 77, the test with kernel 6.5.12-300.fc39.x86_64 was with randomize_va_space set to the default value of 2 -- full randomization.
In the three attached strace logs, mmap() returns the same virtual address. If the virtual memory randomizer* is working, shouldn't they each be different? Snippets from the attached strace logs. The first number is the process ID as recorded in the file name when "strace -ff" was run: 12501: mmap(0x55b5e0000000, 536870912, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x55b5e0000000 12502: mmap(0x55b5e0000000, 536870912, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x55b5e0000000 12592: mmap(0x55b5e0000000, 536870912, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x55b5e0000000 * Documentation for /proc/sys/kernel/ randomize_va_space https://www.kernel.org/doc/html/latest/admin-guide/sysctl/kernel.html#randomize-va-space
(In reply to Steve from comment #81) > If the virtual memory randomizer* is working, shouldn't they each be different? I should have read mmap(2) first: "If addr is NULL, then the kernel chooses the (page-aligned) address at which to create the mapping; this is the most portable method of creating a new mapping. If addr is not NULL, then the kernel takes it as a hint about where to place the mapping; ..." So, why are all three processes specifying the same address: 0x55b5e0000000? The three attached strace logs don't show where that address came from, but presumably it is from a single parent process. So why do they all need to be the same? Doesn't that defeat the purpose of virtual memory address randomization?
The first call to mmap() in the three attached strace logs returns the same address in all three processes. The first argument is "NULL", so virtual memory address randomization doesn't seem to be working in that case: mmap(NULL, 16384, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f36467ea000
Just a quick comment from a Chromium perspective: this is likely to be an issue with SELinux (or the kernel at large, or perhaps Fedora's configuration of them). The fact that Chromium (or, more specifically, V8) needs memory that's writable and executable (at least sometimes) is working as intended, and has always been that way, that's how JIT compilers work. To the best of my knowledge, this memory is always mmap'ed, never malloc'ed (IIUC, the SELinux error *could* be meaning to indicate that it is the latter, which would make me suspect misdetection of some sort on SELinux's part). FWIW, other browsers are generally in the same boat: in the last decade or two, every high-performance JavaScript engine has been using JIT compilation, which by definition means writing generated code into memory and then executing it. Folks who are concerned that this is "dangerous" aren't wrong: for the vast majority of applications on a system, you wouldn't want them to generate code at runtime. JIT-compiling language runtimes (JS engines, JVM, Mono, PyPy, LuaJIT, ...) are the big exception to this rule of thumb. I have no specific hypothesis why this started to become a problem only recently, nor do I have any in-depth knowledge of SELinux. Perhaps some detail changed slightly regarding how exactly V8 reserves the respective memory range. Perhaps changes to SELinux changed how/whether this is now being detected/reported. If V8 needs to make minor changes to make SELinux's life easier, it might be feasible to accommodate that (I can't promise anything, it depends on the nature of the changes; if you have specific suggestions you can comment on https://issues.chromium.org/issues/350117526). But the basic fact that V8 needs to write into memory and then execute it will remain, I can promise that much :) . And since previous comments here suggest that things were working fine with an older kernel and aren't working with a newer kernel, I'd think that it should probably be fixed in the kernel somehow.
Thanks a lot for your comment, Jakob. So we now need to figure out whether it's a kernel issue or a selinux issue. (The fact that older kernels work fine points to the kernel as being the more likely cause). And if it is kernel, whether the patch mentioned in comment 74 is in Fedora already or not, and if it is, update the kernel bugzilla with some technical details explaining that this is not fixed yet.
(In reply to Jakob Kummerow from comment #84) > The fact that Chromium (or, more specifically, V8) needs memory that's writable and executable (at least sometimes) is working as intended, The attached strace logs are from a chromium-browser run in which the "execheap" AVC occurred. Correlating the error returns in the strace logs with the chromium code would be very useful. For example, the "strace log for process 12501" attachment shows these two syscalls: mmap(0x1b9e22116000, 524288, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x1b9e22116000 prctl(PR_SET_VMA, PR_SET_VMA_ANON_NAME, 0x1b9e22116000, 524288, "v8") = -1 EINVAL (Invalid argument) How does chromium handle that error return? Comment 66 has an strace log snippet with this sequence of syscalls, which includes the mprotect() call that corresponds to the "execheap" AVC. How does chromium handle the error returns from the openat() and the prctl() syscalls? openat(AT_FDCWD, "/proc/self/maps", O_RDONLY) = -1 EPERM (Operation not permitted) mmap(0x55b5e0000000, 536870912, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x55b5e0000000 prctl(PR_SET_VMA, PR_SET_VMA_ANON_NAME, 0x55b5e0000000, 536870912, "v8") = -1 EINVAL (Invalid argument) mprotect(0x55b5e0000000, 536870912, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EACCES (Permission denied)
I've had this error on several (all) Fedora workstations now; my "work-around" that seems to work is "dnf reinstall chromium-browser". The error sometimes come back when you update the selinux-policies. Reinstall, and you can use chromium (or Chrome or vscode).
(In reply to Kamil Páral from comment #76) > ... whether the commit from comment 74 is present in currently stable kernels in Fedora? The commit is in the kernel stable 6.9.y branch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/include/linux/mm.h?h=linux-6.9.y&id=d3bb89ea9c13e5a98d2b7a0ba8e50a77893132cb The change is in include/linux/mm.h, and it is relatively simple, so a visual inspection of the kernel source code can confirm its presence. Fedora kernel 6.9.4-100 has it (I just happened to have that one already): $ fgrep -A4 vma_is_initial_heap linux-6.9.4/include/linux/mm.h static inline bool vma_is_initial_heap(const struct vm_area_struct *vma) { return vma->vm_start < vma->vm_mm->brk && vma->vm_end > vma->vm_mm->start_brk; }
(In reply to Steve from comment #86) > For example, the "strace log for process 12501" attachment shows these two syscalls: > > mmap(0x1b9e22116000, 524288, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x1b9e22116000 > prctl(PR_SET_VMA, PR_SET_VMA_ANON_NAME, 0x1b9e22116000, 524288, "v8") = -1 EINVAL (Invalid argument) > > How does chromium handle that error return? Chromium should have exited with a fatal error, because EINVAL should *never* be returned during normal operation. That is a chromium bug. However, that also confirms that this "execheap" AVC is not due to a chromium bug. See the F41 documentation (man-pages-6.9.1-2.fc41): PR_SET_VMA (2const) - set an attribute for virtual memory areas There are only two possible reasons for an EINVAL return: ERRORS EINVAL attr is not a valid attribute. EINVAL addr is an invalid address. PR_SET_VMA_ANON_NAME is certainly "a valid attribute". Indeed, it is the only possible attribute in this case. The address, 0x1b9e22116000, should also be valid, since it was just returned by mmap(). The man page should also explicitly mention the remaining arguments, but they are obviously valid too.
This feedback may now be redundant, but FWIW I've not seen the issue since setting /proc/sys/kernel/randomize_va_space to 0.
(In reply to Ian Laurie from comment #90) > This feedback may now be redundant, but FWIW I've not seen the issue since setting /proc/sys/kernel/randomize_va_space to 0. Thanks for confirming that. That seems like a reasonable workaround until this problem is resolved. For anyone who wants to try that as a workaround, "norandmaps" can be added to the kernel command-line.[1] Alternatively, the sysctl command can be used: $ sysctl kernel/randomize_va_space kernel.randomize_va_space = 2 $ sudo sysctl kernel/randomize_va_space=0 kernel.randomize_va_space = 0 Documentation: $ whatis -s 8 sysctl systemd-sysctl.service sysctl (8) - configure kernel parameters at runtime systemd-sysctl.service (8) - Configure kernel parameters at boot Documentation for /proc/sys/kernel/ https://www.kernel.org/doc/html/latest/admin-guide/sysctl/kernel.html#randomize-va-space [1] https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html
(In reply to Steve from comment #89) > > How does chromium handle that error return? > > Chromium should have exited with a fatal error, because EINVAL should > *never* be returned during normal operation. That is a chromium bug. Chromium has a multi-process architecture. The "renderer" process (which is responsible for providing one tab's contents) that requested rwx memory and didn't get it *did* exit with a fatal error. The "browser" process (which is responsible for rendering the main UI) does not terminate when a renderer crashes for any reason; that's by design, and that's why there is this multi-process architecture to begin with. From a user's perspective, a crashing renderer while the browser process lives on manifests as an "Aw, Snap" tab.
I have this problem on VSCode, VSCodium and Brave. They all start, but crash rendering the UI. It seems to be related to Electron/Chromium? I'll try the workaround (https://bugzilla.redhat.com/show_bug.cgi?id=2254434#c91), but has this been reported to the kernel/chrome-project I cannot find a ticket) yet.
(In reply to Steve from comment #88) > The change is in include/linux/mm.h, and it is relatively simple, so a > visual inspection of the kernel source code can confirm its presence. > > Fedora kernel 6.9.4-100 has it (I just happened to have that one already): Thanks. I pinged people in the kernel bugzilla, asking if they can look into this: https://bugzilla.kernel.org/show_bug.cgi?id=218258
(In reply to Jakob Kummerow from comment #92) > (In reply to Steve from comment #89) > > > How does chromium handle that error return? Process 12501 should have exited with a fatal error on the *first* EINVAL, yet it continued execution: $ fgrep -n EINVAL cb-1.strace.12501 146:prctl(PR_SET_VMA, PR_SET_VMA_ANON_NAME, 0x1b9e22116000, 524288, "v8") = -1 EINVAL (Invalid argument) 150:prctl(PR_SET_VMA, PR_SET_VMA_ANON_NAME, 0x110400000000, 8589934592, "v8") = -1 EINVAL (Invalid argument) 449:prctl(PR_SET_VMA, PR_SET_VMA_ANON_NAME, 0x3c9100000000, 1073741824, "v8") = -1 EINVAL (Invalid argument) 465:prctl(PR_SET_VMA, PR_SET_VMA_ANON_NAME, 0x55b5e0000000, 536870912, "v8") = -1 EINVAL (Invalid argument) So the answer is obvious. Chromium is incorrectly ignoring error returns from some syscalls. That is a coding mistake and a chromium bug.
(In reply to Jakob Kummerow from comment #92) > Chromium has a multi-process architecture. Right. And "strace -ff" logs each process *separately*. See Comment 62, Comment 66, and the "strace" man page: strace (1) - trace system calls and signals
(In reply to Kamil Páral from comment #94) > Thanks. I pinged people in the kernel bugzilla, asking if they can look into this: > https://bugzilla.kernel.org/show_bug.cgi?id=218258 Thanks, Kamil.
Jakob: Here is another class of chromium bugs: $ fgrep -n EFAULT cb-1.strace.12501 204:prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, NULL) = -1 EFAULT (Bad address) 207:prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, NULL) = -1 EFAULT (Bad address) 208:seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) 219:seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_SPEC_ALLOW, NULL) = -1 EFAULT (Bad address) Obviously, a NULL pointer is not going to work as a filter. :-) See the F41 documentation: $ whatis PR_SET_SECCOMP seccomp PR_SET_SECCOMP (2const) - set the secure computing mode EFAULT mode is SECCOMP_MODE_FILTER, and filter is an invalid address. seccomp (2) - operate on Secure Computing state of the process EFAULT args was not a valid address.
Steve, are any of these a likely cause for this bug in question? We should stay focused on the execheap problem and not discuss arbitrary Chromium coding errors, unless you highly suspect them to be related, otherwise this bug report will get unreadable. Given that the execheap problem doesn't happen with kernel 6.5, doesn't that suggest that this is not caused by Chromium?
Regarding some of the earlier discussion about whether this is a kernel problem or an SELinux problem, I think maybe another perspective might be useful. My impression is that SELinux and the kernel are tightly integrated -- SELinux in some places is dwescribed as a collection of patches tot the kernel. Is it possible that the use by wine-preloader of execheap access has recently been identified as something being exploited by malware? If so, perhaps the protected resources or the rules for access have been tightened to prevent its use in default contexts -- perhaps rightly so. The execheap authority may not be a power you would want an arbitrary untrusted program to have, in which case perhaps the problem may be that Chrome is running the code in question as an unconfined_t process. If Chrome legitimately requires authorities that shouldn't be granted to unknown programs, maybe it is time to consider special SELinux support to run some of Chrome in a different process context? Just a thought. I also noticed an earlier comment indicating that any other modern browser should be having the same issue. I haven't noticed this execheap issue with Firefox 128.0 (running under Fedora 39 with kernel 6.9.11-100), and Firefox also seems to be running as an unconfined_t process. Until today I have used Chrome as my default browser and only occasionally used Firefox. I have changed Firefox to be my default browser to see if it is possible they have found some way to avoid this issue, or perhaps more frequent usage will induce the same random failures there also.
Kamil: Point taken. Joel: That earlier comment is Comment 84. Jakob is a Chromium developer. Try running "strace -ff" on Firefox and look for mprotect() syscalls like this one from Comment 66: mprotect(0x55b5e0000000, 536870912, PROT_READ|PROT_WRITE|PROT_EXEC) ^^^^^^^^^ Doc: strace (1) - trace system calls and signals
(In reply to Kamil Páral from comment #99) > ... unless you highly suspect them to be related ... Comment 95: Those prctl->EINVAL syscall errors occur in the same process as the mprotect->EACCES syscall error that was triggered by selinux. Further, the prctl->EINVAL syscall errors occur *before* the mprotect->EACCES syscall error. If chromium is fixed to correctly exit with a fatal error on the first prctl->EINVAL error, I predict that the "execheap" AVCs will disappear. However, there will still be a bug, because those prctl() syscalls appear to be valid, as explained in Comment 89. Comment 98: Spurious syscalls should never occur in production code. In debug or testing code they might be acceptable. The problem is that syscalls that supposedly don't do anything could still have side-effects on timing and sequencing in a multi-process architecture. Thanks for prompting me to clarify my thinking.
(In reply to Joel C Ewing from comment #100) > The execheap authority may not be a power you would want an arbitrary untrusted program to have, ... Chromium implements sandboxes for that code. Sandboxed processes execute within a very restrictive environment. A web search will find much more. Containers are conceptually similar. See "docker" and "podman", which are both available as Fedora packages.
(In reply to Steve from comment #103) > (In reply to Joel C Ewing from comment #100) > > The execheap authority may not be a power you would want an arbitrary untrusted program to have, ... > > Chromium implements sandboxes for that code. BTW, the attachment, "strace log for process 12501", is for a process executing as a sandboxed process. The kernel "knows" that the process id is 12501, but the process itself "thinks" its process id is 1. See the getpid() syscall in line 3 of the attachment. See clone(2) for how that is implemented. Sandboxes make interpreting strace logs even more difficult than they already are. :-)
(In reply to Steve from comment #102) > (In reply to Kamil Páral from comment #99) > > ... unless you highly suspect them to be related ... ... > Comment 98: Spurious syscalls should never occur in production code. ... I am retracting my interpretation of the syscalls in Comment 98. After downloading the 3.8G chromium source rpm, extracting it, and grepping through the source code, I have determined conclusively that those syscalls are *intentional*. Specifically, chromium is trying to determine "if the kernel supports seccomp-filter" by making a prctl() syscall or a seccomp() syscall to probe the kernel and to see what the kernel returns: https://github.com/chromium/chromium/blob/89170039febe1ab353255d4651c621adca070d69/sandbox/linux/seccomp-bpf/sandbox_bpf.cc#L47 https://github.com/chromium/chromium/blob/89170039febe1ab353255d4651c621adca070d69/sandbox/linux/seccomp-bpf/sandbox_bpf.cc#L86 That is a terrible way to determine kernel capabilities, but, without explicit kernel support for capability queries, there might not be a better way to do it. NB: I am using "capability" in a different sense from the way it is used in capabilities(7).
It looks like those getrandom(2) calls are done in order to randomize the address space, and the value gotten from getrandom(2) is masked and then passed to mmap. https://github.com/v8/v8/blob/b85492a46dfbb53a31ae98a77819291e635e2203/src/base/platform/platform-posix.cc#L315 I was able to create a small reproducer C program: #include <stdio.h> #include <stdint.h> #include <string.h> #include <unistd.h> #include <errno.h> #include <sys/mman.h> #include <linux/prctl.h> #include <sys/prctl.h> #include <sys/random.h> int main(void) { uintptr_t raw_addr; getrandom(&raw_addr, sizeof(raw_addr), 0); raw_addr &= 0x3FFFFFFFF000; void* pointer = mmap((void *)raw_addr, 536870912, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); prctl(PR_SET_VMA, PR_SET_VMA_ANON_NAME, pointer, 536870912, "v8"); if (mprotect(pointer, 536870912, PROT_READ | PROT_WRITE | PROT_EXEC) == -1) { printf("%s", strerror(errno)); return 1; } return 0; } If I run it in a loop like this, it eventually exits with "Permission denied", and I get the avc. $ while true; do ./a.out || break; done Permission denied
Great work, Marc! $ sudo true # So we don't get asked for a password later. $ time while true; do ./a.out || break; done ; sudo ausearch -ts now -m avc 841735: Permission denied real 3m1.374s user 1m37.799s sys 1m37.185s ---- time->Sun Aug 4 02:09:26 2024 type=PROCTITLE msg=audit(1722737366.196:411): proctitle="./a.out" type=SYSCALL msg=audit(1722737366.196:411): arch=c000003e syscall=10 success=no exit=-13 a0=97ab000 a1=20000000 a2=7 a3=0 items=0 ppid=2545 pid=841735 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=3 comm="a.out" exe="/home/joeblow/src/a.out" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1722737366.196:411): avc: denied { execheap } for pid=841735 comm="a.out" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0 == I added a getpid() call for correlation with the AVC: $ rcsdiff -r1.1 -u0 y1.c ... - printf("%s", strerror(errno)); + printf("%d: %s\n", getpid(), strerror(errno)); ==
(In reply to Steve from comment #107) > Great work, Marc! It's possible that this avc is legitimate. However, it does seem like there is some randomness at play (either in Chromium or kernel code) which is why it takes a number of tries to trigger the avc.
It exits immediately with strace, but there is no output and no AVC. $ strace -ttt -o y1.strace ./a.out The prctl() syscall in line 29 returns EINVAL: $ cat -n y1.strace # Breaking my 30 line rule ... :-) 1 1722739010.782887 execve("./a.out", ["./a.out"], 0x7ffc6d267ee8 /* 48 vars */) = 0 2 1722739010.783489 brk(NULL) = 0x24f7c000 3 1722739010.783655 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) 4 1722739010.783839 openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 5 1722739010.783929 fstat(3, {st_mode=S_IFREG|0644, st_size=80275, ...}) = 0 6 1722739010.784029 mmap(NULL, 80275, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fe4dc32c000 7 1722739010.784091 close(3) = 0 8 1722739010.784147 openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 9 1722739010.784214 read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 4\0\0\0\0\0\0"..., 832) = 832 10 1722739010.784260 fstat(3, {st_mode=S_IFREG|0755, st_size=2449520, ...}) = 0 11 1722739010.784306 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe4dc32a000 12 1722739010.784374 mmap(NULL, 2038712, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fe4dc138000 13 1722739010.784421 mmap(0x7fe4dc2a7000, 479232, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16f000) = 0x7fe4dc2a7000 14 1722739010.784473 mmap(0x7fe4dc31c000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1e4000) = 0x7fe4dc31c000 15 1722739010.784519 mmap(0x7fe4dc322000, 31672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fe4dc322000 16 1722739010.784568 close(3) = 0 17 1722739010.784616 mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe4dc135000 18 1722739010.784658 arch_prctl(ARCH_SET_FS, 0x7fe4dc135740) = 0 19 1722739010.784691 set_tid_address(0x7fe4dc135a10) = 842347 20 1722739010.784726 set_robust_list(0x7fe4dc135a20, 24) = 0 21 1722739010.784759 rseq(0x7fe4dc136060, 0x20, 0, 0x53053053) = 0 22 1722739010.784846 mprotect(0x7fe4dc31c000, 16384, PROT_READ) = 0 23 1722739010.784903 mprotect(0x403000, 4096, PROT_READ) = 0 24 1722739010.784946 mprotect(0x7fe4dc37b000, 8192, PROT_READ) = 0 25 1722739010.785008 prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0 26 1722739010.785059 munmap(0x7fe4dc32c000, 80275) = 0 27 1722739010.785119 getrandom("\x5f\xc4\x86\x1d\xbb\xac\x24\x12", 8, 0) = 8 28 1722739010.785157 mmap(0x2cbb1d86c000, 536870912, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2cbb1d86c000 29 1722739010.785196 prctl(PR_SET_VMA, PR_SET_VMA_ANON_NAME, 0x2cbb1d86c000, 536870912, "v8") = -1 EINVAL (Invalid argument) 30 1722739010.785245 mprotect(0x2cbb1d86c000, 536870912, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 31 1722739010.785301 exit_group(0) = ? 32 1722739010.785387 +++ exited with 0 +++ $ uname -r 6.11.0-0.rc1.20240731gite4fc196f5ba3.18.fc41.x86_64
(In reply to Steve from comment #109) > It exits immediately with strace, ... The loop is outside a.out. Doh! Anyway, even during a run that doesn't trigger an AVC, prctl() returns EINVAL.
(In reply to reisner.marc from comment #108) > It's possible that this avc is legitimate. However, it does seem like there is some randomness at play (either in Chromium or kernel code) which is why it takes a number of tries to trigger the avc. Your reproducer completely clears chromium. The randomness could be due to a race in the kernel. A web search found this methodology, which entails building a kernel: "The Kernel Concurrency Sanitizer (KCSAN) is a dynamic race detector, which relies on compile-time instrumentation, and uses a watchpoint-based sampling approach to detect races. KCSAN’s primary purpose is to detect data races." https://docs.kernel.org/dev-tools/kcsan.html
(In reply to Steve from comment #111) > A web search found this methodology, which entails building a kernel: ... NM: That's for user space data races ...
Marc: I adapted your reproducer for my own reproducer in this bug report against the kernel: Bug 2302746 - prctl(PR_SET_VMA, PR_SET_VMA_ANON_NAME, 0x7f07c583f000, 4096, "test-mem-1") = -1 EINVAL (Invalid argument)
(In reply to Steve from comment #113) > Marc: I adapted your reproducer for my own reproducer in this bug report against the kernel: > > Bug 2302746 - prctl(PR_SET_VMA, PR_SET_VMA_ANON_NAME, 0x7f07c583f000, 4096, "test-mem-1") = -1 EINVAL (Invalid argument) Problem solved: Bug 2302746 - prctl(PR_SET_VMA, PR_SET_VMA_ANON_NAME, ...) not enabled in kernel; should return ENOSYS, not EINVAL Now I have to retract Comment 95.
Marc: Paul, in an upstream comment, has some good suggestions for further investigation. In particular, he suggests getting "the memory mappings (see /proc/self/maps for an example) and the address which caused the access denial." https://bugzilla.kernel.org/show_bug.cgi?id=218258#c9 Of course, the arguments to mprotect() specify an address range, so that is easy to find. Using the current shell as a test case: $ cat /proc/$$/comm bash This shows the location of the heap, but the "maps" file doesn't show any selinux labels: $ fgrep heap /proc/$$/maps 557b3f398000-557b3f54e000 rw-p 00000000 00:00 0 [heap] Another possibility would be to trigger a core dump before exiting. core(5) has a lot of info.
(In reply to Steve from comment #115) > Another possibility would be to trigger a core dump before exiting. core(5) has a lot of info. core(5): "The gdb(1) gcore command can be used to obtain a core dump of a running process." Instead of exiting, the test process could call sleep(3) or nanosleep(2) with a very long timeout. Then gdb could be attached to the process. sleep(3) says: "On some systems, sleep() may be implemented using alarm(2) and SIGALRM (POSIX.1 permits this); ...". If true on linux, that might cause unwanted execution after the "Permission denied". So: nanosleep((const struct timespec[]){{60*60*24, 0}}, NULL); // sleep for one day
I'm so rusty on this that I asked Mixtral AI* for a suggestion and got a short test program that includes: raise(SIGSTOP); That sounds much better than nanosleep(). * https://start.duckduckgo.com/?q=DuckDuckGo+AI+Chat&ia=chat&duckai=1
I collected strace and /proc/<pid>/maps for a couple of Chromium processes. --------------------------------------------------------------------------- This is an example of a Chromium execution that triggers an avc $ grep mprotect chromium.1167719 | grep EACCES mprotect(0x5557e0000000, 536870912, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EACCES (Permission denied) $ grep mprotect chromium.1167720 | grep EACCES mprotect(0x5557e0000000, 536870912, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EACCES (Permission denied) mreisner@blacklodgetop:~/Downloads/chrome-linux/strace/bad $ grep heap maps.1167719 5557e0000000-555800000000 ---p 00000000 00:00 0 [heap] mreisner@blacklodgetop:~/Downloads/chrome-linux/strace/bad $ grep heap maps.1167720 5557e0000000-555800000000 ---p 00000000 00:00 0 [heap] So according to this, Chromium is indeed requesting execute permissions on the heap. Here's a larger sample of the memory map of one of the processes: 5557c57d6000-5557c990b000 r--p 00000000 00:21 4232162 /home/mreisner/Downloads/chrome-linux/chrome 5557c990c000-5557d5138000 r-xp 04135000 00:21 4232162 /home/mreisner/Downloads/chrome-linux/chrome 5557d5138000-5557d5a18000 r--p 0f960000 00:21 4232162 /home/mreisner/Downloads/chrome-linux/chrome 5557d5a19000-5557d5a30000 rw-p 10240000 00:21 4232162 /home/mreisner/Downloads/chrome-linux/chrome 5557d5a30000-5557d5a31000 r--p 10257000 00:21 4232162 /home/mreisner/Downloads/chrome-linux/chrome 5557d5a31000-5557d5abb000 rw-p 10258000 00:21 4232162 /home/mreisner/Downloads/chrome-linux/chrome 5557d5abb000-5557d5cc2000 rw-p 00000000 00:00 0 5557e0000000-555800000000 ---p 00000000 00:00 0 [heap] 7f6ae6200000-7f6ae6210000 r--p 00000000 00:00 0 7f6ae6210000-7f6aee200000 ---p 00000000 00:00 0 Same mmap calls as before: $ grep 0x5557e0000000 chromium.1167719 mmap(0x5557e0000000, 536870912, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x5557e0000000 prctl(PR_SET_VMA, PR_SET_VMA_ANON_NAME, 0x5557e0000000, 536870912, "v8") = -1 EINVAL (Invalid argument) mprotect(0x5557e0000000, 536870912, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EACCES (Permission denied) $ grep 0x5557e0000000 chromium.1167720 mmap(0x5557e0000000, 536870912, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x5557e0000000 prctl(PR_SET_VMA, PR_SET_VMA_ANON_NAME, 0x5557e0000000, 536870912, "v8") = -1 EINVAL (Invalid argument) mprotect(0x5557e0000000, 536870912, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EACCES (Permission denied) ------------------------------------------------------------- This is an example of a Chromium execution that does not trigger an avc. $ grep mprotect * | grep EXEC chromium.1165958:mprotect(0x556e93600000, 536870912, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 chromium.1165959:mprotect(0x556e93600000, 536870912, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 chromium.1166000:mprotect(0x556e93600000, 536870912, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 There is no heap showing up in /proc/<pid>/maps for these processes $ grep heap maps.1165958 $ grep heap maps.1165959 $ grep heap maps.1166000 $ The 0x556e9360000 does indeed appear to fall in a non-heap memory mapped region, of the requested size (512MB) 556e2ce4a000-556e30f7f000 r--p 00000000 00:21 4232162 /home/mreisner/Downloads/chrome-linux/chrome 556e30f80000-556e3c7ac000 r-xp 04135000 00:21 4232162 /home/mreisner/Downloads/chrome-linux/chrome 556e3c7ac000-556e3d08c000 r--p 0f960000 00:21 4232162 /home/mreisner/Downloads/chrome-linux/chrome 556e3d08d000-556e3d0a4000 rw-p 10240000 00:21 4232162 /home/mreisner/Downloads/chrome-linux/chrome 556e3d0a4000-556e3d0a5000 r--p 10257000 00:21 4232162 /home/mreisner/Downloads/chrome-linux/chrome 556e3d0a5000-556e3d12f000 rw-p 10258000 00:21 4232162 /home/mreisner/Downloads/chrome-linux/chrome 556e3d12f000-556e3d336000 rw-p 00000000 00:00 0 556e93600000-556eb3600000 rwxp 00000000 00:00 0 ##### <====== here 7f6308800000-7f6308801000 ---p 00000000 00:00 0 7f6308801000-7f6309001000 rw-p 00000000 00:00 0 ------------------------------------------------------------- It's a little strange that when the issue occurs there is heap memory and when the issue occurs there is not heap memory, leading me to believe that part of memory is being flagged as heap when it is not actually heap. I'm no expert, but some Googling leads me to believe that mmap should *never* return a heap address. I'll try to reproduce again with my program and get /proc/<pid>/maps from that.
I updated my reproducer as follows: #include <stdio.h> #include <stdint.h> #include <string.h> #include <unistd.h> #include <errno.h> #include <sys/mman.h> #include <linux/prctl.h> #include <sys/prctl.h> #include <sys/random.h> int main(void) { uintptr_t raw_addr; getrandom(&raw_addr, sizeof(raw_addr), 0); raw_addr &= (uint64_t) 0x3FFFFFFFF000; int length = 512 * 1024 * 1024; void* pointer = mmap((void *)raw_addr, length, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); if (!pointer) { char buf[100]; sprintf(buf, "Failed to mmap 0x%x", raw_addr); perror(buf); return 1; } if (mprotect(pointer, length, PROT_READ | PROT_WRITE | PROT_EXEC) == -1) { char buf[100]; sprintf(buf, "Failed to mprotect 0x%x", pointer); perror(buf); FILE *maps = fopen("/proc/self/maps", "r"); char read_buf[16384]; while (!feof(maps)) { fread(read_buf, sizeof(read_buf), 1, maps); printf("%s", read_buf); } return 1; } return 0; } The output is now this. You can see that 0x25085000 is in heap. Failed to mprotect 0x25085000: Permission denied 00400000-00401000 r--p 00000000 00:21 4241895 /home/mreisner/a.out 00401000-00402000 r-xp 00001000 00:21 4241895 /home/mreisner/a.out 00402000-00403000 r--p 00002000 00:21 4241895 /home/mreisner/a.out 00403000-00404000 r--p 00002000 00:21 4241895 /home/mreisner/a.out 00404000-00405000 rw-p 00003000 00:21 4241895 /home/mreisner/a.out 25085000-45085000 ---p 00000000 00:00 0 [heap] 7f5aa8d7f000-7f5aa8e82000 rw-p 00000000 00:00 0 7f5aa8e82000-7f5aa8eaa000 r--p 00000000 00:21 1857352 /usr/lib64/libc.so.6 7f5aa8eaa000-7f5aa9017000 r-xp 00028000 00:21 1857352 /usr/lib64/libc.so.6 7f5aa9017000-7f5aa9065000 r--p 00195000 00:21 1857352 /usr/lib64/libc.so.6 7f5aa9065000-7f5aa9069000 r--p 001e2000 00:21 1857352 /usr/lib64/libc.so.6 7f5aa9069000-7f5aa906b000 rw-p 001e6000 00:21 1857352 /usr/lib64/libc.so.6 7f5aa906b000-7f5aa9075000 rw-p 00000000 00:00 0 7f5aa908a000-7f5aa908e000 r--p 00000000 00:00 0 [vvar] 7f5aa908e000-7f5aa9090000 r-xp 00000000 00:00 0 [vdso] 7f5aa9090000-7f5aa9091000 r--p 00000000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7f5aa9091000-7f5aa90b9000 r-xp 00001000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7f5aa90b9000-7f5aa90c3000 r--p 00029000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7f5aa90c3000-7f5aa90c5000 r--p 00033000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7f5aa90c5000-7f5aa90c7000 rw-p 00035000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7ffd6938c000-7ffd693ad000 rw-p 00000000 00:00 0 [stack] ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall] I further tweaked it so that it prints out /proc/self/maps when successful: #include <stdio.h> #include <stdint.h> #include <string.h> #include <unistd.h> #include <errno.h> #include <sys/mman.h> #include <linux/prctl.h> #include <sys/prctl.h> #include <sys/random.h> int main(void) { uintptr_t raw_addr; getrandom(&raw_addr, sizeof(raw_addr), 0); raw_addr &= (uint64_t) 0x3FFFFFFFF000; int length = 512 * 1024 * 1024; void* pointer = mmap((void *)raw_addr, length, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); if (!pointer) { char buf[100]; sprintf(buf, "Failed to mmap 0x%x", raw_addr); perror(buf); return 1; } if (mprotect(pointer, length, PROT_READ | PROT_WRITE | PROT_EXEC) == -1) { char buf[100]; sprintf(buf, "Failed to mprotect 0x%x", pointer); perror(buf); return 1; } printf("mmap returned: 0x%x\n", pointer); FILE *maps = fopen("/proc/self/maps", "r"); char read_buf[16384]; while (!feof(maps)) { fread(read_buf, sizeof(read_buf), 1, maps); printf("%s", read_buf); } return 0; } What's interesting here is that 0x771f7000 is not in /proc/self/maps but 0x3ffb771f7000 is, which is what you get if you do logical OR of 0x3ffb00000000 | 0x771f7000. Every time I run it though, there is a different offset. The only time that it is counted as heap is when the offset is 0! mmap returned: 0x771f7000 00400000-00401000 r--p 00000000 00:21 4242154 /home/mreisner/a.out 00401000-00402000 r-xp 00001000 00:21 4242154 /home/mreisner/a.out 00402000-00403000 r--p 00002000 00:21 4242154 /home/mreisner/a.out 00403000-00404000 r--p 00002000 00:21 4242154 /home/mreisner/a.out 00404000-00405000 rw-p 00003000 00:21 4242154 /home/mreisner/a.out 19836000-19857000 rw-p 00000000 00:00 0 [heap] 3ffb771f7000-3ffb971f7000 rwxp 00000000 00:00 0 7f2309ae4000-7f2309ae7000 rw-p 00000000 00:00 0 7f2309ae7000-7f2309b0f000 r--p 00000000 00:21 1857352 /usr/lib64/libc.so.6 7f2309b0f000-7f2309c7c000 r-xp 00028000 00:21 1857352 /usr/lib64/libc.so.6 7f2309c7c000-7f2309cca000 r--p 00195000 00:21 1857352 /usr/lib64/libc.so.6 7f2309cca000-7f2309cce000 r--p 001e2000 00:21 1857352 /usr/lib64/libc.so.6 7f2309cce000-7f2309cd0000 rw-p 001e6000 00:21 1857352 /usr/lib64/libc.so.6 7f2309cd0000-7f2309cda000 rw-p 00000000 00:00 0 7f2309cef000-7f2309cf3000 r--p 00000000 00:00 0 [vvar] 7f2309cf3000-7f2309cf5000 r-xp 00000000 00:00 0 [vdso] 7f2309cf5000-7f2309cf6000 r--p 00000000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7f2309cf6000-7f2309d1e000 r-xp 00001000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7f2309d1e000-7f2309d28000 r--p 00029000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7f2309d28000-7f2309d2a000 r--p 00033000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7f2309d2a000-7f2309d2c000 rw-p 00035000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7ffe13e1e000-7ffe13e3f000 rw-p 00000000 00:00 0 [stack] ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall] Here are some more examples showing the random offset. mmap returned: 0x1659f000 00400000-00401000 r--p 00000000 00:21 4242154 /home/mreisner/a.out 00401000-00402000 r-xp 00001000 00:21 4242154 /home/mreisner/a.out 00402000-00403000 r--p 00002000 00:21 4242154 /home/mreisner/a.out 00403000-00404000 r--p 00002000 00:21 4242154 /home/mreisner/a.out 00404000-00405000 rw-p 00003000 00:21 4242154 /home/mreisner/a.out 30235000-30256000 rw-p 00000000 00:00 0 [heap] 641659f000-643659f000 rwxp 00000000 00:00 0 7fe690baa000-7fe690bad000 rw-p 00000000 00:00 0 7fe690bad000-7fe690bd5000 r--p 00000000 00:21 1857352 /usr/lib64/libc.so.6 7fe690bd5000-7fe690d42000 r-xp 00028000 00:21 1857352 /usr/lib64/libc.so.6 7fe690d42000-7fe690d90000 r--p 00195000 00:21 1857352 /usr/lib64/libc.so.6 7fe690d90000-7fe690d94000 r--p 001e2000 00:21 1857352 /usr/lib64/libc.so.6 7fe690d94000-7fe690d96000 rw-p 001e6000 00:21 1857352 /usr/lib64/libc.so.6 7fe690d96000-7fe690da0000 rw-p 00000000 00:00 0 7fe690db5000-7fe690db9000 r--p 00000000 00:00 0 [vvar] 7fe690db9000-7fe690dbb000 r-xp 00000000 00:00 0 [vdso] 7fe690dbb000-7fe690dbc000 r--p 00000000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7fe690dbc000-7fe690de4000 r-xp 00001000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7fe690de4000-7fe690dee000 r--p 00029000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7fe690dee000-7fe690df0000 r--p 00033000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7fe690df0000-7fe690df2000 rw-p 00035000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7fffd2591000-7fffd25b2000 rw-p 00000000 00:00 0 [stack] ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall] ======================================== mmap returned: 0x3a2d5000 00400000-00401000 r--p 00000000 00:21 4242154 /home/mreisner/a.out 00401000-00402000 r-xp 00001000 00:21 4242154 /home/mreisner/a.out 00402000-00403000 r--p 00002000 00:21 4242154 /home/mreisner/a.out 00403000-00404000 r--p 00002000 00:21 4242154 /home/mreisner/a.out 00404000-00405000 rw-p 00003000 00:21 4242154 /home/mreisner/a.out 1efd1000-1eff2000 rw-p 00000000 00:00 0 [heap] 21153a2d5000-21155a2d5000 rwxp 00000000 00:00 0 7f4a444b2000-7f4a444b5000 rw-p 00000000 00:00 0 7f4a444b5000-7f4a444dd000 r--p 00000000 00:21 1857352 /usr/lib64/libc.so.6 7f4a444dd000-7f4a4464a000 r-xp 00028000 00:21 1857352 /usr/lib64/libc.so.6 7f4a4464a000-7f4a44698000 r--p 00195000 00:21 1857352 /usr/lib64/libc.so.6 7f4a44698000-7f4a4469c000 r--p 001e2000 00:21 1857352 /usr/lib64/libc.so.6 7f4a4469c000-7f4a4469e000 rw-p 001e6000 00:21 1857352 /usr/lib64/libc.so.6 7f4a4469e000-7f4a446a8000 rw-p 00000000 00:00 0 7f4a446bd000-7f4a446c1000 r--p 00000000 00:00 0 [vvar] 7f4a446c1000-7f4a446c3000 r-xp 00000000 00:00 0 [vdso] 7f4a446c3000-7f4a446c4000 r--p 00000000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7f4a446c4000-7f4a446ec000 r-xp 00001000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7f4a446ec000-7f4a446f6000 r--p 00029000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7f4a446f6000-7f4a446f8000 r--p 00033000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7f4a446f8000-7f4a446fa000 rw-p 00035000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7ffe3a8f6000-7ffe3a917000 rw-p 00000000 00:00 0 [stack] ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall] ========================================
An even better reproducer - rather than use a random address, just use the same one! #include <stdio.h> #include <stdint.h> #include <string.h> #include <unistd.h> #include <errno.h> #include <sys/mman.h> #include <linux/prctl.h> #include <sys/prctl.h> #include <sys/random.h> int main(void) { uintptr_t raw_addr = 0x25085000; int length = 512 * 1024 * 1024; void* pointer = mmap((void *)raw_addr, length, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); if (!pointer) { char buf[100]; sprintf(buf, "Failed to mmap 0x%x", raw_addr); perror(buf); return 1; } if (mprotect(pointer, length, PROT_READ | PROT_WRITE | PROT_EXEC) == -1) { char buf[100]; sprintf(buf, "Failed to mprotect 0x%x", pointer); perror(buf); FILE *maps = fopen("/proc/self/maps", "r"); char read_buf[16384]; while (!feof(maps)) { fread(read_buf, sizeof(read_buf), 1, maps); printf("%s", read_buf); } return 1; } return 0; } The results are equally as random: mreisner@blacklodgetop:~ $ ./a.out Failed to mprotect 0x25085000: Permission denied 00400000-00401000 r--p 00000000 00:21 4242834 /home/mreisner/a.out 00401000-00402000 r-xp 00001000 00:21 4242834 /home/mreisner/a.out 00402000-00403000 r--p 00002000 00:21 4242834 /home/mreisner/a.out 00403000-00404000 r--p 00002000 00:21 4242834 /home/mreisner/a.out 00404000-00405000 rw-p 00003000 00:21 4242834 /home/mreisner/a.out 25085000-45085000 ---p 00000000 00:00 0 [heap] 7f442eb91000-7f442ec94000 rw-p 00000000 00:00 0 7f442ec94000-7f442ecbc000 r--p 00000000 00:21 1857352 /usr/lib64/libc.so.6 7f442ecbc000-7f442ee29000 r-xp 00028000 00:21 1857352 /usr/lib64/libc.so.6 7f442ee29000-7f442ee77000 r--p 00195000 00:21 1857352 /usr/lib64/libc.so.6 7f442ee77000-7f442ee7b000 r--p 001e2000 00:21 1857352 /usr/lib64/libc.so.6 7f442ee7b000-7f442ee7d000 rw-p 001e6000 00:21 1857352 /usr/lib64/libc.so.6 7f442ee7d000-7f442ee87000 rw-p 00000000 00:00 0 7f442ee9c000-7f442eea0000 r--p 00000000 00:00 0 [vvar] 7f442eea0000-7f442eea2000 r-xp 00000000 00:00 0 [vdso] 7f442eea2000-7f442eea3000 r--p 00000000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7f442eea3000-7f442eecb000 r-xp 00001000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7f442eecb000-7f442eed5000 r--p 00029000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7f442eed5000-7f442eed7000 r--p 00033000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7f442eed7000-7f442eed9000 rw-p 00035000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7ffd720b5000-7ffd720d6000 rw-p 00000000 00:00 0 [stack] ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall] mreisner@blacklodgetop:~ $ ./a.out 1 Failed to mprotect 0x25085000: Permission denied 00400000-00401000 r--p 00000000 00:21 4242834 /home/mreisner/a.out 00401000-00402000 r-xp 00001000 00:21 4242834 /home/mreisner/a.out 00402000-00403000 r--p 00002000 00:21 4242834 /home/mreisner/a.out 00403000-00404000 r--p 00002000 00:21 4242834 /home/mreisner/a.out 00404000-00405000 rw-p 00003000 00:21 4242834 /home/mreisner/a.out 25085000-45085000 ---p 00000000 00:00 0 [heap] 7fe0f55ea000-7fe0f56ed000 rw-p 00000000 00:00 0 7fe0f56ed000-7fe0f5715000 r--p 00000000 00:21 1857352 /usr/lib64/libc.so.6 7fe0f5715000-7fe0f5882000 r-xp 00028000 00:21 1857352 /usr/lib64/libc.so.6 7fe0f5882000-7fe0f58d0000 r--p 00195000 00:21 1857352 /usr/lib64/libc.so.6 7fe0f58d0000-7fe0f58d4000 r--p 001e2000 00:21 1857352 /usr/lib64/libc.so.6 7fe0f58d4000-7fe0f58d6000 rw-p 001e6000 00:21 1857352 /usr/lib64/libc.so.6 7fe0f58d6000-7fe0f58e0000 rw-p 00000000 00:00 0 7fe0f58f5000-7fe0f58f9000 r--p 00000000 00:00 0 [vvar] 7fe0f58f9000-7fe0f58fb000 r-xp 00000000 00:00 0 [vdso] 7fe0f58fb000-7fe0f58fc000 r--p 00000000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7fe0f58fc000-7fe0f5924000 r-xp 00001000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7fe0f5924000-7fe0f592e000 r--p 00029000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7fe0f592e000-7fe0f5930000 r--p 00033000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7fe0f5930000-7fe0f5932000 rw-p 00035000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7ffdd3c1f000-7ffdd3c40000 rw-p 00000000 00:00 0 [stack] ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall] mreisner@blacklodgetop:~ $ ./a.out 1 mreisner@blacklodgetop:~ $ ./a.out mreisner@blacklodgetop:~ $ ./a.out mreisner@blacklodgetop:~ $ ./a.out Failed to mprotect 0x25085000: Permission denied 00400000-00401000 r--p 00000000 00:21 4242834 /home/mreisner/a.out 00401000-00402000 r-xp 00001000 00:21 4242834 /home/mreisner/a.out 00402000-00403000 r--p 00002000 00:21 4242834 /home/mreisner/a.out 00403000-00404000 r--p 00002000 00:21 4242834 /home/mreisner/a.out 00404000-00405000 rw-p 00003000 00:21 4242834 /home/mreisner/a.out 25085000-45085000 ---p 00000000 00:00 0 [heap] 7f53cad00000-7f53cae03000 rw-p 00000000 00:00 0 7f53cae03000-7f53cae2b000 r--p 00000000 00:21 1857352 /usr/lib64/libc.so.6 7f53cae2b000-7f53caf98000 r-xp 00028000 00:21 1857352 /usr/lib64/libc.so.6 7f53caf98000-7f53cafe6000 r--p 00195000 00:21 1857352 /usr/lib64/libc.so.6 7f53cafe6000-7f53cafea000 r--p 001e2000 00:21 1857352 /usr/lib64/libc.so.6 7f53cafea000-7f53cafec000 rw-p 001e6000 00:21 1857352 /usr/lib64/libc.so.6 7f53cafec000-7f53caff6000 rw-p 00000000 00:00 0 7f53cb00b000-7f53cb00f000 r--p 00000000 00:00 0 [vvar] 7f53cb00f000-7f53cb011000 r-xp 00000000 00:00 0 [vdso] 7f53cb011000-7f53cb012000 r--p 00000000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7f53cb012000-7f53cb03a000 r-xp 00001000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7f53cb03a000-7f53cb044000 r--p 00029000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7f53cb044000-7f53cb046000 r--p 00033000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7f53cb046000-7f53cb048000 rw-p 00035000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7ffe6e21c000-7ffe6e23d000 rw-p 00000000 00:00 0 [stack] ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall]
And of course a result from the previous program if you print out /proc/self/maps when successful: 00400000-00401000 r--p 00000000 00:21 4242926 /home/mreisner/a.out 00401000-00402000 r-xp 00001000 00:21 4242926 /home/mreisner/a.out 00402000-00403000 r--p 00002000 00:21 4242926 /home/mreisner/a.out 00403000-00404000 r--p 00002000 00:21 4242926 /home/mreisner/a.out 00404000-00405000 rw-p 00003000 00:21 4242926 /home/mreisner/a.out 198fc000-1991d000 rw-p 00000000 00:00 0 [heap] 25085000-45085000 ---p 00000000 00:00 0 7fa57adbc000-7fa57adbf000 rw-p 00000000 00:00 0 7fa57adbf000-7fa57ade7000 r--p 00000000 00:21 1857352 /usr/lib64/libc.so.6 7fa57ade7000-7fa57af54000 r-xp 00028000 00:21 1857352 /usr/lib64/libc.so.6 7fa57af54000-7fa57afa2000 r--p 00195000 00:21 1857352 /usr/lib64/libc.so.6 7fa57afa2000-7fa57afa6000 r--p 001e2000 00:21 1857352 /usr/lib64/libc.so.6 7fa57afa6000-7fa57afa8000 rw-p 001e6000 00:21 1857352 /usr/lib64/libc.so.6 7fa57afa8000-7fa57afb2000 rw-p 00000000 00:00 0 7fa57afc7000-7fa57afcb000 r--p 00000000 00:00 0 [vvar] 7fa57afcb000-7fa57afcd000 r-xp 00000000 00:00 0 [vdso] 7fa57afcd000-7fa57afce000 r--p 00000000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7fa57afce000-7fa57aff6000 r-xp 00001000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7fa57aff6000-7fa57b000000 r--p 00029000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7fa57b000000-7fa57b002000 r--p 00033000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7fa57b002000-7fa57b004000 rw-p 00035000 00:21 1857349 /usr/lib64/ld-linux-x86-64.so.2 7fff29ebe000-7fff29edf000 rw-p 00000000 00:00 0 [stack] ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall]
(In reply to reisner.marc from comment #121) > And of course a result from the previous program if you print out > /proc/self/maps when successful: > > 198fc000-1991d000 rw-p 00000000 00:00 0 > [heap] > 25085000-45085000 ---p 00000000 00:00 0 Important to note that this was printed *before* executing mprotect(2), hence why there are no r/w/x permissions on 0x25085000-0x45085000
Interesting tidbit: If I insert the following at the beginning of my program, I can't reproduce the issue. void *program_break = sbrk(0); printf("program break is 0x%x\n=====================", program_break); Must have something to do with establishing the program break that prevents mmap from incorrectly establishing the program break.
We need to check the upper bounds too. From Comment 118: mprotect(0x5557e0000000, 536870912, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EACCES (Permission denied) 5557e0000000-555800000000 ---p 00000000 00:00 0 [heap] $ python ... >>> hex(0x5557e0000000+536870912) '0x555800000000' Is 0x555800000000 in the heap or in the next page? If anyone wants to do the addition mentally, here is the length in hex: >>> hex(536870912) '0x20000000'
Re Comment 119: $ python ... >>> # int length = 512 * 1024 * 1024; >>> hex(512 * 1024 * 1024) '0x20000000' OK, you are making that length more comprehensible. :-)
Re Comment 120: > rather than use a random address, just use the same one! Good idea. That makes it much easier to analyze the results. I'm not reviewing your code, but figuring out what it does. :-) This is much better than what I had in mind: FILE *maps = fopen("/proc/self/maps", "r");
Re Comment 121: > a result from the previous program if you print out /proc/self/maps when successful: 198fc000-1991d000 rw-p 00000000 00:00 0 [heap] 25085000-45085000 ---p 00000000 00:00 0 That's what I would expect -- mmap() isn't supposed to allocate from the heap or to create the heap*, and here it works as expected. For the record, here is the distance from the top of the heap to the beginning of the mmapped memory: >>> hex(0x25085000-0x1991d000) '0xb768000' * Indeed, mmap(2) doesn't even mention the heap!
(In reply to reisner.marc from comment #123) > Interesting tidbit: > > If I insert the following at the beginning of my program, I can't reproduce the issue. > > void *program_break = sbrk(0); > printf("program break is 0x%x\n=====================", program_break); > > > Must have something to do with establishing the program break that prevents mmap from incorrectly establishing the program break. Actually, that is a very important observation -- it suggests that the heap is not always being created before mmap executes. Indeed, Comment 120 shows this for the failure case: 25085000-45085000 ---p 00000000 00:00 0 [heap] So how in the world did that become the heap! Is mmap trashing the heap?! Or creating the heap?! IIUC, the runtime initialization should create *one heap* and any subsequent mmap calls should allocate regions *outside the heap*.
Looking at this patch: The logic used to be: vma->vm_start >= vma->vm_mm->start_brk && vm_end <= vma->vm_mm->brk https://github.com/torvalds/linux/commit/68df1baf158fddc07b6f0333e4c81fe1ccecd6ff changed it to: vma->vm_start <= vma->vm_mm->brk && vma->vm_end >= vma->vm_mm->start_brk; Then https://github.com/torvalds/linux/commit/d3bb89ea9c13e5a98d2b7a0ba8e50a77893132cb changed it to: vma->vm_start < vma->vm_mm->brk && vma->vm_end > vma->vm_mm->start_brk; Maybe I'm mistaken, but how is this equivalent? Why was start_brk and brk swapped?
Here is a suggestion. Put your heap-dumper into a function and then use it to dump the memory map twice -- once before mmap in your reproducer runs and once after mmap runs. That would answer the question -- does the runtime initialization create a heap before user code executes?
When I do that, it again becomes a heisenbug - viewing /proc/self/maps has the same effect as printing the result of sbrk(0) - it prevents the error.
(In reply to reisner.marc from comment #131) > When I do that, it again becomes a heisenbug - viewing /proc/self/maps has the same effect as printing the result of sbrk(0) - it prevents the error. OK, all that printing must have major side-effects. Can you think of a way to get the memory map without actually printing it? That's not Heisenberg, that's Zen. :-) A possibility would be to add a SIGSTOP, after the prog stops, copy the "maps" file from outside the prog, and then do a SIGCONT, also from outside the prog. I haven't worked out the details enough to say whether that approach could be fully automated. Basically, it is setting a breakpoint, collecting some info, and then continuing from the breakpoint. Maybe gdb could be used.
Actually, one run of gdb should be enough to answer the question -- just set a breakpoint before the mmap call and copy the "maps" file. Presumably, the runtime initialization is the same every time. :-)
No heap is created during runtime initialization: $ cat z1.c #include <signal.h> int main(void) { raise(SIGSTOP); } $ cc z1.c $ ./a.out [1]+ Stopped ./a.out $ pgrep -l a.out 5519 a.out $ cat /proc/5519/maps 00400000-00402000 r-xp 00000000 fc:03 827305 /home/joeblow/src/a.out 00402000-00403000 r--p 00002000 fc:03 827305 /home/joeblow/src/a.out 00403000-00404000 r--p 00002000 fc:03 827305 /home/joeblow/src/a.out 00404000-00405000 rw-p 00003000 fc:03 827305 /home/joeblow/src/a.out 7fa272619000-7fa27261c000 rw-p 00000000 00:00 0 7fa27261c000-7fa27278b000 r-xp 00000000 fc:03 1059004 /usr/lib64/libc.so.6 7fa27278b000-7fa272800000 r--p 0016f000 fc:03 1059004 /usr/lib64/libc.so.6 7fa272800000-7fa272804000 r--p 001e4000 fc:03 1059004 /usr/lib64/libc.so.6 7fa272804000-7fa272806000 rw-p 001e8000 fc:03 1059004 /usr/lib64/libc.so.6 7fa272806000-7fa272810000 rw-p 00000000 00:00 0 7fa272824000-7fa272828000 r--p 00000000 00:00 0 [vvar] 7fa272828000-7fa27282a000 r-xp 00000000 00:00 0 [vdso] 7fa27282a000-7fa272854000 r-xp 00000000 fc:03 1059001 /usr/lib64/ld-linux-x86-64.so.2 7fa272854000-7fa27285f000 r--p 0002a000 fc:03 1059001 /usr/lib64/ld-linux-x86-64.so.2 7fa27285f000-7fa272861000 r--p 00035000 fc:03 1059001 /usr/lib64/ld-linux-x86-64.so.2 7fa272861000-7fa272863000 rw-p 00037000 fc:03 1059001 /usr/lib64/ld-linux-x86-64.so.2 7fffe218c000-7fffe21ad000 rw-p 00000000 00:00 0 [stack] ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall] $ kill -CONT %1 [1]+ Done ./a.out
Calling sbrk(0) does not create a heap. This does: $ cat z1.c #include <signal.h> #include <unistd.h> int main(void) { void *program_break = sbrk(0x100000); raise(SIGSTOP); } ... $ pgrep -l a.out 5905 a.out $ cat /proc/5905/maps ... 00404000-00405000 rw-p 00003000 fc:03 827305 /home/joeblow/src/a.out 24428000-24528000 rw-p 00000000 00:00 0 [heap] 7fd5a285d000-7fd5a2860000 rw-p 00000000 00:00 0 7fd5a2860000-7fd5a29cf000 r-xp 00000000 fc:03 1059004 /usr/lib64/libc.so.6 ...
Calling printf() is going to wreak havoc on this investigation -- it has the side-effect of triggering a call to brk(), as shown in line 30 of this strace output: $ cat z1.c #include <stdio.h> int main(void) { printf("hello, world!\n"); } $ strace -o printf-test-1.strace ./a.out hello, world! $ cat -n printf-test-1.strace 1 execve("./a.out", ["./a.out"], 0x7fffad403c80 /* 48 vars */) = 0 2 brk(NULL) = 0x401ae000 3 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) ... 25 prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0 26 munmap(0x7fc425dcd000, 80375) = 0 27 fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0), ...}) = 0 28 getrandom("\xda\xee\x47\xdf\x8d\x17\x1a\xe3", 8, GRND_NONBLOCK) = 8 29 brk(NULL) = 0x401ae000 30 brk(0x401cf000) = 0x401cf000 31 write(1, "hello, world!\n", 14) = 14 32 exit_group(0) = ? 33 +++ exited with 0 +++
*** Bug 2303106 has been marked as a duplicate of this bug. ***
(In reply to reisner.marc from comment #120) > An even better reproducer - rather than use a random address, just use the same one! I adapted your reproducer to raise SIGSTOP instead of calling printf(). And it works great! $ cat y3.c #include <stdint.h> #include <unistd.h> #include <errno.h> #include <sys/mman.h> #include <sys/random.h> #include <signal.h> int main(void) { uintptr_t raw_addr = 0x25085000; int length = 512 * 1024 * 1024; void* pointer = mmap((void *)raw_addr, length, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); if (!pointer) { raise(SIGSTOP); return 1; } if (mprotect(pointer, length, PROT_READ | PROT_WRITE | PROT_EXEC) == -1) { raise(SIGSTOP); return 1; } return 0; } $ cc -o y3 y3.c After 3 tries: $ ./y3 [1]+ Stopped ./y3 $ pgrep -l y3 141585 y3 We do indeed have an AVC for pid=141585: $ sudo ausearch -i -ts recent -m avc ---- type=PROCTITLE msg=audit(08/06/2024 14:05:01.352:411) : proctitle=./y3 type=SYSCALL msg=audit(08/06/2024 14:05:01.352:411) : arch=x86_64 syscall=mprotect success=no exit=EACCES(Permission denied) a0=0x25085000 a1=0x20000000 a2=PROT_READ|PROT_WRITE|PROT_EXEC a3=0x0 items=0 ppid=2860 pid=141585 auid=joeblow uid=joeblow gid=joeblow euid=joeblow suid=joeblow fsuid=joeblow egid=joeblow sgid=joeblow fsgid=joeblow tty=pts0 ses=3 comm=y3 exe=/home/joeblow/src/y3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(08/06/2024 14:05:01.352:411) : avc: denied { execheap } for pid=141585 comm=y3 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0 The mmap call created a heap! $ grep heap /proc/141585/maps 25085000-45085000 ---p 00000000 00:00 0 [heap] $ kill -CONT %1 [1]+ Exit 1 ./y3
Kamil: I think we have enough for Paul to look at. We can read his reply at the upstream bug report: https://bugzilla.kernel.org/show_bug.cgi?id=218258
Paul asked us to submit a better reproducer and detailed findings to the upstream SELinux mailing list on vger.kernel.org, to get the attention it needs. Is anyone open to do that? This is too low-level for me.
(In reply to Kamil Páral from comment #140) > Paul asked us to submit a better reproducer and detailed findings to the upstream SELinux mailing list on vger.kernel.org, to get the attention it needs. Is anyone open to do that? This is too low-level for me. The reproducer and the relevant details are in Comment 138. The most important fact is that the mmap call in the reproducer created a heap: $ grep heap /proc/141585/maps 25085000-45085000 ---p 00000000 00:00 0 [heap] Since that doesn't happen every time, this seems to be a kernel bug, not an selinux bug. Marc: What do you think?
(In reply to Steve from comment #141) > Since that [mmap creating a heap] doesn't happen every time, this seems to be a kernel bug, not an selinux bug. Indeed, selinux is *doing its job* -- stopping the heap from being made executable.
(In reply to Steve from comment #141) > Marc: What do you think? I can send an email to the kernel mailing list but I'm not a Red Hat employee (just a casual observer) so I thought it would make more sense for someone who is (Ondrej?) to do so. I have a suspicion that the vma_is_initial_heap is not handling the case where brk == start_brk (which is the case when there is no heap). https://github.com/torvalds/linux/blob/master/fs/binfmt_elf.c#L1288 I think this code shows that when the address space is randomized, vma->mm->brk == vma->mm->start_brk when a process is started. From this email: https://lore.kernel.org/all/20230728050043.59880-4-wangkefeng.wang@huawei.com/T/#mc98ee0ae55db44c4688b5a128b9cc27525e3e54f It looks like it's trying to handle the following cases: >> [start_brk brk] >> case1: [vm_start,vm_end] >> case2: [vm_start,vm_end] >> case3: [vm_start,vm_end] >> case4: [vm_start, vm_end] >> >> case5: [vm_start,vm_end] >> case6: [vm_start,vm_end] >> However, it doesn't seem to handle a 7th case - no heap. For example: [start_brk brk] [vm_start vm_end] This would be flagged as heap memory. Is it? Shouldn't a subsequent malloc result in allocating memory somewhere else, not intersecting with something that was mmapped? (Reminder of the current vma_is_initial_heap logic) https://github.com/torvalds/linux/blob/eb5e56d1491297e0881c95824e2050b7c205f0d4/include/linux/mm.h#L919 static inline bool vma_is_initial_heap(const struct vm_area_struct *vma) { return vma->vm_start < vma->vm_mm->brk && vma->vm_end > vma->vm_mm->start_brk; }
(In reply to reisner.marc from comment #143) > I have a suspicion that the vma_is_initial_heap is not handling the case where brk == start_brk (which is the case when there is no heap). Thanks for researching that. That is an excellent hypothesis. The original posting of those six vm_start->vm_end cases is here: Subject: Re: [PATCH v3 3/4] selinux: use vma_is_initial_stack() and vma_is_initial_heap() Date: Thu, 7 Dec 2023 https://lore.kernel.org/all/79f6131f-7d69-408d-917a-f0ca6fccc5b2@huawei.com/
*** Bug 2303249 has been marked as a duplicate of this bug. ***
(In reply to reisner.marc from comment #143) > I can send an email to the kernel mailing list but I'm not a Red Hat > employee (just a casual observer) so I thought it would make more sense for > someone who is (Ondrej?) to do so. Please do. Your email address shouldn't matter. Realistically I'll not be able to participate in any followup technical discussion, you will. (And I'm also leaving for a vacation soon.)
Kamil: Two *volunteers* have completely solved a difficult kernel bug, yet Red Hat is *still* not going to take any initiative?! That is outrageous! Please escalate this to someone at Red Hat.
First the fist, now the flowers ... Kamil: You are really good with people. You don't need to be a technical expert. What is needed is for someone at Red Hat to confirm the analysis and submit their conclusions to the appropriate kernel mailing list. After that, kernel experts should be able to develop a patch.
(In reply to Steve from comment #147) > Kamil: Two *volunteers* have completely solved a difficult kernel bug, yet > Red Hat is *still* not going to take any initiative?! > > That is outrageous! Please escalate this to someone at Red Hat. This is an inappropriate demand for a Fedora bug report. Red Hat is a sponsor of the Fedora project, but that does not add any special requirements to escalate things within the company. Also, it is best if the person who has debugged this engage directly with LKML, as they're the best equipped to answer any follow-up questions. There is absolutely no reason for Red Hat (or anyone else) to act as an intermediary; LKML is an open mailing list. Anyone can join and get involved; people are judged on their merit, not their email domain.
Adding Artem back to the CC list. Artem: This is a memory management bug, not an selinux bug. Could you please change the component of the upstream bug report from "Loadable Security Modules (LSM)" to one of the "Memory Management" components? https://bugzilla.kernel.org/show_bug.cgi?id=218258
(In reply to Chris Adams from comment #149) > it is best if the person who has debugged this engage directly with LKML Could you verify the reproducer in Comment 138?
(In reply to Steve from comment #150) Done. Changed to Memory -> Other, as I'm not sure whether any other memory components work.
(In reply to Steve from comment #151) ./y3 ./y3 ./y3 ./y3 ./y3 [1]+ Stopped ./y3 Fails here under 6.9.12-200.fc40.x86_64
Artem: Thanks!
Until this kernel bug is fixed, there are two workarounds: 1. For users: Disable virtual memory address randomization as described in Comment 91. Since that has security implications, it would be a good idea to assess them before deciding to use that workaround for an extended period of time. 2. For coders: Explicitly initialize the heap with brk() or sbrk() (or any higher-level memory allocation function). Do that before calling mmap(). Verify with strace and "grep heap /proc/<pid>/maps" for the relevant process. Specifically, verify that memory allocated with mmap() is not marked as the heap in /proc/<pid>/maps. Reference: Comment 138 and numerous earlier comments. Marc: Do the coder recommendations sound OK to you? As for disabling VMA randomization (VMAR), I'm fairly sure that that works because of your point in Comment 143 that "brk == start_brk ... when there is no heap". When there is no heap and VMAR is disabled, start_brk and brk are set to *the same constant address* and that address is never within the address range specified in mmap() calls. start_brk and brk appear to be initialized here: https://github.com/torvalds/linux/blob/6a0e38264012809afa24113ee2162dc07f4ed22b/fs/binfmt_elf.c#L1232 You are much better at reading kernel code than I am, so maybe you can figure out the value of "ELF_PAGEALIGN(elf_brk)".
(In reply to Steve from comment #155) > Marc: Do the coder recommendations sound OK to you? Yes > You are much better at reading kernel code than I am, so maybe you can > figure out the value of "ELF_PAGEALIGN(elf_brk)". Not sure it matters what the exact value is, all that matters is that the ELF_PAGEALIGN macro results in the heap being aligned to a page boundary.
I sent an email. Follow along here: https://lore.kernel.org/all/ZrPmoLKJEf1wiFmM@marcreisner.com/
(In reply to reisner.marc from comment #157) > I sent an email. Follow along here: > > https://lore.kernel.org/all/ZrPmoLKJEf1wiFmM@marcreisner.com/ Thanks. That's an *excellent* summary.
(In reply to reisner.marc from comment #157) > I sent an email. Follow along here: > > https://lore.kernel.org/all/ZrPmoLKJEf1wiFmM@marcreisner.com/ Paul replied: https://lore.kernel.org/all/CAHC9VhSWVdiuK+VtbjV6yJiCp=2+6Bji_86mSkj1eeRL4g_Jfg@mail.gmail.com/ Paul's suggestions were *invaluable* (Comment 115 and the following). Could you thank him on our behalf?
(In reply to Steve from comment #147) > Kamil: Two *volunteers* have completely solved a difficult kernel bug, yet > Red Hat is *still* not going to take any initiative?! Please know that your effort is very appreciated. At the same time, Fedora is very volunteer-driven and Red Hat provides financial backing and some of its engineers' time, but their primary focus is of course the commercial products. So, as far as I know, we have just a single person taking care of the whole Fedora kernel (or maybe 1.5 people). And a number of QA people like me, who take care of the whole distribution and not specific packages. I wish it would be otherwise, but manpower is always lacking. That's why upstream collaboration is important. (In reply to reisner.marc from comment #157) > I sent an email. Follow along here: > > https://lore.kernel.org/all/ZrPmoLKJEf1wiFmM@marcreisner.com/ Thanks a lot, Marc. This is much better than I could do, and I'd have to invite you for a followup discussion anyway.
(In reply to Kamil Páral from comment #160) Thanks for updating the upstream kernel bug report and Comment 0 of this bug report. Keeping everyone informed is very important when there are three separate web pages involved. And thanks for explaining the staffing situation. > their primary focus is of course the commercial products. AIUI, Fedora kernels eventually become RHEL kernels, so fixing this bug is in the interest of the company: "The Fedora distribution is, among other things, an upstream for Red Hat Enterprise Linux (RHEL)." https://docs.fedoraproject.org/en-US/eln/faq/
Marc: Apparently, the heap can be discontiguous. That won't change the reproducer, but it does seem to change the interpretation of the results. Quoting Liam at lore.kernel.org[1]: "Have a look at the mmapstress 3 test in ltp [2]. The tests pokes holes and mmaps into those holes throughout the brk range." And the documentation for that test includes this, apparently supported, memory map: "After mmaping over the end of the brk segment, it [the test] increases the brk which should split it into two segments (i.e. |---brk---|-mmap-|--more brk--|)." [1] https://lore.kernel.org/all/zk5ffj6otbixbnppw4shxgz4tjulagm7du457gzi4qg7zrtdkk@e7mbwyzhdtrx/ [2] https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/mem/mmapstress/mmapstress03.c
(In reply to Steve from comment #162) > Marc: Apparently, the heap can be discontiguous. Confirmed. I simply raised SIGSTOP at a plausible place in mmapstress03.c and rebuilt the entire test suite: $ rcsdiff -u0 mmapstress03.c =================================================================== RCS file: RCS/mmapstress03.c,v retrieving revision 1.1 diff -u0 -r1.1 mmapstress03.c --- mmapstress03.c 2024/08/08 20:28:27 1.1 +++ mmapstress03.c 2024/08/08 20:30:41 @@ -46,0 +47 @@ +#include <signal.h> @@ -111,0 +113,2 @@ + + raise(SIGSTOP); $ ./mmapstress03-1 mmapstress03 0 TINFO : uname.machine=x86_64 kernel is 64bit [1]+ Stopped ./mmapstress03-1 $ jobs -l [1]+ 3414 Stopped (signal) ./mmapstress03-1 I apologize for going way beyond my self-imposed 30-line limit, but there are indeed "holes" in the heap! $ cat -n /proc/3414/maps 1 00400000-00404000 r--p 00000000 fc:03 829937 /home/joeblow/src/kernel-stress-test/mmapstress03-1 2 00404000-00420000 r-xp 00004000 fc:03 829937 /home/joeblow/src/kernel-stress-test/mmapstress03-1 3 00420000-00431000 r--p 00020000 fc:03 829937 /home/joeblow/src/kernel-stress-test/mmapstress03-1 4 00431000-00432000 r--p 00030000 fc:03 829937 /home/joeblow/src/kernel-stress-test/mmapstress03-1 5 00432000-00433000 rw-p 00031000 fc:03 829937 /home/joeblow/src/kernel-stress-test/mmapstress03-1 6 00433000-0044f000 rw-p 00000000 00:00 0 7 26800000-26821000 rw-p 00000000 00:00 0 [heap] 8 26822000-26823000 rw-p 00000000 00:00 0 [heap] 9 26824000-26825000 rw-p 00000000 00:00 0 [heap] 10 26826000-26827000 rw-p 00000000 00:00 0 [heap] 11 26828000-26829000 rw-p 00000000 00:00 0 [heap] 12 2682a000-2682b000 rw-p 00000000 00:00 0 [heap] 13 2682c000-2682d000 rw-p 00000000 00:00 0 [heap] 14 2682e000-2682f000 rw-p 00000000 00:00 0 [heap] 15 26830000-26831000 rw-p 00000000 00:00 0 [heap] 16 26832000-26833000 rw-p 00000000 00:00 0 [heap] 17 26834000-26835000 rw-p 00000000 00:00 0 [heap] 18 26836000-26837000 rw-p 00000000 00:00 0 [heap] 19 26838000-26839000 rw-p 00000000 00:00 0 [heap] 20 2683a000-2683b000 rw-p 00000000 00:00 0 [heap] 21 2683c000-2683d000 rw-p 00000000 00:00 0 [heap] 22 2683e000-2683f000 rw-p 00000000 00:00 0 [heap] 23 26840000-26841000 rw-p 00000000 00:00 0 [heap] 24 26842000-26843000 rw-p 00000000 00:00 0 [heap] 25 26844000-26845000 rw-p 00000000 00:00 0 [heap] 26 26846000-26847000 rw-p 00000000 00:00 0 [heap] 27 26848000-26849000 rw-p 00000000 00:00 0 [heap] 28 2684a000-2684b000 rw-p 00000000 00:00 0 [heap] 29 2684c000-2684d000 rw-p 00000000 00:00 0 [heap] 30 2684e000-2684f000 rw-p 00000000 00:00 0 [heap] 31 26850000-26851000 rw-p 00000000 00:00 0 [heap] 32 26852000-26853000 rw-p 00000000 00:00 0 [heap] 33 26854000-26855000 rw-p 00000000 00:00 0 [heap] 34 26856000-26857000 rw-p 00000000 00:00 0 [heap] 35 26858000-26859000 rw-p 00000000 00:00 0 [heap] 36 2685a000-2685b000 rw-p 00000000 00:00 0 [heap] 37 2685c000-2685d000 rw-p 00000000 00:00 0 [heap] 38 2685e000-2685f000 rw-p 00000000 00:00 0 [heap] 39 26860000-26861000 rw-p 00000000 00:00 0 [heap] 40 26862000-26863000 rw-p 00000000 00:00 0 [heap] 41 26864000-26865000 rw-p 00000000 00:00 0 [heap] 42 26866000-26867000 rw-p 00000000 00:00 0 [heap] 43 26868000-26869000 rw-p 00000000 00:00 0 [heap] 44 2686a000-2686b000 rw-p 00000000 00:00 0 [heap] 45 2686c000-2686d000 rw-p 00000000 00:00 0 [heap] 46 2686e000-2686f000 rw-p 00000000 00:00 0 [heap] 47 26870000-26871000 rw-p 00000000 00:00 0 [heap] 48 26872000-26873000 rw-p 00000000 00:00 0 [heap] 49 26874000-26875000 rw-p 00000000 00:00 0 [heap] 50 26876000-26877000 rw-p 00000000 00:00 0 [heap] 51 26878000-26879000 rw-p 00000000 00:00 0 [heap] 52 2687a000-2687b000 rw-p 00000000 00:00 0 [heap] 53 2687c000-2687d000 rw-p 00000000 00:00 0 [heap] 54 2687e000-2687f000 rw-p 00000000 00:00 0 [heap] 55 26880000-26881000 rw-p 00000000 00:00 0 [heap] 56 26882000-26885000 rw-p 00000000 00:00 0 [heap] 57 7f4185a62000-7f4185a65000 rw-p 00000000 00:00 0 58 7f4185a65000-7f4185bd4000 r-xp 00000000 fc:03 1059004 /usr/lib64/libc.so.6 59 7f4185bd4000-7f4185c49000 r--p 0016f000 fc:03 1059004 /usr/lib64/libc.so.6 60 7f4185c49000-7f4185c4d000 r--p 001e4000 fc:03 1059004 /usr/lib64/libc.so.6 61 7f4185c4d000-7f4185c4f000 rw-p 001e8000 fc:03 1059004 /usr/lib64/libc.so.6 62 7f4185c4f000-7f4185c59000 rw-p 00000000 00:00 0 63 7f4185c6d000-7f4185c71000 r--p 00000000 00:00 0 [vvar] 64 7f4185c71000-7f4185c73000 r-xp 00000000 00:00 0 [vdso] 65 7f4185c73000-7f4185c9d000 r-xp 00000000 fc:03 1059001 /usr/lib64/ld-linux-x86-64.so.2 66 7f4185c9d000-7f4185ca8000 r--p 0002a000 fc:03 1059001 /usr/lib64/ld-linux-x86-64.so.2 67 7f4185ca8000-7f4185caa000 r--p 00035000 fc:03 1059001 /usr/lib64/ld-linux-x86-64.so.2 68 7f4185caa000-7f4185cac000 rw-p 00037000 fc:03 1059001 /usr/lib64/ld-linux-x86-64.so.2 69 7fff27119000-7fff2713a000 rw-p 00000000 00:00 0 [stack] 70 ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall] $ kill -CONT %1 mmapstress03 1 TPASS : Test passed [1]+ Done ./mmapstress03-1
Marc: I'm not going to weigh in on the kernel code, but I can help clarify the theory because I have dealt with similar issues in mathematics and in computer graphics. In mathematics, a fundamental distinction is between closed, open, and half-open intervals: Closed: a1 <= x <= a2 Open: a1 < x < a2 Half-open: a1 <= x < a2 And the problem is to select a model that lets you join adjacent intervals without them intersecting. For that, you have to use half-open intervals: Interval 1: a1 <= x < a2 Interval 2: a2 <= x < a3 Interval 3: a3 <= x < a4 If you look some memory maps, it is not immediately clear which pages are the in the interval and which are not. From Comment 120: 7f442ec94000-7f442ecbc000 r--p 00000000 00:21 1857352 /usr/lib64/libc.so.6 # Interval 1 ^^^^^^^^^^^^ 7f442ecbc000-7f442ee29000 r-xp 00028000 00:21 1857352 /usr/lib64/libc.so.6 # Interval 2 ^^^^^^^^^^^^ The upper endpoint (page) of Interval 1 has the same address as the lower endpoint (page) of Interval 2. And there is no way to tell, without looking at the code, whether those intervals are disjoint or not. If it were me, I would explicitly document the model: 1. The half-open interval model, as described above, is being used. 2. The upper endpoint is never in the interval.
The objective of Comment 164 is to develop enough theory to figure out how to express an empty heap in similar terms. In mathematics, an empty interval can be expressed this way: a1 <= x < a1 That has the form of a half-open interval, yet, when expanded, it means this: a1 < x or a1 = x or x < a1 Clearly, there is no value of x that could satisfy that expression -- the interval is empty, it has *no points*.
Correction: Wrong: a1 < x or a1 = x or x < a1 Right: ( a1 < x or a1 = x ) and x < a1 The conclusion is the same: The interval is empty.
Now we can consider the following problem. Locate two finite intervals on either side of an empty interval. Interval 1: a1 <= x < a2 Empty interval: a2 <= x < a2 Interval 2: a2 <= x < a3 Since the empty interval has no points, it serves no purpose as a "separator". Interval 1 and Interval 2 are disjoint, and there are no points separating them. So my conclusion is that the empty heap should be replaced by a one-page heap. The corresponding interval can be expressed this way: P1 <= A < P1+1 Here, P1 is a page address and P1+1 is the address of the next page. A is the address of pages within the interval, which, in this case, is only one address: A = P1. That would completely eliminate any special logic for the "empty" case.
(In reply to Steve from comment #167) > So my conclusion is that the empty heap should be replaced by a one-page heap. Supporting an empty heap is inconsistent with mmap(2), which does not support empty mappings: "The length argument specifies the length of the mapping (which must be greater than 0)." And that is confirmed with a test program: $ cat y4.c #include <stdlib.h> #include <stdio.h> #include <stdint.h> #include <string.h> #include <unistd.h> #include <errno.h> #include <sys/mman.h> #include <signal.h> int main(void) { void* pointer = (void*)0x25085000; int length = 0; pointer = mmap(pointer, length, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); if (pointer == MAP_FAILED) { printf("mmap: %s\n", strerror(errno)); return 1; } raise(SIGSTOP); return 0; } $ cc -o y4 y4.c $ ./y4 mmap: Invalid argument If "length" is changed to 1, you get a one-page mapping: $ ./y4 [1]+ Stopped ./y4 $ jobs -l [1]+ 5009 Stopped (signal) ./y4 $ grep 25085000 /proc/5009/maps 25085000-25086000 ---p 00000000 00:00 0
Note the "size 1" here: "The Maple Tree is a B-Tree data type which is optimized for storing non-overlapping ranges, including ranges of size 1." Maple Tree Author: Liam R. Howlett https://docs.kernel.org/next/core-api/maple_tree.html More about "maple trees" here: Introducing maple trees by Marta Rybczyńska February 12, 2021 https://lwn.net/Articles/845507/
(In reply to Steve from comment #164) > If it were me, I would explicitly document the model: > 1. The half-open interval model, as described above, is being used. > 2. The upper endpoint is never in the interval. Here is an example from include/linux/mm_types.h where that is actually done: /* VMA covers [vm_start; vm_end) addresses within mm */ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/mm_types.h?h=v6.10#n653 [vm_start; vm_end) ^ included ^ excluded This commit shows that the previous version did too, although with informal language: mm: rcu safe VMA freeing 2023-02-27 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/include/linux/mm_types.h?h=v6.10&id=20cce633f4254cc0df39665449726e3172518f6c
*** Bug 2303959 has been marked as a duplicate of this bug. ***
*** Bug 2304968 has been marked as a duplicate of this bug. ***
The fix was merged into the mainline kernel. https://lore.kernel.org/all/30fc5b38165e4eda57d640eca76b7df1@paul-moore.com/ It just needs to be merged into the next stable kernel and released by Fedora. I'm guessing that will be next week.
(In reply to reisner.marc from comment #173) > The fix was merged into the mainline kernel. Thanks for pointing that out. Mainline kernels are usually released on Sundays: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/refs/ Linux v6.11-rc4 should have this merge commit, which includes the fix: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9d5906799f7d89c9e12f6d2e0fccb00713c945ab I'm not sure about the release schedule for stable kernels, but Fedora users can look for kernel updates here: https://bodhi.fedoraproject.org/updates/?packages=kernel
FEDORA-2024-9d98836711 (kernel-6.10.6-200.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-9d98836711
FEDORA-2024-37e213a05c (kernel-6.10.6-100.fc39) has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2024-37e213a05c
FEDORA-2024-37e213a05c has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-37e213a05c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-37e213a05c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-9d98836711 has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-9d98836711` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-9d98836711 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
With the assumption that this patch [1] has solved the issue, some people who are affected tested 6.10.6 [2] as the patch was backported to that one: We have already two reports [3] that the issue is solved after updating to the 6.10.6. I assume some more reports will follow. I ask them to add karma to bodhi, but often people remain in ask.fedora, so some reports might appear only there. [1] https://lore.kernel.org/selinux/CAHC9VhTYiiyXasAY3+8n576yvx79W+ZjdB0P4+iCWzQpwW+VBQ@mail.gmail.com/ [2] https://bodhi.fedoraproject.org/updates/FEDORA-2024-9d98836711 [3] https://discussion.fedoraproject.org/t/selinux-execheap-denials/120638/79
The changelog shows that the Fedora kernel, kernel-6.10.6-200.fc40, is patched: https://koji.fedoraproject.org/koji/buildinfo?buildID=2532093
> The changelog shows that the Fedora kernel, kernel-6.10.6-200.fc40, is patched That's why we encouraged the affected users in ask.fp to test that one :) But at our stage, we can only assume and not verify that it is this very patch that made 6.10.6 to solve the issue, but only verify it is 6.10.6. But so far the indication in ask.fp is that the issue is solved
Here is the commit that patches Fedora kernel-6.10.6-200: https://src.fedoraproject.org/rpms/kernel/c/66aa3fc5031f2df27efcb8fd0a69722ff96c4c51?branch=f40 Note that patching a Fedora kernel also entails updating the changelog, the spec file, and the sources file.
FEDORA-2024-37e213a05c (kernel-6.10.6-100.fc39) has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-9d98836711 (kernel-6.10.6-200.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.
*** Bug 2305057 has been marked as a duplicate of this bug. ***
*** Bug 2305107 has been marked as a duplicate of this bug. ***
*** Bug 2305560 has been marked as a duplicate of this bug. ***