[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