Comment 7 for bug 1812973

Regarding "This is arguably a kernel bug in that the kernel is not performing the seccomp filter check on the value that it is ultimately going to process." it should be pointed out that the seccomp man page has this to say:

"When checking values from args against a blacklist, keep in mind that arguments are often silently truncated before being processed, but after the seccomp check".

It goes on to give specific examples about syscalls with an int arg and how the full 64bits are in the seccomp data whereas the kernel will only look at the lowest 32bits, which is this bug (note, TIOCSTI is the only blacklist rule we have in snapd). The problem is that glibc and the kernel disagree on the function prototype (glibc man page says unsigned long and the kernel is considering it an int) and snapd got caught up in the discrepancy.

So, there is a known kernel limitation for when the time of check of the seccomp data is done and the ignored high bits are sent off to ioctl(), the kernel treats the 2nd arg of ioctl() as an int, the int limitation is documented in the libseccomp man page and there is a man page for ioctl that says the 2nd arg is an unsigned long. Ideally the kernel and glibc would align on this point, the kernel would lift this limitation or at least libseccomp would provide more assistance for dealing with this limitation.