github-starred/firejail

Fork 0

mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00

[GH-ISSUE #1329] Build failure: userfaultfd syscall #909

New issue

Closed

opened 2026-05-05 07:07:32 -06:00 by gitea-mirror · 3 comments

gitea-mirror commented

2026-05-05 07:07:32 -06:00

Owner

Originally created by @h1z1 on GitHub (Jun 8, 2017).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1329

Using latest release from GIT on CentOS 7, 4.9.11 kernel:


make[1]: Leaving directory `/home/build/git/firejail/src/fnet'
make -C src/fseccomp
make[1]: Entering directory `/home/build/git/firejail/src/fseccomp'
cc -ggdb  -O2 -DVERSION='"0.9.47"'  -DPREFIX='"/usr/local"'  -DSYSCONFDIR='"/usr/local/etc/firejail"' -DLIBDIR='"/usr/local/lib"' -DHAVE_X11 -DHAVE_PRIVATE_HOME  -DHAVE_OVERLAYFS -DHAVE_SECCOMP -DHAVE_GLOBALCFG -DHAVE_SECCOMP_H -DHAVE_CHROOT -DHAVE_NETWORK -DHAVE_USERNS -DHAVE_BIND -DHAVE_FILE_TRANSFER -DHAVE_WHITELIST -fstack-protector-all -D_FORTIFY_SOURCE=2 -fPIE -pie -Wformat -Wformat-security  -c seccomp.c -o seccomp.o
In file included from seccomp.c:23:0:
seccomp.c: In function ‘add_default_list’:
seccomp.c:232:27: error: ‘__NR_userfaultfd’ undeclared (first use in this function)
  filter_add_blacklist(fd, SYS_userfaultfd, 0);
                           ^
seccomp.c:232:27: note: each undeclared identifier is reported only once for each function it appears in
make[1]: *** [seccomp.o] Error 1
make[1]: Leaving directory `/home/build/git/firejail/src/fseccomp'
make: *** [src/fseccomp] Error 2
[build@localhost firejail]$ grep userfault -r  /usr/include/*
/usr/include/bits/syscall.h:#define SYS_userfaultfd __NR_userfaultfd
/usr/include/bits/syscall.h:#define SYS_userfaultfd __NR_userfaultfd
/usr/include/bits/syscall.h:#define SYS_userfaultfd __NR_userfaultfd
[build@localhost firejail]$ rpm -qf /usr/include/{bits,sys}/syscall.h
glibc-headers-2.17-157.el7_3.2.x86_64
glibc-headers-2.17-157.el7_3.2.x86_64
[build@localhost firejail]$

Appears added in e6805b6bbb ? Builds OK after commenting it out. bits/syscall.h is not included, not sure which location is "correct"..

Originally created by @h1z1 on GitHub (Jun 8, 2017). Original GitHub issue: https://github.com/netblue30/firejail/issues/1329 Using latest release from GIT on CentOS 7, 4.9.11 kernel: ``` make[1]: Leaving directory `/home/build/git/firejail/src/fnet' make -C src/fseccomp make[1]: Entering directory `/home/build/git/firejail/src/fseccomp' cc -ggdb -O2 -DVERSION='"0.9.47"' -DPREFIX='"/usr/local"' -DSYSCONFDIR='"/usr/local/etc/firejail"' -DLIBDIR='"/usr/local/lib"' -DHAVE_X11 -DHAVE_PRIVATE_HOME -DHAVE_OVERLAYFS -DHAVE_SECCOMP -DHAVE_GLOBALCFG -DHAVE_SECCOMP_H -DHAVE_CHROOT -DHAVE_NETWORK -DHAVE_USERNS -DHAVE_BIND -DHAVE_FILE_TRANSFER -DHAVE_WHITELIST -fstack-protector-all -D_FORTIFY_SOURCE=2 -fPIE -pie -Wformat -Wformat-security -c seccomp.c -o seccomp.o In file included from seccomp.c:23:0: seccomp.c: In function ‘add_default_list’: seccomp.c:232:27: error: ‘__NR_userfaultfd’ undeclared (first use in this function) filter_add_blacklist(fd, SYS_userfaultfd, 0); ^ seccomp.c:232:27: note: each undeclared identifier is reported only once for each function it appears in make[1]: *** [seccomp.o] Error 1 make[1]: Leaving directory `/home/build/git/firejail/src/fseccomp' make: *** [src/fseccomp] Error 2 [build@localhost firejail]$ grep userfault -r /usr/include/* /usr/include/bits/syscall.h:#define SYS_userfaultfd __NR_userfaultfd /usr/include/bits/syscall.h:#define SYS_userfaultfd __NR_userfaultfd /usr/include/bits/syscall.h:#define SYS_userfaultfd __NR_userfaultfd [build@localhost firejail]$ rpm -qf /usr/include/{bits,sys}/syscall.h glibc-headers-2.17-157.el7_3.2.x86_64 glibc-headers-2.17-157.el7_3.2.x86_64 [build@localhost firejail]$ ``` Appears added in e6805b6bbbe8f43b4099dc344535741ba9af6bca ? Builds OK after commenting it out. bits/syscall.h is not included, not sure which location is "correct"..

gitea-mirror

2026-05-05 07:07:32 -06:00

closed this issue
added the
information_old
label

gitea-mirror commented

2026-05-05 07:07:45 -06:00

Author

Owner

@netblue30 commented on GitHub (Jun 8, 2017):

It is working fine on my CentOS 7 system, I am running the original kernel 3.10, glibc-headers version 2.17-157.e17_3.1.x86_64. Grep:

$ grep -r userfault /usr/include/*
/usr/include/asm/unistd_32.h:#define __NR_userfaultfd 374
/usr/include/asm/unistd_64.h:#define __NR_userfaultfd 323
/usr/include/asm/unistd_x32.h:#define __NR_userfaultfd (__X32_SYSCALL_BIT + 323)
/usr/include/bits/syscall.h:#define SYS_userfaultfd __NR_userfaultfd
/usr/include/bits/syscall.h:#define SYS_userfaultfd __NR_userfaultfd
/usr/include/bits/syscall.h:#define SYS_userfaultfd __NR_userfaultfd
/usr/include/linux/userfaultfd.h: *  include/linux/userfaultfd.h
/usr/include/linux/userfaultfd.h:/* userfaultfd ioctl ids */

__NR_userfaultfd is defined in /usr/include/asm/unistd_64.h, it comes from:

$ rpm -qf /usr/include/asm/unistd_64.h
kernel-headers-3.10.0-514.10.2.el7.x86_64netblue@debian:~$

Probably you have a kernel-headers-3.9.x. There is quite a mismatch between unistd_64.h and bits/syscall.h on your system. The funny part is userfaultfd syscall was introduced in kernel 4.3. It looks like Red Hat are porting forward support for new syscalls into glibc-headers package.

Stay with the line commented out for now, until we can figure out what's going on there.

@netblue30 commented on GitHub (Jun 8, 2017): It is working fine on my CentOS 7 system, I am running the original kernel 3.10, glibc-headers version 2.17-157.e17_3.1.x86_64. Grep: ````` $ grep -r userfault /usr/include/* /usr/include/asm/unistd_32.h:#define __NR_userfaultfd 374 /usr/include/asm/unistd_64.h:#define __NR_userfaultfd 323 /usr/include/asm/unistd_x32.h:#define __NR_userfaultfd (__X32_SYSCALL_BIT + 323) /usr/include/bits/syscall.h:#define SYS_userfaultfd __NR_userfaultfd /usr/include/bits/syscall.h:#define SYS_userfaultfd __NR_userfaultfd /usr/include/bits/syscall.h:#define SYS_userfaultfd __NR_userfaultfd /usr/include/linux/userfaultfd.h: * include/linux/userfaultfd.h /usr/include/linux/userfaultfd.h:/* userfaultfd ioctl ids */ ````` __NR_userfaultfd is defined in /usr/include/asm/unistd_64.h, it comes from: ````` $ rpm -qf /usr/include/asm/unistd_64.h kernel-headers-3.10.0-514.10.2.el7.x86_64netblue@debian:~$ ````` Probably you have a kernel-headers-3.9.x. There is quite a mismatch between unistd_64.h and bits/syscall.h on your system. The funny part is userfaultfd syscall was introduced in kernel 4.3. It looks like Red Hat are porting forward support for new syscalls into glibc-headers package. Stay with the line commented out for now, until we can figure out what's going on there.

gitea-mirror commented

2026-05-05 07:07:48 -06:00

Author

Owner

@h1z1 commented on GitHub (Jun 9, 2017):

Will do. FWIW it's 3.10 but older

$ rpm -qf /usr/include/asm/unistd_64.h
kernel-headers-3.10.0-229.14.1.el7.x86_64
$ yum check-update kernel-headers -q
kernel-headers.x86_64                3.10.0-514.21.1.el7                 updates
$

Unrelated perhaps but just to clarify since you state CentOS 7, it's weird your prompt above shows debian :)

Regarding Red Hat release, I believe their versions don't really match upstream on purpose as they cherrypick things to backport?

$ grep -i sys_userfault /boot/System.map-*
/boot/System.map-3.10.0-514.6.1.el7.x86_64:ffffffff8124d650 T SyS_userfaultfd
/boot/System.map-3.10.0-514.6.1.el7.x86_64:ffffffff8124d650 T sys_userfaultfd
/boot/System.map-4.9.11-1.el7.elrepo.x86_64:ffffffff810a3e50 W sys_userfaultfd
$
$ ls -al /boot/System.map-*
-rw-------. 1 root root 2881776 Sep 15  2015 /boot/System.map-3.10.0-229.14.1.el7.x86_64
-rw-------. 1 root root 2881257 Mar  6  2015 /boot/System.map-3.10.0-229.el7.x86_64
-rw-------. 1 root root 3113404 Jan 18 08:17 /boot/System.map-3.10.0-514.6.1.el7.x86_64
-rw-------. 1 root root 3674581 Feb 18 19:09 /boot/System.map-4.9.11-1.el7.elrepo.x86_64
$

@h1z1 commented on GitHub (Jun 9, 2017): Will do. FWIW it's 3.10 but older ``` $ rpm -qf /usr/include/asm/unistd_64.h kernel-headers-3.10.0-229.14.1.el7.x86_64 $ yum check-update kernel-headers -q kernel-headers.x86_64 3.10.0-514.21.1.el7 updates $ ``` Unrelated perhaps but just to clarify since you state CentOS 7, it's weird your prompt above shows debian :) Regarding Red Hat release, I believe their versions don't really match upstream on purpose as they cherrypick things to backport? ``` $ grep -i sys_userfault /boot/System.map-* /boot/System.map-3.10.0-514.6.1.el7.x86_64:ffffffff8124d650 T SyS_userfaultfd /boot/System.map-3.10.0-514.6.1.el7.x86_64:ffffffff8124d650 T sys_userfaultfd /boot/System.map-4.9.11-1.el7.elrepo.x86_64:ffffffff810a3e50 W sys_userfaultfd $ $ ls -al /boot/System.map-* -rw-------. 1 root root 2881776 Sep 15 2015 /boot/System.map-3.10.0-229.14.1.el7.x86_64 -rw-------. 1 root root 2881257 Mar 6 2015 /boot/System.map-3.10.0-229.el7.x86_64 -rw-------. 1 root root 3113404 Jan 18 08:17 /boot/System.map-3.10.0-514.6.1.el7.x86_64 -rw-------. 1 root root 3674581 Feb 18 19:09 /boot/System.map-4.9.11-1.el7.elrepo.x86_64 $ ```

gitea-mirror commented

2026-05-05 07:07:52 -06:00

Author

Owner

@netblue30 commented on GitHub (Jun 9, 2017):

it's weird your prompt above shows debian

I was posting from a different computer. Anyway, they seem to be missing the definition for __NR_userfaultfd in /usr/include/bits/unistd_64.h file.

@netblue30 commented on GitHub (Jun 9, 2017): > it's weird your prompt above shows debian I was posting from a different computer. Anyway, they seem to be missing the definition for __NR_userfaultfd in /usr/include/bits/unistd_64.h file.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#909

No description provided.

Rows
Columns