Description of problem: Running a simple program. Version-Release number of selected component: gcl-2.6.14-3.fc39 Additional info: reporter: libreport-2.17.11 comment: Running a simple program. runlevel: N 5 package: gcl-2.6.14-3.fc39 crash_function: do_gcl_abort rootdir: / journald_cursor: s=8ce7d0793b5d4423816eac809b75fb96;i=11d6571;b=92381493a519485395bd7461ed8705b1;m=2f429ab78;t=60b713cf4421a;x=a81b9f235bdb4c8d cmdline: /usr/lib/gcl-2.6.14/unixport/saved_ansi_gcl -dir /usr/lib/gcl-2.6.14/unixport/ -libdir /usr/lib/gcl-2.6.14/ -eval $'(setq si::*allow-gzipped-file* t)' -eval $'(setq si::*tk-library* "/usr/lib64/tk8.6")' day01-1.lisp backtrace_rating: 4 kernel: 6.6.2-201.fc39.x86_64 cgroup: 0::/user.slice/user-1000.slice/user/app.slice/app-org.kde.konsole-b2a36f56dab948619b816d1cfba92cc0.scope uid: 1000 executable: /usr/lib/gcl-2.6.14/unixport/saved_ansi_gcl type: CCpp reason: saved_ansi_gcl killed by SIGABRT Truncated backtrace: Thread no. 1 (46 frames) #4 do_gcl_abort at main.c:618 #5 error at main.c:636 #6 segmentation_catcher at main.c:823 #8 _IO_putc at putc.c:31 #9 my_putc at /usr/src/debug/gcl-2.6.14-3.fc39.x86_64/o/gcl_readline.d:192 #10 rl_putc_em at /usr/src/debug/gcl-2.6.14-3.fc39.x86_64/o/gcl_readline.d:228 #11 writec_stream at /usr/src/debug/gcl-2.6.14-3.fc39.x86_64/o/file.d:981 #12 princ_char at /usr/src/debug/gcl-2.6.14-3.fc39.x86_64/o/print.d:2109 #13 LI19 at gcl_serror.c:1283 #14 LI18 at gcl_serror.c:1239 #15 c_apply_n_fun at ../h/apply_n.h:92 #16 call_vfun at eval.c:122 #17 funcall at eval.c:162 #18 LI16 at gcl_serror.c:1080 #19 c_apply_n at ../h/apply_n.h:15 #20 c_apply_n_fun at ../h/apply_n.h:92 #21 call_vfun at eval.c:122 #22 funcall at eval.c:162 #23 IapplyVector at nfunlink.c:246 #24 Icall_gen_error_handler_ap at error.c:146 #25 Icall_gen_error_handler_noreturn at error.c:175 #26 error at main.c:633 #27 segmentation_catcher at main.c:823 #29 _IO_putc at putc.c:31 #30 my_putc at /usr/src/debug/gcl-2.6.14-3.fc39.x86_64/o/gcl_readline.d:192 #31 rl_putc_em at /usr/src/debug/gcl-2.6.14-3.fc39.x86_64/o/gcl_readline.d:228 #32 writec_stream at /usr/src/debug/gcl-2.6.14-3.fc39.x86_64/o/file.d:981 #33 princ_char at /usr/src/debug/gcl-2.6.14-3.fc39.x86_64/o/print.d:2109 #34 LI19 at gcl_serror.c:1283 #35 c_apply_n_fun at ../h/apply_n.h:92 #36 call_proc_new at funlink.c:456 #37 LnkTLI91 at gcl_serror.c:2018 #38 LI18 at gcl_serror.c:1239 #39 c_apply_n_fun at ../h/apply_n.h:92 #40 call_vfun at eval.c:122 #41 funcall at eval.c:162 #42 LI16 at gcl_serror.c:1080 #43 c_apply_n at ../h/apply_n.h:15 #44 c_apply_n_fun at ../h/apply_n.h:92 #45 call_vfun at eval.c:122 #46 funcall at eval.c:162 #47 IapplyVector at nfunlink.c:246 #48 Icall_gen_error_handler_ap at error.c:146 #49 Icall_gen_error_handler_noreturn at error.c:175 #50 assert_error at error.c:40 #51 gcl_init_alloc at alloc.c:1256
Created attachment 2002308 [details] File: os_info
Created attachment 2002309 [details] File: limits
Created attachment 2002310 [details] File: environ
Created attachment 2002311 [details] File: cpuinfo
Created attachment 2002312 [details] File: maps
Created attachment 2002313 [details] File: dso_list
Created attachment 2002314 [details] File: core_backtrace
Created attachment 2002315 [details] File: mountinfo
Created attachment 2002316 [details] File: backtrace
Created attachment 2002317 [details] File: open_fds
Created attachment 2002318 [details] File: proc_pid_status
Indeed, "setarch -X" no longer works in F39 or Rawhide. (I don't have an F38 box handy to see if the same is true there.) Running "sudo setenforce 0" makes gcl work again, but I cannot recommend that you expose your system that way. Reassigning to the selinux-policy component to see if the maintainers can tell us if "setarch -X" not working is deliberate or not. If it is deliberate, please reassign this bug back to gcl, but please also tell me what the gcl package needs to do instead of using "setarch -X".
John and Jerry, I am sorry but I don't understand what's the problem. Can you share reproducing steps and AVC denials you see?
Run: gcl Do not need to even run a specific file. When running, you'll see the following output: $ gcl mprotect failure: 0x883000 7282688 : Permission denied Unrecoverable error: Segmentation violation.. Aborted (core dumped)
What I can reproduce results in: type=PROCTITLE msg=audit(12/05/2023 06:49:26.182:571) : proctitle=/usr/lib/gcl-2.6.14/unixport/saved_ansi_gcl -dir /usr/lib/gcl-2.6.14/unixport/ -libdir /usr/lib/gcl-2.6.14/ -eval (setq si::*all type=SYSCALL msg=audit(12/05/2023 06:49:26.182:571) : arch=x86_64 syscall=mprotect per=PER_LINUX|~ADDR_NO_RANDOMIZE success=no exit=EACCES(Permission denied) a0=0x883000 a1=0x6f2000 a2=PROT_READ|PROT_WRITE|PROT_EXEC a3=0x7ffff7a8c4a8 items=0 ppid=1448 pid=1907 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=4 comm=saved_ansi_gcl exe=/usr/lib/gcl-2.6.14/unixport/saved_ansi_gcl subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(12/05/2023 06:49:26.182:571) : avc: denied { execheap } for pid=1907 comm=saved_ansi_gcl 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 audit2allow suggests: #!!!! This avc can be allowed using the boolean 'selinuxuser_execheap' allow unconfined_t self:process execheap; Please refer to the boolean description: # semanage boolean -l|grep execheap selinuxuser_execheap (off , off) 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 Additional information: The Linux implementation of mprotect (unlike POSIX) allows changing the access protection of memory on the heap, e. g. allocated using malloc. This AVC denial indicates that heap memory was supposed to be made executable. While the permission can be granted turning the selinuxuser_execheap boolean on as suggested by setroubleshoot, it should not be done without a thorough code review as in most cases it indicates a bug in the code. If anonymous executable memory is needed, another method should be considered, e. g. allocating memory using mmap. There was no related change in selinux-policy. If the permission is now needed, go ahead and change the boolean value. setsebool -P selinuxuser_execheap on
This actually seems to be a kernel regression caused by the following commits: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=68df1baf158fddc07b6f0333e4c81fe1ccecd6ff https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=11250fd12eb8a58205e69ea36f19fa8c084afb62 I will ask on the kernel mailing lists if this is an intended behavior and what can be done about it if it is not.
The issue is being discussed here: https://lore.kernel.org/selinux/CAFqZXNv0SVT0fkOK6neP9AXbj3nxJ61JAY4+zJzvxqJaeuhbFw@mail.gmail.com/
Thank you, Ondrej. I appreciate you diagnosing the issue and kicking off a discussion.
Update: A fix has now been merged into Andrew Morton's mm-hotfixes-stable tree and should get into mainline soon: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-hotfixes-stable&id=d3bb89ea9c13e5a98d2b7a0ba8e50a77893132cb
Fantastic. Thank you again, Ondrej.
This should be fixed in F39 as of kernel-6.7.3-200.fc39 - closing.