[RTEMS Project] #4844: Unchecked boundaries

[RTEMS trac]

#4844: Unchecked boundaries
----------------------------+---------------------------
  Reporter:  Daniel Páscoa  |      Owner:  (none)
      Type:  defect         |     Status:  new
  Priority:  normal         |  Milestone:
 Component:  admin          |    Version:  6
  Severity:  normal         |   Keywords:  qualification
Blocked By:                 |   Blocking:
----------------------------+---------------------------
 Consider checking for overflow situations and taking necessary actions in
 the three files designated below.
 \\
 ----

 **Memory copy function accesses out-of-bound array element in file
 cpukit\include\rtems\score\coremsgimpl.h (line 469)**

 Additional Information:
 The pointer to the structure that contains the buffer and the size is
 tested against NULL, but this finding refers to the fact that the argument
 size of is not validated against the maximum size of the destination
 and/or source buffer.

 This function can be traced up to rtems_message_queue_send and
 rtems_message_queue_receive functions where the buffer, its size and
 maximum size for queue messages are provided by the user. In the RTMES
 library at the moment of sending a message in the
 _CORE_message_queue_Submit function it is validated if the given size of
 the buffer is not above the user previously provided/configured maximum
 size, and returns an error if so. But it is up to the user to supply
 correct values. If the user tries to pass a buffer with 16 bytes, but
 indicates 32 bytes in the size there is no possible library validation
 that will detect an overflow situation. These cases must be detected by
 user code inspection/review.
 \\
 ----

 **Out of bound memory access (access exceeds upper limit of memory block)
 in file cpukit\include\rtems\score\mrspimpl.h (lines 120, 312, 315)**

 Additional Information:
 There is a Global variable  const size_t _Scheduler_Count =
 _CONFIGURE_SCHEDULER_COUNT; corresponding to the value configured
 statically depending of RTEMS_ARRAY_SIZE( _Scheduler_Table ), which is the
 number of shedulers.
 Relevant source code for lines 312 and 315, which are OK:

 {{{
 scheduler_count = _Scheduler_Count;
 for ( i = 0 ; i < scheduler_count ; ++i ) {
 (...)
     scheduler_of_index = &_Scheduler_Table[ i ];
 (...)
          mrsp->ceiling_priorities[ i ] =
 }}}


 Relevant source code for lines 120 and others, do not seem OK, because is
 not clear that the scheduler is always valid:

 {{{
 scheduler_index = _Scheduler_Get_index( scheduler ); // Note: translates
 to "return (uint32_t) (scheduler - &_Scheduler_Table[ 0 ]);"
 return mrsp->ceiling_priorities[ scheduler_index ];
 }}}
 \\
 ----

 **Returned pointer value points outside the original object (potential
 buffer overflow) for file cpukit\score\src\threadqops.c (line 294)**

 Consider checking for overflow situations and acting accordingly.

 Additional Information:
 The line 294 (the referred line is for version 3 of the QDP), from
 function _Thread_queue_Priority_queue_by_index:

 {{{
   return &heads->Priority[ scheduler_index ];
 }}}

 The priority field is declared as  Thread_queue_Priority_queue Priority[
 RTEMS_ZERO_LENGTH_ARRAY ]; which is a zero-length array...

 Then in threads.h file a Struct is defined as

 {{{
   struct Thread_queue_Configured_heads {
     Thread_queue_Heads Heads;
       Thread_queue_Priority_queue Priority[ _CONFIGURE_SCHEDULER_COUNT ];
   };
 }}}


 Which permits to access the zero-length array beyond the initial
 configuration of zero length (C99 permits it):
 C99 6.7.2.1, §16: As a special case, the last element of a structure with
 more than one named member may have an incomplete array type; this is
 called a flexible array member.

 But still, scheduler_index value is obtained by calling several other
 functions which extract information from a thread object in order to
 obtain and use the scheduler_index value in the
 _Thread_queue_Priority_queue_by_index function. It is not clear that that
 value is below _CONFIGURE_SCHEDULER_COUNT value.


 \\
 \\

 **Additional Notes:**
 This ticket was raised as an outcome of the Independent SW Verification
 and Validation (ISVV) for ESA-promoted RTEMS SMP Qualification Data Packs
 (https://rtems-qual.io.esa.int). The original ISVV reference for this
 issue is RTEMS-SMP-CODE-VER-036.

--
Ticket URL: <http://devel.rtems.org/ticket/4844>
RTEMS Project <http://www.rtems.org/>
RTEMS Project