Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Evaluation of a NULL pointer is undefined behavior. #1

Open
cmarsalc opened this issue Jan 11, 2024 · 2 comments
Open

Evaluation of a NULL pointer is undefined behavior. #1

cmarsalc opened this issue Jan 11, 2024 · 2 comments
Assignees
Labels
bug Something isn't working internal bug tracker Issue confirmed and reported into a ticket in the internal bug tracking system mw MW-related issue or pull-request rtos RTOS-related issue or pull-request

Comments

@cmarsalc
Copy link

Caution

The Issues are strictly limited for the reporting of problem encountered with the software provided in this project.
For any other problem related to the STM32 product, the performance, the hardware characteristics and boards, the tools the environment in general, please post your report to the ST Community in the STM32 MCUs dedicated page.

Describe the set-up

Any

Describe the bug (skip if none)

In the code the following idiom is used thoroughly as a "free reserved memory if ThreadX primitive construction has failed" pattern:

if ((attr->cb_mem == NULL) || (attr == NULL))

In this case attr may be NULL which will dereference a NULL pointer in the first expression. The effect of dereferencing a NULL pointer depends on several factors including whether address 0 is accessible from a given MCU (e,g,. some of them have TCM memory there), whether accessing an invalid address raises a bus fault (Cortex-M configuration) or whether the address 0 is initialized (depends no the startup code) and if it is not initialized which random value it may have and if dereferencing that random address triggers a fault or its just a no-operation.

In summary, we could conclude that is undefined behavior. Why cannot easily advance what may happen, even it is probable that it does not produces any fault, it just reads a random address that maybe zero or non zero and executes the clean-up code (which is correct for attr = NULL).

How to reproduce the bug (skip if none)

  1. Trigger a fault in a ThreadX primitive construction by instrumenting the code to do so.
  2. Put a value in address 0 to a MPU protected memory address
  3. Run the code

It will trigger a MPU fault.

Additional context

n/a

Screenshots

n/a

@ALABSTM ALABSTM self-assigned this Jan 12, 2024
@ALABSTM ALABSTM added bug Something isn't working mw MW-related issue or pull-request rtos RTOS-related issue or pull-request labels Jan 12, 2024
@ALABSTM
Copy link

ALABSTM commented Jan 12, 2024

Hi @cmarsalc,

Thank you for this report. Your point looks relevant. It will be forwarded to our development teams. I will keep you posted.

With regards,

@ALABSTM
Copy link

ALABSTM commented Jan 12, 2024

ST Internal Reference: 170640

@ALABSTM ALABSTM added the internal bug tracker Issue confirmed and reported into a ticket in the internal bug tracking system label Jan 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working internal bug tracker Issue confirmed and reported into a ticket in the internal bug tracking system mw MW-related issue or pull-request rtos RTOS-related issue or pull-request
Projects
Status: In progress
Development

No branches or pull requests

2 participants