-
Bug
-
Resolution: Done-Errata
-
Major
-
rhel-8.10.z
-
None
-
libselinux-2.9-10.el8_10
-
Yes
-
Important
-
2
-
rhel-sst-security-selinux
-
ssg_security
-
24
-
2
-
False
-
-
None
-
Red Hat Enterprise Linux
-
SELINUX 250129: 1, SELINUX 250219: 2
-
x86_64
-
None
Various semodule commands segfault when an selinux policy is not installed.
Specifically, this happens when /etc/selinux/targeted/contexts/files/file_contexts doesn't exist, since libsemanage 2.9-10.el8_10.x86_64. In libsemanage 2.9-9.el8_6.x86_64, the same semodule commands work fine without that file.
Here's a trivial repro using a RHEL 8 UBI (which has no selinux policy installed):
$ docker run -it redhat/ubi8:8.10-1161 [root@09013a3d5424 /]# rpm -q libsemanage libsemanage-2.9-10.el8_10.x86_64 [root@09013a3d5424 /]# [root@09013a3d5424 /]# dnf install -y policycoreutils >/dev/null [root@09013a3d5424 /]# [root@09013a3d5424 /]# semodule -B Error obtaining file context handle: No such file or directory Segmentation fault (core dumped) [root@09013a3d5424 /]# [root@09013a3d5424 /]# echo $? 139
Whereas the problem did not occur on an image that did not contain https://access.redhat.com/errata/RHBA-2024:11159
$ docker run -it redhat/ubi8:8.10-1132.1733300785 [root@392e5f7699f9 /]# rpm -q libsemanage libsemanage-2.9-9.el8_6.x86_64 [root@392e5f7699f9 /]# [root@392e5f7699f9 /]# dnf install -y policycoreutils >/dev/null [root@392e5f7699f9 /]# [root@392e5f7699f9 /]# semodule -B [root@392e5f7699f9 /]# [root@392e5f7699f9 /]# echo $? 0
I tripped over this in a build of the selinux-policy package in a non-selinux environment. The selinux-policy specfile invokes semodule a handful of times, so the rpmbuild now reliably fails.
Here's a stack trace courtesy of gdb when running "semodule -B":
Program received signal SIGSEGV, Segmentation fault.
selabel_digest (rec=0x0, digest=digest@entry=0x7ffff7b1b598 <fc_digest>, digest_len=digest_len@entry=0x7ffff7b1b590 <fc_digest_len>,
specfiles=specfiles@entry=0x7fffffffb5b8, num_specfiles=num_specfiles@entry=0x7fffffffb5c0) at label.c:326
326 if (!rec->digest) {
(gdb) bt
#0 selabel_digest (rec=0x0, digest=digest@entry=0x7ffff7b1b598 <fc_digest>, digest_len=digest_len@entry=0x7ffff7b1b590 <fc_digest_len>,
specfiles=specfiles@entry=0x7fffffffb5b8, num_specfiles=num_specfiles@entry=0x7fffffffb5c0) at label.c:326
#1 0x00007ffff790baec in selinux_restorecon_set_sehandle (hndl=<optimized out>) at selinux_restorecon.c:1069
#2 0x00007ffff790bc05 in restorecon_init () at selinux_restorecon.c:97
#3 0x00007ffff67fee87 in __pthread_once_slow () from /lib64/libpthread.so.0
#4 0x00007ffff790bd54 in selinux_restorecon (pathname_orig=pathname_orig@entry=0x7fffffffc980 "/var/lib/selinux/targeted/tmp/modules",
restorecon_flags=restorecon_flags@entry=4100) at selinux_restorecon.c:798
#5 0x00007ffff76d725d in semanage_setfiles (path=path@entry=0x7fffffffc980 "/var/lib/selinux/targeted/tmp/modules") at semanage_store.c:3021
#6 0x00007ffff76d87bd in semanage_copy_dir_flags (src=0x55555575c760 "/var/lib/selinux/targeted/active",
dst=dst@entry=0x55555575d4e0 "/var/lib/selinux/targeted/tmp", flag=1) at semanage_store.c:826
#7 0x00007ffff76d8979 in semanage_copy_dir (dst=0x55555575d4e0 "/var/lib/selinux/targeted/tmp", src=<optimized out>) at semanage_store.c:779
#8 semanage_make_sandbox (sh=sh@entry=0x55555575b920) at semanage_store.c:972
#9 0x00007ffff76c3a59 in semanage_direct_begintrans (sh=0x55555575b920) at direct_api.c:411
#10 0x00007ffff76cc10c in semanage_begin_transaction_internal (sh=0x55555575b920) at handle.c:415
#11 0x000055555555674a in main ()
This happens because the patch https://gitlab.com/redhat/centos-stream/rpms/libsemanage/-/commit/997cbe2630d6429ee45f6cfef84ff7509a4ea058 introduced a call to semanage_setfiles from various functions such as semanage_copy_dir_flags.
The function semanage_setfiles calls selinux_restorecon, which calls restorecon_init, which calls selinux_restorecon_default_handle, which prints "Error obtaining file context handle: %s" and returns NULL when /etc/selinux/targeted/contexts/files/file_contexts does not exist.
The NULL is passed from restorecon_init to selinux_restorecon_set_sehandle, which in turn passes it to selabel_digest, which assumes that it can be dereferenced, leading to the segfault.
I'm not sure whether semodule commands are expected to work when there's no selinux policy installed, but it used to before libsemanage 2.9-10.el8_10.x86_64, so it feels like a regression. Even if it wasn't ever intended to work, a segfault is not pretty.
The patch https://github.com/SELinuxProject/selinux/commit/08f5e30177218fae7ce9f5c8d6856690126b2b30 probably would have helped avoid the segfault as it short-circuits selinux_restorecon_set_sehandle in the case where the handle is NULL.
- links to
-
RHBA-2025:145374
libselinux bug fix update
