Problem Description:
The RACK setsockopt(2) handler drops the connection lock in
order to copy option data from userspace, then reacquires the lock.
After reacquiring, it verifies that the TCP stack had not been
switched away, but did not reload its pointer to the stack's
per-connection control block. If userspace switches stacks twice
during this window, the check will succeed but the saved pointer
will refer to freed memory.
Impact:
The bug may be exploitable by an unprivileged local user to
escalate privileges.