So the bug doesn't seem to be hw specific, I have reproduced it also on x86_64
But the requirement here is that both audit record have the same timestamp.

Therefore I am reducing the severity.

# rpm -q audit
audit-2.4.1-5.el7.x86_64
# ausyscall --dump | grep 231 | awk '{print $2}'
exit_group
# cat test.log
type=SECCOMP msg=audit(1395076595.898:760): auid=1000 uid=0 gid=0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=3283 comm="test" sig=31 arch=80000016 syscall=231 compat=0 ip=0x7fe37deb9c09 code=0x0
type=SECCOMP msg=audit(1395076595.898:760): auid=1000 uid=0 gid=0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=3283 comm="test" sig=31 arch=c000003e syscall=231 compat=0 ip=0x7fe37deb9c09 code=0x0
# ausearch -if test.log -sc exit_group
----
time->Mon Mar 17 13:16:35 2014
type=SECCOMP msg=audit(1395076595.898:760): auid=1000 uid=0 gid=0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=3283 comm="test" sig=31 arch=c000003e syscall=231 compat=0 ip=0x7fe37deb9c09 code=0x0
type=SECCOMP msg=audit(1395076595.898:760): auid=1000 uid=0 gid=0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=3283 comm="test" sig=31 arch=80000016 syscall=231 compat=0 ip=0x7fe37deb9c09 code=0x0
# 
# vim test.log 
# cat test.log
type=SECCOMP msg=audit(1395076595.898:760): auid=1000 uid=0 gid=0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=3283 comm="test" sig=31 arch=c000003e syscall=231 compat=0 ip=0x7fe37deb9c09 code=0x0
type=SECCOMP msg=audit(1395076595.898:760): auid=1000 uid=0 gid=0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=3283 comm="test" sig=31 arch=80000016 syscall=231 compat=0 ip=0x7fe37deb9c09 code=0x0
# ausearch -if test.log -sc exit_group
<no matches>

The way that ausearch works is that if --arch is not given, then it checks the machine that its being run on and uses what it detects to select the arch lookup table. It can only search for one arch at a time.

This is because what its doing is taking the syscall text and turning it into a number. So, if you are running this on an x86_64 machine, then running ausearch -sc io_cancel, is the same as running ausearch -sc 210.

(In reply to Steve Grubb from comment #3)
> The way that ausearch works is that if --arch is not given, then it checks
> the machine that its being run on and uses what it detects to select the
> arch lookup table. It can only search for one arch at a time.
> 
> This is because what its doing is taking the syscall text and turning it
> into a number. So, if you are running this on an x86_64 machine, then
> running ausearch -sc io_cancel, is the same as running ausearch -sc 210.

So do we consider this a bug or no?

My understanding is that it is a bug. Despite the chance of having same timestamp for two records is low, it grows if we consider that logs are collected from multiple systems. But is it fair to say that log messages in comments above are artificial and it would probably require additional testing to confirm whether it happens also for real-life logs.

Normally logs from multiple systems have node in the audit trail. Node+time+serial is how events are classified.

(In reply to Steve Grubb from comment #6)
> Normally logs from multiple systems have node in the audit trail.
> Node+time+serial is how events are classified.

Let me summarize it - this issue can be hit only if there are at least two event with the same identifier. Such a situation cannot happen on a single system not used for a remote logging. If a remote logging is used, node names are part of identifiers and a probability that two events have the same timestamp _and_ sequence number _and_ node name negligible. 

Therefore after discussion with Karel I am closing this issue as NOTABUG.

(In reply to Ondrej Moriš from comment #7)

> ...
> same timestamp _and_ sequence number _and_ node name IS negligible.