Upgrade NimBLE to latest release (IDFGH-12552)
Answers checklist.
- [X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
- [X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
- [X] I have searched the issue tracker for a similar issue and not found a similar issue.
General issue report
Hi @rahult-github
FYI: [ANNOUNCE] Apache Mynewt 1.12.0 and Apache Mynewt NimBLE 1.7.0 released https://lists.apache.org/thread/9g5vmz5mtlmz4qtnbk3988c1kdpwvkqc
Also note: CVE-2024-24746: Apache NimBLE: Denial of service in NimBLE Bluetooth stack in NimBLE-1.6.0. https://lists.apache.org/thread/bptkzc0o2ymjk8qqzqdmy39kcmh27078
When using Nimble, the following specifications are required in CMakeLists.txt.
set(EXTRA_COMPONENT_DIRS $ENV{IDF_PATH}/examples/bluetooth/nimble/common/nimble_peripheral_utils)
Is it possible to migrate Nimble to ESP-IDF Component Registry?
(EDIT) I found this. I'm going to try it now.
https://components.espressif.com/components/espressif/ble_conn_mgr
Hi @AxelLin ,
So just a week back or so ESP_IDF master branch has migrated to nimble-1.6.0-idf which is candidate for next branch off nimble. We will work on migrating to 1.7.0-idf but it will take little time.
As for the VU , we will quickly assess the actual change done to first check if it is applicable to esp solutions. If yes, then we will also backport it to all active branches.
The link points to denial of service attack, but will gather more information about same and address this .
@rahult-github These repository does not support ESP-IDF V5. https://github.com/espressif/esp-iot-solution/tree/master/components/bluetooth/ble_conn_mgr https://components.espressif.com/components/espressif/ble_conn_mgr
I would like the next version of nimble to be provided as an ESP-IDF Component Registry.
Hi @nopnop2002 ,
Please use a new ticket to track your request as it is different from the original issue of this ticket.
Will check internally if there are any plans to do so and will update.
Hi @AxelLin ,
So just a week back or so ESP_IDF master branch has migrated to nimble-1.6.0-idf which is candidate for next branch off nimble. We will work on migrating to 1.7.0-idf but it will take little time.
IMHO, given this timing the v1.7.0 is already released, I think move to v1.7.0 is a better option. So you don't need to maintain v1.6.0 branch which could save a lot efforts in the future.
As for the VU , we will quickly assess the actual change done to first check if it is applicable to esp solutions. If yes, then we will also backport it to all active branches.
The link points to denial of service attack, but will gather more information about same and address this .
@rahult-github Any update for the VU? Just wondering if existing nimble needs fix?
As for the VU , we will quickly assess the actual change done to first check if it is applicable to esp solutions. If yes, then we will also backport it to all active branches. The link points to denial of service attack, but will gather more information about same and address this .
@rahult-github Any update for the VU? Just wondering if existing nimble needs fix?
except release/v5.1 , the VU fix is merged and backported for all other branches.
master ( https://github.com/espressif/esp-idf/commit/052e884f3478ce27053a869e32c6502eb983a2cf )
Once release/v5.1 is also done, will update
@rahult-github
FRI, there is another CVE fixed in 3.6.0. https://nvd.nist.gov/vuln/detail/CVE-2024-30166
Maybe you need to check if this fix (https://github.com/Mbed-TLS/mbedtls/commit/a5c5c58107645c8d2ee3f2d59ef6924a66d4fb74) needs backport as well.
Hi @AxelLin , ok , since this comes under mbedTls specific component, i will redirect the request internally to concerned team.
@AxelLin We are in progress of upgrading to mbedTLS-3.6.0 on all of the release branches that support mbedtls-3.X.
It should be visible on GitHub in a few days. I think that should fix this CVE.
Hi @AxelLin , ok , since this comes under mbedTls specific component, i will redirect the request internally to concerned team.
@rahult-github Thanks, and I'm sorry that I just realized I posted in wrong thread...