sysvsem: Fix another sequence number wraparound race

[markj]

Summary

semop() may sleep waiting for a semaphore. Upon waking up, it checks to
see if the set's sequence number has changed, indicating that the set
was removed. The sequence number is not wide enough to prevent a false
negative due to wraparound, in which case the subsequent access of
semakptr->u.__sem_base[sopptr->sem_num] may be out of bounds. This
race can be leveraged into privilege escalation.

I think the proper fix would be to add a wider sequence number to struct
semid_kernel. However, this would change the layout and so break
applications which define _WANT_SYSVSEM_INTERNALS.

Instead, simply re-validate the set size upon waking up. Move MAC and
permission checks into the loop as well. This still permits false
negatives, but I don't see how we can do better without changing the
ABI.

While here, use semvalid() instead of open-coding its implementation,
convert a couple of flags to be bool, and use a better variable name to
store required permissions.

Reported by: Reo Shiseki
Reported by: Andrew Griffiths

[markj]

Stray newline

[markj]

Fix an assertion

[kib]

Or, the wider seq number array might be added in parallel to the sema array.

[markj]

In D59347#1361768, @kib wrote:

Or, the wider seq number array might be added in parallel to the sema array.

Indeed, I didn't think of that...

[markj]

New approach: provide an array of 64-bit sequence numbers in parallel with
the main semaphore set array.