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.
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.
The TX power range configurable in menuconfig only describes the maximum possible range.
Add a function to report the real range, and validate the configured BR/EDR TX power values during conroller init.
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/
f_getlabel() extracts the exFAT volume label with a loop bounded by the on-disk
byte dj.dir[XDIR_NumLabel] (0-255):
for (si = di = hs = 0; si < dj.dir[XDIR_NumLabel]; si++)
wc = ld_16(dj.dir + XDIR_Label + si * 2);
The exFAT label field holds at most 11 UTF-16 units (22 bytes). A crafted
directory entry with a larger count both reads past the 22-byte label field and,
through put_utf(... &label[di], 4), writes past the end of the caller-provided
label buffer (the canonical API examples use small fixed stack buffers) -> stack
buffer overflow.
Clamp the character count to the exFAT maximum of 11 before the extraction loop.
Record the CVE in the component SBOM.
Note: f_getlabel() takes no destination-buffer size, so under UTF-8 output
(FF_LFN_UNICODE == 2) 11 units can still expand to up to 34 bytes; the clamp
downgrades this from attacker-unbounded to spec-bounded. ESP-IDF's VFS layer
does not call f_getlabel(); direct callers on untrusted media should size their
buffer accordingly. A complete fix requires an upstream size-aware API change.
Reference: https://www.runzero.com/blog/fatfs-bugs/
After a direct multi-sector disk_read()/disk_write(), FatFs decides whether the
cached sector overlaps the direct-I/O range with:
fp->sect - sect < cc (and the FF_FS_TINY variant fs->winsect - sect < cc)
`sect`, `fp->sect` and `fs->winsect` are unsigned LBA_t. On 32-bit LBA_t builds,
if the cached sector is below `sect`, the subtraction wraps to a huge value that
can still compare `< cc`, so the code computes a bogus large offset:
- in f_write() it mis-copies from the direct write buffer (data corruption);
- in f_read() it is worse: memcpy(rbuff + (wrapped_offset * SS), ...) is an
out-of-bounds WRITE into the caller-supplied read buffer.
Add an explicit lower-bound check (fp->sect >= sect, resp. fs->winsect >= sect)
before the range test on both the read and write paths and both the FF_FS_TINY
and normal variants, so the condition is exactly "cached sector lies within
[sect, sect + cc)". Record the CVE in the component SBOM.
Reference: https://www.runzero.com/blog/fatfs-bugs/
The FAT12/16/32 mount path rejects a zero cluster count, but the exFAT path
accepted NumClusters == 0. That yields fs->n_fatent == 2, and sync_fs() later
computes the "percent in use" field as:
... * 100 / (fs->n_fatent - 2)
which is a division by zero (n_fatent - 2 == 0) -> crash. On a device that
syncs during an update this can brick the unit.
Reject ncl == 0 at exFAT mount time, and add a defense-in-depth
`fs->n_fatent > 2` guard around the division in sync_fs() so the divisor can
never be zero even if some future path produces such a filesystem object.
Record the CVE in the component SBOM.
Reference: https://www.runzero.com/blog/fatfs-bugs/
morris
Zhang Wen Xu
Samuel Obuch
C.S.M
Song Ruo Jing
Rahul Tank
Fu Hanxi
Wang Meng Yang
Marius Vikhammer
Martin Vychodil
Tomáš Rohlínek
Li Shuai
Jiang Jiang Jian
Mahavir Jain
Hu Rui
chenqingqing
zhangyanjiao
Nachiket Kukade
Meet Patel