Problem Description:
When semop(2) blocks waiting for a semaphore condition, it
releases the per-set lock and sleeps. Upon waking, it checks the
sequence number embedded in the semaphore set's IPC identifier to
detect whether the set was removed while the caller was asleep.
This sequence number is only 15 bits wide. If enough semaphore
sets are created and destroyed in the same table slot while a caller
is blocked, the counter wraps around, and semop(2) may falsely
conclude that the original set still exists. The subsequent access
to a semaphore within the set may then be out of bounds.
Impact:
An unprivileged local user can trigger an out-of-bounds access
on kernel heap memory, potentially leading to privilege escalation.