Update esp_tls, esp_http_client docs and migration guide to reflect
the new esp_key_config_t interface and secure element PSA driver.
(cherry picked from commit 37808e2386)
Add generic secure element PSA driver with runtime callback registration.
Consolidate Kconfig into single MBEDTLS_SECURE_ELEMENT_DRIVER_ENABLED option.
Closes https://github.com/espressif/esp-idf/issues/18388
(cherry picked from commit 1c20f525b4)
Add ESP_KEY_SOURCE_BUFFER and ESP_KEY_SOURCE_PSA key sources so all
hardware backends (DS, ECDSA, secure element) are accessed via PSA
key IDs through a single esp_tls_cfg_t.client_key field.
(cherry picked from commit 36090b7161)
free_up_channels can only be called once for a started transaction.
Double free will undesirely stop the next picked 2D-DMA transaction on the same channel.
Co-authored-by: Cursor <cursoragent@cursor.com>
The initial CVE-2026-6682 fix hardened the exFAT mount path, but the CVE
as reported by runZero is a FAT32 defect in mount_volume() and is
reachable in the default configuration (exFAT and 64-bit LBA disabled).
This corrects the fix.
Root cause: `fasize *= fs->n_fats` is a DWORD multiply with no overflow
guard. A crafted BPB_FATSz32 such as 0x80000001 with NumFATs=2 wraps
`fasize` to 0x00000002. The wrapped (too-small) FAT size places
`fs->database` inside the FAT region, so a forged directory entry yields
an attacker-controlled `finfo.fsize`; a caller using it as a read length
overflows its buffer with attacker-controlled bytes (CVSS 7.6).
Fix: reject per-FAT and reserved+FAT+root system-area sizes that overflow
DWORD before they are used to derive the data-area base. The exFAT
cluster-heap/bitmap 64-bit promotions are retained as defense-in-depth
and relabeled (they are not CVE-2026-6682). SBOM reason updated.
The addend in `emac_hal_ptp_start()` was derived from the floating-point
`config->ptp_req_accuracy_ns` instead of the integer `base_increment`
register that actually drives the sub-second update. The cast to
`uint8_t` loses the fractional part, so the un-corrected addend leaves
the PTP clock running off-rate.
Example: with a 40 MHz XTAL and the default `req_accuracy_ns = 40`,
`base_increment` rounds 85.899 up to 86, leaving the clock +1170 ppm
fast — well outside the IEEE 802.1AS neighborRateRatio limit (~±200
ppm), so strict-1AS bridges refuse asCapable.
Compute the addend from the stored `base_increment` for both rollover
modes: `addend = 2^32 * clk_period_ns / increment_ns`.
Measured on ESP32-P4: neighborRateRatio drops from +1147.5 ppm to
+4.2 ppm, and asCapable is granted.
Co-authored-by: Ondrej Kosta <panzer412@gmail.com>
Document the three runZero "Seven FatFs bugs" CVEs that require no source change
in this component, so vulnerability scanners have their disposition:
- CVE-2026-6684: GPT partition-scan loop DoS. Already fixed upstream in R0.16,
where test_gpt_header() caps the partition-entry count at 128.
- CVE-2026-6686: read of uninitialized clusters after f_lseek() past EOF.
Longstanding, behavioral; not a memory-safety defect and zero-filling every
extended cluster is prohibitively costly on flash.
- CVE-2026-6688: long-filename overflow in downstream callers. Not exposed in
ESP-IDF; vfs_fat.c uses bounded copies and fname is bounded by FF_MAX_LFN.
Reference: https://www.runzero.com/blog/fatfs-bugs/
