A number of new *time64 syscalls are introduced in newer kernel series (>=5.1.x):
403: clock_gettime64 404: clock_settime64 405: clock_adjtime64 406: clock_getres_time64 407: clock_nanosleep_time64 408: timer_gettime64 409: timer_settime64 410: timerfd_gettime64 411: timerfd_settime64 412: utimensat_time64 413: pselect6_time64 414: ppoll_time64
In particular utimensat_time64 is now used inside glibc>=2.31
In turn ubuntu with has trouble running docker images of newer distros. This problem affects libseccomp<2.4.2, ie bionic (lts), and eoan, but not focal.
See a similar report at Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1770154
A solution could be to backport the related changes from 2.4.2 similarly to what happened for the statx whitelisting (#1755250).
A number of new *time64 syscalls are introduced in newer kernel series (>=5.1.x):
403: clock_gettime64 _time64
404: clock_settime64
405: clock_adjtime64
406: clock_getres_time64
407: clock_nanosleep
408: timer_gettime64
409: timer_settime64
410: timerfd_gettime64
411: timerfd_settime64
412: utimensat_time64
413: pselect6_time64
414: ppoll_time64
In particular utimensat_time64 is now used inside glibc>=2.31
In turn ubuntu with has trouble running docker images of newer distros.
This problem affects libseccomp<2.4.2, ie bionic (lts), and eoan, but not focal.
See a similar report at Fedora: https:/ /bugzilla. redhat. com/show_ bug.cgi? id=1770154
A solution could be to backport the related changes from 2.4.2 similarly to what happened for the statx whitelisting (#1755250).