RTEMS | posix: A timed condition variable wait locks a mutex it did not own (#5819)

[Sebastian Huber (@sebhub)]

Issue created by Sebastian Huber: https://gitlab.rtems.org/rtems/rtos/rtems/-/work_items/5819



`pthread_cond_timedwait()` and `pthread_cond_clockwait()` add the
timeout before they release the mutex. With an invalid or past time
point, the timeout ends the wait at once with `EINVAL` or `ETIMEDOUT`.
The enqueue callout then calls `pthread_mutex_unlock()`. Its failure has
no effect, because the wait already ended.
`_POSIX_Condition_variables_Wait_support()` sees an error other than
`EPERM` and calls `pthread_mutex_lock()`.

So a caller which did not own the mutex gets `EINVAL` or `ETIMEDOUT`
and then owns the mutex. If another thread owns the mutex, the caller
blocks until that thread releases it. The same call with a valid future
time point returns `EPERM` and leaves the mutex alone.

The fix releases the mutex in
`_POSIX_Condition_variables_Enqueue_with_timeout_by_clock_id()` before
it adds the timeout. A failed unlock then ends the wait with `EPERM`,
and the timeout has no effect. An owned mutex behaves as before.

A validation test of `pthread_cond_timedwait()` found the defect.

This description was created with Claude Code assistance.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/work_items/5819
You're receiving this email because of your account on gitlab.rtems.org. Unsubscribe from this thread: https://gitlab.rtems.org/-/namespace/49/sent_notifications/6-e5k5xq1vt8s3ytxbxekvnd9o3-1d/unsubscribe | Manage all notifications: https://gitlab.rtems.org/-/profile/notifications | Help: https://gitlab.rtems.org/help


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20261112/75e2aad3/attachment.htm>