Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Learn more about Collectives

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

I am working on a large embedded system (STM32F423 CPU and CubeIDE environment on Windows, all the code is in C), and recently I found out that there must be a buffer overflow somewhere. The mbedtls library reports an error suggesting the server did not respond in the required time. The thing is that when I comment one function I added recently (completely unrelated, and not even executed before the error occurs), everything works fine. I think the presence of the function causes the memory arrangement to shift, and some other code has a buffer overflow bug, that overwrites some variable in the mbedtls library. Mbedtls then sends some invalid data to the server, and the server does not respond. That's my guess.

I tried updating mbedtls to the newest version. I also tried to find problematic pointer operations by:

  • adding various compiler flags: -Wabsolute-value , -Warray-bounds , -Wformat-overflow , -Wstringpop-overflow
  • -fbounds-check - this does not seem to do anything, because the compiled code has the same size with and without it,
  • adding access attribute to most functions that take a pointer parameter,
  • adding -fsanitize=address to the compiler options.
  • The last thing is problematic, because it triggers the compiler error:

    arm-none-eabi-gcc: fatal error: cannot read spec file 'libsanitizer.spec': No such file or directory
    

    Do you know how to add the sanitizer support to the GCC in the CubeIDE toolchain?

    I have also got a suggestion to use git bisect, and I am yet going to try it, although my hopes are not high, because most likely the bug has been introduced a long time ago, and the revision where it was introduced will work fine, because of different memory arrangement.

    Also having the sanitizer would help finding other pointer issues I might have and not know about.

    I've not seen any evidence the address sanitiser has been ported to run on embedded systems. CLang has a static analysis mode that can find these types of bugs. Tools like pc-lint can also find many problems like this, but it does cost money. This is all assuming it is a buffer overflow. Sound possible, but not definitive. Does your new function also have data in the .bss or .data sections? If not, it will just be moving things in the .text section, which sounds unlikely to be involved with a buffer overflow. – pmacfarlane Oct 29, 2022 at 19:34 You could use your linker script to align the mbedtls data or bss to an aligned address, essentially creating a "space" before it. If that fixes it, it might confirm your theory, and you could set a data breakpoint on the first word of the "space" and see what is hitting it. – pmacfarlane Oct 29, 2022 at 19:39 Note that questions asking for recommendations of tools (such as linkers with certain features) are off-topic. – outis Oct 30, 2022 at 20:25 @outis, my question wasn't about tool recommendation, but pmacfarlane's comments could qualify as answers, as they propose valid alternate solutions to my problem. – Kazimierz Król Nov 1, 2022 at 8:58 @KazimierzKról: most of your question isn't; my comment was referring to the part that I edited out, asking about other toolchains that could be used. In part, the comment was to give reason for the edit. – outis Nov 1, 2022 at 9:26

    While the documentation for GCC's AddressSanitizer lists ARM as a supported platform, it's only for Android. The same is true for CLang's AddressSanitizer.

    To add support, you'd need to port an ASAN run-time library (such as the Android, GCC or LLVM libraries) and define the .spec file. The exact process in its entirety is beyond the scope of SO, though specific issues that could crop up may be on-topic.

    Thanks for contributing an answer to Stack Overflow!

    • Please be sure to answer the question. Provide details and share your research!

    But avoid

    • Asking for help, clarification, or responding to other answers.
    • Making statements based on opinion; back them up with references or personal experience.

    To learn more, see our tips on writing great answers.