Skip to content

fix: guard dlt_log_handle close+reset under dlt_mutex (CWE-362, MISRA R1.3)#831

Open
aki1770-del wants to merge 1 commit intoCOVESA:masterfrom
aki1770-del:fix/dlt-log-handle-mutex-253
Open

fix: guard dlt_log_handle close+reset under dlt_mutex (CWE-362, MISRA R1.3)#831
aki1770-del wants to merge 1 commit intoCOVESA:masterfrom
aki1770-del:fix/dlt-log-handle-mutex-253

Conversation

@aki1770-del
Copy link
Copy Markdown

Fixes #253.

Problem

dlt_user.dlt_log_handle is closed and reset without holding dlt_mutex in the DLT_RETURN_PIPE_ERROR case of dlt_user_log_send_log_v2() (src/lib/dlt_user.c):

// Before — no mutex held:
close(dlt_user.dlt_log_handle);
dlt_user.dlt_log_handle = -1;

Concurrent threads calling DLT_LOG_X() macros may read dlt_log_handle between the close() and the = -1 assignment (TOCTOU window), or write to a file descriptor that has already been closed and reallocated to an unrelated resource (fd-reuse hazard).

Safety classification:

  • CWE-362: Race Condition (TOCTOU on dlt_log_handle check + close)
  • CWE-416: fd-reuse hazard (closed fd may be reallocated to an unrelated resource)
  • MISRA C:2012 Rule 1.3: Undefined behavior — C11 §5.1.2.4 defines a data race on a non-atomic object as undefined behavior
  • AUTOSAR SWS_DLT_01000: freedom from interference between software components using the DLT API concurrently

Fix

Wrap the close+reset block under dlt_mutex_lock()/dlt_mutex_unlock():

// After — atomic close+reset:
dlt_mutex_lock();
close(dlt_user.dlt_log_handle);
dlt_user.dlt_log_handle = -1;
dlt_mutex_unlock();

dlt_mutex is a PTHREAD_MUTEX_RECURSIVE mutex — no deadlock risk from nested acquisition. The v1 send path (dlt_user_log_send_log()) already acquires dlt_mutex at function entry; this patch closes the equivalent gap introduced in the v2 path.

Secondary fix

Removes an orphaned dlt_mutex_unlock() in dlt_free() that was left without a matching dlt_mutex_lock(), immediately after the dlt_receiver_free() block. This unbalanced unlock would corrupt the mutex state on any platform that detects unlock-without-lock.

Continuity

  • dlt_user_init was made thread-safe in a prior patch (see ReleaseNotes.md: "dlt_user: Make dlt_init thread safe"). This PR closes the corresponding gap in the deinitialization and DLTv2 send paths.
  • Active MISRA compliance work is noted in ReleaseNotes.md ("DLT MISRA conform changes"). This patch closes the most significant remaining MISRA-relevant gap in dlt_user.c (Rule 1.3 — undefined behavior via data race).

Change scope

src/lib/dlt_user.c only. +2 lines, −3 lines. No new dependencies. No new files. No behavior change on the non-error path.

… R1.3)

This fixes a data race on dlt_user.dlt_log_handle in
dlt_user_log_send_log_v2() (the DLTv2 protocol send path).

The close+reset sequence (close(dlt_user.dlt_log_handle);
dlt_log_handle = -1;) in the DLT_RETURN_PIPE_ERROR case runs without
holding dlt_mutex, while concurrent threads may be reading or writing
dlt_log_handle via DLT_LOG_X() macros.

Safety classification:
- CWE-362: Race Condition (TOCTOU on dlt_log_handle check + close)
- CWE-416: fd-reuse hazard (closed fd may be reallocated to unrelated resource)
- MISRA C:2012 Rule 1.3: Undefined behavior (C11 §5.1.2.4 data race on non-atomic)
- AUTOSAR SWS_DLT_01000: freedom from interference between concurrent DLT users

The fix wraps the close+reset block under dlt_mutex_lock()/dlt_mutex_unlock().
dlt_mutex is a POSIX recursive mutex (PTHREAD_MUTEX_RECURSIVE) — no deadlock
risk. The v1 send path (dlt_user_log_send_log) already acquires dlt_mutex at
function entry; this patch closes the equivalent gap in the v2 path.

Also removes an orphaned dlt_mutex_unlock() in dlt_free() that was left without
a matching lock, introduced alongside the existing code.

Note: dlt_user_init was made thread-safe in a prior patch (see ReleaseNotes).
This PR closes the corresponding gap in the DLTv2 send path.

Fixes: COVESA#253
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

dlt_user.dlt_log_handle used without any form of syncronization

1 participant