If you find a way, you'll get a CVE!
In seriousness, it is possible to find a way around SECCOMP in that if the handler thread listening to the messages from the SECCOMP-ed jail thread has a length check type bug, you could then exploit the handler thread (which presumably isn't as strongly SECCOMP-ed as the jail thread). Then you'd follow a normal exploit chain.
However, in the general case, folks are putting SECCOMP on a process because it's doing untrusted stuff. As a result it's unlikely that code execution on a jailed thread will allow for priv escalation, simply because it's unlikely the code trusts the inputs from the jailed thread!
Bypassing SECCOMP directly would be really hard, you'd have to find a kernel vulnerability in one of the allowed system calls, or a processor-level vulnerability. In strict mode this is normally considered intractable.