On Wed, May 28, 2014 at 2:19 PM, H. Peter Anvin <h...@linux.intel.com> wrote: > On 05/28/2014 02:15 PM, Andy Lutomirski wrote: >>> >>>> 3. The OOPS you're fixing doesn't seem like it's fixed. What if some >>>> other random high bits are set? >>> >>> There is a range check in entry_*.S for the system call. >> >> I can imagine that causing a certain amount of confusion to fancy >> seccomp users. Oh, well. No one that I know of has complained yet. >> > > I don't know how seccomp or audit deal with out-of-range syscall > numbers, so that might be worth taking a look at.
audit oopses, apparently. seccomp will tell BPF about it and follow directions, barring bugs. However: are you sure that entry_64.S handles this? It looks like tracesys has higher priority than badsys. And strace can certainly see out-of-range syscalls. And I can oops audit by doing: auditctl -a exit,always -S open ./a.out where a.out is this: #include <stdio.h> #include <sys/syscall.h> int main() { long i; for (i = 1000; ; i += 64 * 4096) syscall(i, 0, 0, 0, 0, 0, 0); return 0; } I would *love* to deprecate the entire syscall auditing mechanism. Or at least I'd love to have distros stop using it. I'll go ask for a CVE number. Sigh. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/