#3449 new defect

Workspace corruption due to nested acquisition of API Mutex

Reported by: strauman Owned by:
Priority: high Milestone: 4.10.3
Component: score Version: 4.10
Severity: major Keywords:
Cc: Blocked By:
Blocking:

Description

rtems_task_delete is does most of its work holding the RTEMS allocator mutex. This mutex (_RTEMS_Allocator_Mutex) is created by _API_Mutex_Allocate() in CORE_MUTEX_NESTING_IS_ERROR mode.

Note that _API_Mutex_Lock() does *not* check the return status of the underlying _Core_mutex_Seize()!

I found that the allocator mutex *is* actually acquired recursively at least from one place: during task deletion when the RTEMS API extension is deleted this walks through all task variables and invokes their deletor.

In general it is unknown and therefore not guaranteed that such a deletor might not acquire the allocator mutex -- indeed I found that 'free' which is probably the most common deletor protects the
heap with _RTEMS_Lock_allocator() (i.e., the very allocator mutex)

Because _API_Mutex_Lock() fails to detect the unsuccessful nested attempt the code proceeds and releases the API mutex prematurely (upon return from free(), when the allocator mutex is unlocked).

The resulting lack of protection during the later steps of rtems_task_delete() opens the door for corruption.

Attachments (1)

rtems-trac#3449-nested-apimutex-4.10.diff (2.6 KB) - added by strauman on Jun 8, 2018 at 5:22:13 AM.
Patch that converts the API mutex to a recursive one. It also adds code that checks the return code of operations on the API mutex.

Download all attachments as: .zip

Change History (3)

Changed on Jun 8, 2018 at 5:22:13 AM by strauman

Patch that converts the API mutex to a recursive one. It also adds code that checks the return code of operations on the API mutex.

comment:1 Changed on Jun 14, 2018 at 11:19:36 AM by Sebastian Huber

The fatal error codes should be unique. Maybe we should add three new ones for RTEMS 4.10.

RTEMS 4.11 and later already allow nesting.

comment:2 Changed on Jun 14, 2018 at 2:30:29 PM by strauman

Agreed - however, the proper maintainer should make this decision as well as picking the names...

Note: See TracTickets for help on using tickets.