RTEMS | rtems_message_queue_receive(RTEMS_NO_WAIT) in ISR corrupts unrelated task Event wait (#5789)

[Sebastian Huber (@sebhub)]

Sebastian Huber commented: https://gitlab.rtems.org/rtems/rtos/rtems/-/work_items/5789#note_160407


Thanks for the analysis. We reproduced the bug on main at 32595811b30 with the `sparc/leon3` BSP on the SIS simulator.

The reproducer is a new test case in `spintrcritical10`. It uses `T_interrupt_test()` to fire an interrupt after `_Event_Seize()` sets the intend to block wait flag. The interrupt handler receives a pending message with `rtems_message_queue_receive( ..., RTEMS_NO_WAIT, 0 )`. It then sends the event which the task waits for.

| Configuration | Result |
| --- | --- |
| Uniprocessor | The event receive returns `RTEMS_TIMEOUT`. `Wait.count` is 2147483647. |
| SMP | Same result. |

The value 2147483647 is `INT_MAX`, the priority of a message from `rtems_message_queue_send()`. The event condition becomes this priority, so the event send cannot satisfy the waiting task.

The write is in `_CORE_message_queue_Seize()` in `cpukit/score/src/coremsgseize.c`. `_Event_Seize()` is the victim. The same race also affects `mq_receive()`. `_POSIX_Message_queue_Receive_support()` reads `executing->Wait.count` after the queue lock is released. An interrupt which receives a message in between overwrites the priority which the caller gets.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/work_items/5789#note_160407
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/5-d7lybt9jmd64xmblg5bb885ij-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/20261001/94c27485/attachment-0001.htm>