fix(drivers): harden multiple peripheral drivers against local DoS and memory corruption
Closes SEC-1183, SEC-1181, SEC-1191, SEC-1120, SEC-1154, SEC-1138, SEC-1136, and SEC-1140
See merge request espressif/esp-idf!50203
Guard start_command_read_blocks against cards that place TOKEN_BLOCK_START so early that extra_data_size exceeds the bytes expected on the current iteration. Without this check, the unsigned subtraction for will_receive underflows and propagates into memset, SPI transaction length, and memcpy counts against the fixed 516-byte block buffer.
spi_slave_queue_trans calls spi_slave_setup_priv_trans to allocate
DMA buffers, then tries xQueueSend. If the queue is full the function
returns ESP_ERR_TIMEOUT without freeing those buffers, leaking up to
2 * max_transfer_sz per failed call. Call spi_slave_uninstall_priv_trans
before returning the timeout.
jpeg_acquire_codec_handle acquires s_jpeg_platform.mutex at entry
but two ESP_RETURN_ON_* macros (semaphore-create and PM-lock-create
failure) return without releasing it. Replace with ESP_GOTO_ON_*
that jumps to a cleanup label which frees partial resources, NULLs
the codec pointer, and releases the mutex.
ESP_RETURN_ON_ERROR inside the s_i2c_platform.mutex critical section
returns without releasing the mutex, permanently blocking all I2C
bus operations. Replace with ESP_GOTO_ON_ERROR that jumps to a
cleanup label releasing the mutex before return.
CSI_FSM_INIT is 1, but the controller struct is zero-allocated.
Any failure before the former csi_fsm assignment (near the end of
esp_cam_new_csi_ctlr) jumped to err: which called s_del_csi_ctlr.
That function bailed out immediately because csi_fsm == 0, leaking
the claimed slot, queue, bridge, DMA channel, PM lock, and backup
buffer. Move csi_fsm = CSI_FSM_INIT right after a successful claim
so the err: path properly tears down all allocated resources.
Correct "802.154" to "802.15.4" and change the EUI-64 derivation notation
from base_mac[0:3]/base_mac[3:6] to the inclusive base_mac[0:2]/base_mac[3:5]
in the esp32h2/esp32h21/esp32h4 Kconfig.mac help text and the EN/zh_CN
misc_system_api docs.
Co-authored-by: Cursor <cursoragent@cursor.com>
fix(bt/bluedroid): fixed several security issues from NVIDIA
Closes SEC-084, SEC-713, SEC-1143, SEC-1153, SEC-1164, and SEC-1169
See merge request espressif/esp-idf!50200
fix(bt/example): Add print the device name to verify if it matches in HID example
Closes IDFCI-9124 and IDFCI-3631
See merge request espressif/esp-idf!50375
The initial CVE-2026-6682 fix (merged in !50362) hardened the exFAT
mount path, but the CVE as reported by runZero is a FAT32 defect in
mount_volume() and is reachable in ESP-IDF's 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 then places
`fs->database` inside the FAT region, so a forged directory entry in the
overlapping sector yields an attacker-controlled `finfo.fsize`. Any
caller that uses that size as a read length overflows its buffer with
attacker-controlled bytes (CVSS 7.6, path to RCE). The later
`fs->fsize < szbfat` check does not catch this because it compares the
un-doubled single-FAT size, which is still large.
Fix: reject a per-FAT size that overflows DWORD when multiplied by the
FAT count, and reject a reserved+FAT+root system-area size that overflows
DWORD, before either value is used to derive the data-area base.
The previous exFAT cluster-heap/bitmap 64-bit promotions are retained as
defense-in-depth and their comments relabeled accordingly (they are not
CVE-2026-6682). The SBOM cve-exclude-list reason is updated to describe
the FAT32 overflow and its fix.
Move per-target JPEG regdma retention descriptors out of esp_hal_jpeg
and into
esp_driver_jpeg so the codec driver owns its backup scope and restore
flow.
