When a Uri-Query filter ends in '=' with no value bytes (e.g. "rt="),
the filter parser computes resource_param.length == query_filter->length - 1
and query_pattern.length == 0, but then unconditionally dereferences
query_pattern.s[0] to test for a leading '/'. With the current allocator
strategy in coap_new_string() (which over-allocates by 1 byte for a NUL
terminator) this read lands on the NUL slot and is harmless; ASan does
not flag it on the dispatch path.
However, coap_print_wellknown is a public, exported COAP_API. A caller
passing a tightly-allocated coap_string_t (length == alloc_size, no
trailing slack) hits a 1-byte heap-buffer-overflow read at
src/coap_resource.c:178. The man page does not document any required
allocation slack, so this is an API-contract footgun rather than only an
internal invariant violation.
Mirror the existing guard already in place for the trailing '*' check
(line 183) by guarding the leading '/' check on query_pattern.length > 0.
Reproducer (clang + ASan, against HEAD e3f8cd0):
uint8_t *filter = malloc(3);
memcpy(filter, "rt=", 3);
coap_string_t qf = { .length = 3, .s = filter };
coap_print_wellknown(ctx, out, &out_buflen, 0, &qf);
/* AddressSanitizer: heap-buffer-overflow READ of size 1
* #0 coap_print_wellknown_lkd src/coap_resource.c:178
* #1 coap_print_wellknown src/coap_resource.c:110 */
After the fix the PoC exits cleanly; the sanity case "rt=x" (length>0)
continues to work unchanged.
Signed-off-by: OwenSanzas <zesheng@tamu.edu>
- fix(cmake): only create alias if it doesn't exist:
Zephyr v4.4 has moved to MbedTLS 4.x in following PR:
https://github.com/zephyrproject-rtos/zephyr/pull/104031
Zephyr now uses MbedTLS' CMakeLists, which exports targets
with NAMESPACE MbedTLS::, therefore MbedTLS::mbedtls,
MbedTLS::mbedx509, MbedTLS::tfpsacrypto aliases already exist
- fix(zephyr): v4.4: include correct mbedtls config based on zephyr version
CONFIG_MBEDTLS_CFG_FILE was deprecated. Instead, CONFIG_MBEDTLS_CONFIG_FILE
shall be used. This change supports both based on Kconfig symbols.
Signed-off-by: Krisztian Szilvasi <34309983+kr-t@users.noreply.github.com>
d33b7fa571 adds a call to setup_cpsk(),
which is only defined with COAP_PROXY_SUPPORT defined. This commit
enables said function if COAP_CLIENT_SUPPORT is enabled as well.
Don't report
WARN coap_socket_accept_tcp: accept: Resource temporarily unavailable
when multiple threads are trying to process the same incoming TCP connection.
When a FETCH request is OSCORE-protected the Content-Format option is
an inner (encrypted) option per RFC 8613 §4.1.3.1 and is legitimately
absent from the outer CoAP message. The existing RFC 8132 §2.3.1
check unconditionally rejects such requests with 4.15 (Unsupported
Content-Format) even when COAP_OSCORE_SUPPORT is disabled and the
application uses its own OSCORE stack.
Only enforce the Content-Format presence rule when no OSCORE option
is present in the outer request.
Fixes: https://github.com/obgm/libcoap/issues/1936
coap_new_cache_entry() does not correctly check for no PDU data when called
with COAP_CACHE_RECORD_PDU. No current libcoap code (examples and library)
call coap_new_cache_entry() with COAP_CACHE_RECORD_PDU set.
Internal function coap_pdu_resize() can be used to reduce a PDU size,
creating current options confusion. Fix is not to reduce PDU if new
size is smaller than the current used size. No current libcoap code calls
coap_pdu_resize() to reduce the size.
If there is an issue with the PDU options where the maximum used option
value is larger than the last defined option value, an assert() is triggered.
All of the coap_*_option() functions correctly manage pdu->max_opt, but
this issue could occur if coap_pdu_resize() was called to reduce the PDU size
below that of pdu->used_size.
Jon Shallow