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.
The idf_test component was previously cleaned up but accidentally
reintroduced when adding esp32s31 support. It only contained an empty
header file (idf_performance_target.h) with no references anywhere
in the codebase.
Also removes the corresponding entry from astyle-rules.yml.
Validate MTU from DHCP option 26 against RFC 2132 minimum (68 bytes)
before applying to netif->mtu, preventing rogue DHCP servers from
setting MTU to 0 or other dangerously low values that cause integer
wraparound in IPv4 fragmentation.
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>
(cherry picked from commit 811c64c17c)
Add help text to the esp32h2/esp32h21/esp32h4 Kconfig.mac explaining
that these chips only consume one universally administered MAC address:
the IEEE 802.154 EUI-64 is derived from the base MAC and MAC_EXT, and
Bluetooth reuses the base MAC as-is (no BT offset, since there is no
Wi-Fi).
Add a matching 1-MAC derivation table and note to misc_system_api.rst
(EN and zh_CN) under a new `.. only:: esp32h2 or esp32h21 or esp32h4`
block, and exclude these targets from the generic 4/2 table.
Add an esp32s31-only note stating that the "Four" option may only be
used with a customer-provided custom base MAC range, since ESP32-S31
only provides two universally administered MAC addresses in eFuse.
Co-authored-by: Cursor <cursoragent@cursor.com>
(cherry picked from commit e3bc260178)
ESP32-H2/H21/H4 only provide a single universally administered MAC
address in eFuse (MAC_FACTORY), so switch their UNIVERSAL_MAC_ADDRESSES
Kconfig from "Two" to "One" to match the hardware allocation.
This is a functional no-op for MAC generation: the BT offset is only
applied when SOC_WIFI_SUPPORTED, and these chips have no Wi-Fi, so
Bluetooth already reuses the base MAC as-is; the IEEE 802.154 EUI-64 is
derived from the base MAC and MAC_EXT regardless. The only change is
the (otherwise unused) ESP_MAC_UNIVERSAL_MAC_ADDRESSES int value going
from 2 to 1.
Co-authored-by: Cursor <cursoragent@cursor.com>
(cherry picked from commit 431983a091)
ESP32-S31 only provides two universally administered MAC addresses in
eFuse. The previous default of "Four" led to WiFi softap and Ethernet
consuming global MAC slots (base+1/+3) that do not exist on this chip
and could collide with the Bluetooth MAC.
Switch the default to "Two" so Softap and Ethernet fall back to locally
administered MACs derived from the WiFi station and Bluetooth MACs.
The "Four" option is retained for customers who override the base MAC
with a custom range in which four universally administered MAC
addresses are allocated per device; the help text now documents this
constraint.
Co-authored-by: Cursor <cursoragent@cursor.com>
(cherry picked from commit f18f3814cc)
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.
Ashish Sharma
hebinglin
morris
Hu Rui
Mahavir Jain
wuzhenghui
Laukik Hase
David Cermak
Jack
Jin Cheng
Xu Si Yu
yangfeng
Tomáš Rohlínek