[RTEMS Project] #3772: missaligned pointer dereference in cpukit/libnetworking/libc/res_query.c:131

RTEMS trac trac at rtems.org
Thu Jul 25 00:13:25 UTC 2019


#3772: missaligned pointer dereference in
cpukit/libnetworking/libc/res_query.c:131
---------------------------------------+---------------------
 Reporter:  Jeffrey Hill               |       Owner:  (none)
     Type:  defect                     |      Status:  new
 Priority:  normal                     |   Milestone:
Component:  network/libbsd             |     Version:  4.11
 Severity:  normal                     |  Resolution:
 Keywords:  missaligned libnetworking  |  Blocked By:
 Blocking:                             |
---------------------------------------+---------------------

Comment (by Jeffrey Hill):

 > Are you compiling with any type of strict alignment flags?

 Not that I know of, this is what we are using, and probably nothing
 additional relevant in the specs file.

 -O3 -ggdb  -Wall -Wmissing-prototypes -Wimplicit-function-declaration
 -Wstrict-prototypes -Wnested-externs -MT serial/libserialio_a-mc68681.o
 -MD -MP -MF

 > A union requires more modification of the software I think.

 That would be more portable. The cplusplus 11 has alignment features but C
 doesn't yet at this time probably?

 > Are we sure 4 is a portable answer.

 The particular alignment issue causing the failure is probably a two byte
 one, based only on use of htons in that place in the code, but I
 definitely haven't looked around in this code to find the worst case
 alignment issue. Furthermore, I suspect there are additional instances of
 these char aligned buffers getting casted alarmingly into random data
 types therein ...

 > Is the stack itself properly aligned initially?

 I suppose that we _are_ an unusual BSP/ARCH, so there could be some
 suspicion there. I am looking at the _CPU_Context_Initialize we are using,
 which probably is mostly unmodified from stock RTEMS. The comment about
 the broken stack allocate functionality is concerning. I don't recall
 noticing it before. Nevertheless, wouldn't we see some fireworks if the
 stack pointer wasn't initially native word aligned?

 {{{
 void _CPU_Context_Initialize(
   Context_Control *context,
   void *stack_area_begin,
   size_t stack_area_size,
   uint32_t new_level,
   void (*entry_point)( void ),
   bool is_fp,
   void *tls_area
 )
 {
   const Nios2_MPU_Configuration *mpu_config =
 _Nios2_MPU_Get_configuration();
   uint32_t stack = (uint32_t) stack_area_begin + stack_area_size - 4;

   memset(context, 0, sizeof(*context));

   context->fp = stack;
   context->sp = stack;
   context->ra = (uint32_t) entry_point;
   /*
    * must init status field in the context before
    * calling _NIOS2_CPU_context_isr_set_level
    */
   context->status = NIOS2_STATUS_PIE;
   _NIOS2_CPU_context_isr_set_level ( context, new_level );

   if ( mpu_config != NULL ) {
     Nios2_MPU_Region_descriptor desc = {
       .index = mpu_config->data_index_for_stack_protection,
       /* FIXME: Brocken stack allocator */
       .base = (void *) ((int) stack_area_begin & ~((1 <<
 mpu_config->data_region_size_log2) - 1)),
       .end = (char *) stack_area_begin + stack_area_size,
       .perm = NIOS2_MPU_DATA_PERM_SVR_READWRITE_USER_NONE,
       .data = true,
       .cacheable = mpu_config->enable_data_cache_for_stack,
       .read = false,
       .write = true
     };
     bool ok = _Nios2_MPU_Setup_region_registers(
       mpu_config,
       &desc,
       &context->stack_mpubase,
       &context->stack_mpuacc
     );

     if ( !ok ) {
       /* The task stack allocator must ensure that the stack area is valid
 */
       _Terminate( INTERNAL_ERROR_CORE, false, 0xdeadbeef );
     }
   }
 }
 }}}

--
Ticket URL: <http://devel.rtems.org/ticket/3772#comment:3>
RTEMS Project <http://www.rtems.org/>
RTEMS Project


More information about the bugs mailing list