The console transport read loop passed &linebuf[i] to uart_read_bytes()
before checking i < LINE_BUF_SIZE, so a line of LINE_BUF_SIZE or more
bytes without a terminator wrote one byte past the 256-byte linebuf
stack array.
Gate the read on the bounds check and reserve the final byte for the NUL
terminator (LINE_BUF_SIZE - 1), so the buffer handed to esp_console_run()
stays terminated even when an overlong line is truncated.
Closes https://github.com/espressif/esp-idf/issues/18638
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
sec1_new_session()/sec2_new_session() were calling sec*_close_session()
with the *new* session_id parameter instead of the existing
cur_session->id. The close handler validates `cur_session->id ==
session_id` before performing teardown, so the call always failed with
ESP_ERR_INVALID_STATE.
Effect: when a peer started a new provisioning session while another was
already active, the previous session's PSA keys, AES context, SRP handle
and username buffer were leaked instead of being destroyed. The cleared
session struct was overwritten by the new session, leaking the previous
key handles inside PSA Crypto and (for security2) leaking heap memory
for the username and SRP context.
Fix: pass cur_session->id so the close path actually executes the
teardown (psa_destroy_key/psa_cipher_abort/esp_srp_free/free) before the
new session takes over.
Add checks to validate client_verify_data pointer and length before
processing in handle_session_command1. Prevents NULL pointer dereference
when client omits verifier data in Session_Command1, which could cause
device crash during provisioning (remote DoS attack).
We would like to thank Pavel Kohout from Aisle Research for reporting
this vulnerability along with a mitigation strategy.
Using same IV in AES-GCM across multiple invocation of
encryption/decryption operations can pose a security risk. It can help
to reveal co-relation between different plaintexts.
This commit introduces a change to use part of IV as a monotonic
counter, which must be incremented after every AES-GCM invocation
on both the client and the device side.
Concept of patch version for a security scheme has been introduced here
which can help to differentiate a protocol behavior for the provisioning
entity. The security patch version will be available in the JSON
response for `proto-ver` endpoint request with the field
`sec_patch_ver`.
Please refer to documentation for more details on the changes required
on the provisioning entity side (e.g., PhoneApps).
fix(nt/bluedroid): Split the device name set functions
feat(bt/bluedroid): added APIs to get/set device name on BT GAP side
change(bt/common): Marked some APIs in device module as deprecated
1. esp_bt_dev_set_device_name
2. esp_bt_dev_get_device_name
change(bt/bluedroid): use BT GAP APIs to set/get device name in bluetooth classic examples
change(bt/bluedroid): use BT/BLE GAP APIs to set/get device name in coexist examples
Only pull in direct dependencies for the test apps, reducing build time
as well making it possible for CI to determine if the test should run or not
when dependencies are changed.
Using @brief for file description wrongly associates the documentation to an API.
Correct way to add file description is to use `@file` and then `@brief`. Corrected the same.
- Also added missing doc for esp_srp_handle_t
This commit adds a new feature to generate a salt and verifier pair for a given username and
password during the provisioning process. This is useful in scenarios where the pairing pin is
randomly generated and shown via some interface such as a display or console.
- Uses the provided username and password to generate a salt and verifier pair
- Adds support for dev mode where the pin/password can still be read from flash
* All components which won't build (yet) on Linux are excluded.
This enables switching to Linux in an application without
explicitly setting COMPONENTS to main in the main
CMakeLists.txt.
* ESP Timer provides headers for Linux now
* automatically disabling LWIP in Kconfig if it is not available
doc(linux): brought section
"Component Linux/Mock Support Overview" up to date
- `protocomm` depends on a config option `CONFIG_WIFI_PROV_BLE_FORCE_ENCRYPTION`
from `wifi_provisioning`; however, a lower layer component (`protocomm`) should
not have any `#ifdef` guard dependent on an upper layer component (`wifi_provisioning`).
- Added a new `ble_link_encryption` flag in `protocomm_ble_config_t` to manage the same
Closes https://github.com/espressif/esp-idf/issues/9443
