Summary

I spotted an ineffective size check implemented via assert() that may lead to a buffer overflow in RIOT source code at:
https://github.com/RIOT-OS/RIOT/blob/master/sys/net/ble/skald/skald_eddystone.c#L99-L107

Details

Most codebases define assertion macros which compile to a no-op on non-debug builds. If assertions are the only line of defense against untrusted input, the software may be exposed to attacks that leverage the lack of proper input checks. In detail, in the skald_eddystone_url_adv() function below, len is checked in an assertion and subsequently used in a call to memcpy(). If an attacker is able to provide a large url while assertions are compiled-out, they can write past the end of the pdu->url buffer.

Please refer to the marked lines below:

void skald_eddystone_url_adv(skald_ctx_t *ctx,
                             uint8_t scheme, const char *url, uint8_t tx_pwr,
                             uint32_t adv_itvl_ms)
{
    assert(url && ctx);
    size_t len = strlen(url);
    assert(len <= (NETDEV_BLE_PDU_MAXLEN - (URL_HDR_LEN + PREAMBLE_LEN))); // VULN: len is checked only via an assertion

    eddy_url_t *pdu = (eddy_url_t *)ctx->pkt.pdu;
    _init_pre(&pdu->pre, EDDYSTONE_URL, (URL_HDR_LEN + len));

    /* set remaining service data fields */
    pdu->tx_pwr = tx_pwr;
    pdu->scheme = scheme;
    memcpy(pdu->url, url, len); // VULN: if len is actually larger than expected there's a potential buffer overflow

    /* start advertising */
    ctx->pkt.len = (sizeof(pre_t) + 2 + len);
    ctx->adv_itvl_ms = adv_itvl_ms;
    skald_adv_start(ctx);
}

Impact

If the unchecked input above is attacker-controlled and crosses a security boundary, the impact of the buffer overflow vulnerability could range from denial of service to arbitrary code execution.