Null pointer access when Size1 not included in multi block PUT

[cdurkin]

Environment

• Build System: Eclipse / MCUXpresso
• Operating System: Windows 11
• Hosted Environment: LwIP, FreeRTOS

libcoap Configuration Summary

libcoap package version : "4.3.5"
libcoap package source : "4.3.5"
libcoap API version : "3"
libcoap ABI version : "3.2.0"
libcoap libtool SO version : "5.0.2"
libcoap DTLS lib extn : "-mbedtls"
host system : "x86_64-pc-linux-gnu"
build with server support : "yes"
build with client support : "yes"
build with proxy support : "yes"
build with IPv4 support : "yes"
build with IPv6 support : "yes"
build with Unix socket support : "yes"
build with TCP support : "yes"
build DTLS support : "yes"
--> Mbed TLS around : "yes" (found Mbed TLS without pkg-config)
MbedTLS_CFLAGS : ""
MbedTLS_LIBS : ""
build DTLS support : "no"
add default names : "yes"
build Observe Persist : "yes"
build using epoll : "yes"
enable small stack size : "no"
enable separate responses : "yes"
enable OSCORE support : "yes"
enable Q-Block support : "yes"
enable max logging level : "none"
enable thread safe code : "yes"
enable recursive lock check : "yes"
build doxygen pages : "no"
build man pages : "no"
build unit test binary : "no"
build examples : "yes"
install examples source : "yes"
build with gcov support : "no"
build shared library : "yes"
build static library : "yes"

Problem Description

Crash (i.e. seg fault) when processing a multi block PUT request that doesn't include a Size1 option

n.b. no crash if Size1 option included in PUT request or PUT payload is small enough that multi block transfer is not required.

Expected Behavior

No crash

Other items if possible

I tracked this down to access of lg_srcv->last_token on lines 3108 and 3109 on coap_block.c : coap_handle_request_put_block() (towards bottom of function just before "goto give_app_data;").

It seems lg_srcv->last_token if only set if the Size1 option is included in the request, if Size1 option is not included in the request lg_srcv->last_token is null and hence it's access on line 3108 causes a seg fault.

I had a read of RFC7959 and couldn't see any indication that Size1 is mandatory so i believe not including Size1 in the request is valid but even if not it should be caught and handled and shouldn't be causing a crash.

Thanks
Chris

[mrdeep1]

Thank you for raising this and investigating the issue.

Please see if #1565 fixes your issue.

[cdurkin]

Hi, I tested and can confirm #1565 fixes the issue, thanks for the quick response, though looking at the issue numbers i assume it's a nice coincidence that you had already noticed this and had a fix ready :)

[mrdeep1]

Thanks for the confirmation. I am currently regression testing a re-worked solution as Size1 and Size2 are only hint sizes, and a way off hint size may also cause issues.

[mrdeep1]

@cdurkin #1565 has now been updated to handle Size1 hints that are not the exact size of the data payload, as well as when Size1 is not present. Please confirm that all works as expected here.

I assume it's a nice coincidence that you had already noticed this

Yes, see #1562 which had recently come in.

[cdurkin]

retested with latest code from updated #1565 and all still working :)

[mrdeep1]

Thanks for the feedback. Will merge the PR shortly.

[cdurkin]

I notice #1565 is now merged so closing this