net: lib: coap_client: Fix potentially invalid path/options pointer #97328
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Use buffers instead of pointers for path and extra options provided in the struct coap_client_request, so that the library keeps a copy of the path/options instead of pointers. That way, the library can still work correctly in case of retransmissions or block transfer in case when the original path or options were automatic variables that went out of context. Signed-off-by: Robert Lubos <[email protected]>
Move the definition from the test suite to a public header. Signed-off-by: Robert Lubos <[email protected]>
Keep a separate buffer for each request context instead of having a single common buffer for the entire client context. This allows to simplify the retransmission logic, as parallel requests will no longer overwrite the buffer for each other. That way, we can simply retransmit the packet w/o a need to recreate it, and thus reach to the payload pointer or callback. This removes the requirement to keep the payload pointer, provided to asynchronous coap_client_req() call, valid throughout the exchange lifetime for simple cases (i.e. no block transfer used). In case of block transfer, this is unavoidable and needs to be documented. Signed-off-by: Robert Lubos <[email protected]>
1 task
zephyrbot
added
area: Networking
Release Notes
rlubos
force-pushed
the
net/coap-client-request-pointers
branch
from
1e04c20 to
19c622b
Compare
pdgendt
reviewed
Oct 10, 2025
rlubos
force-pushed
the
net/coap-client-request-pointers
branch
from
19c622b to
83395d8
Compare
Cover struct coap_client_request changes in the migration guide. Signed-off-by: Robert Lubos <[email protected]>
rlubos
force-pushed
the
net/coap-client-request-pointers
branch
from
83395d8 to
a4ecb40
Compare
|
pdgendt
approved these changes
Oct 10, 2025
jukkar
approved these changes
Oct 13, 2025
SeppoTakalo
reviewed
Oct 14, 2025
| config COAP_CLIENT_MAX_PATH_LENGTH | ||
| int "Maximum length of the path string" | ||
| default 64 | ||
| range 1 128 |
There was a problem hiding this comment.
Why do we set the range here?
This might end up limiting some use-cases where lots of parameters are supplied in path.
I would leave the range out, and just build-time assert that it is more than zero.
There was a problem hiding this comment.
The only reason I had was that COAP_CLIENT_MESSAGE_HEADER_SIZE config already had a range on it (
zephyr/subsys/net/lib/coap/Kconfig
Line 135 in cb77257
|
@juhaylinen Do you know any nRF Cloud path lengths? Is this going to kick us in the next upmerge? |
Maximum path length for Device provisioning client seems to be around 88. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The library used to store the path/options pointer within the request context and used them in case of retransmissions/block transfer/cancellation. This however didn't work well if the pointer provided were pointing to for example memory on a stack, that could've been overwritten.
Therefore, rework how the data is passed to the library to make it more robust. Instead of using pointer, allocate buffers within request context for path/options so that the data remains valid throughout the exchange lifetime.
Additionally, rework the retransmission logic, so that the request is not built from scratch, but instead the originally created message is reused. This also solves the transient pointer issue for payload in simple cases. For block transfer, the payload pointer needs to remain valid throughout the exchange, which has been documented.
Fixes #97115