Currently, s_mxic_set_required_regs() lacks checking for
CONFIG_SPI_FLASH_SUPPORT_MXIC_OPI_CHIP. And this causes a defined but not
used warning when MXIC flash driver is disabled in project config. So add
a #if check for this to supress warning.
Signed-off-by: Shengyu Qu <wiagn@4d2.org>
(cherry picked from commit 062c948c18)
SpiffsFS.create_file() rejected names only when strictly longer than
obj_name_len, but CONFIG_SPIFFS_OBJ_NAME_LEN's documented semantics
(see components/spiffs/Kconfig) are that the length includes the
zero-termination character, so the maximum number of actual name
characters is obj_name_len - 1.
With the old check, a name exactly obj_name_len characters long was
accepted. SpiffsObjIndexPage.to_binary() then computes the NUL padding
after the name as (obj_name_len - len(name)), which is 0 in that case,
so the generated image's fixed-size name field ends up with no NUL
terminator anywhere in its reserved region.
Fix the boundary so the generator enforces the same maximum length
that the Kconfig help text documents.
esp_partition_write/read/erase_range/mmap in partition_linux.c (the
`linux` target backend used by --preview set-target linux / host_test)
validated the requested range with `offset + size > partition->size`.
When `size` is close to SIZE_MAX, this addition wraps around size_t and
can evaluate to a small value, so the check passes even though the
request is far out of bounds. A caller passing e.g.
esp_partition_write(partition, 1, src, SIZE_MAX) sails through both
bounds checks and reaches the byte-copy loop with new_size == SIZE_MAX,
causing out-of-bounds reads/writes far past both the caller's buffer
and the mmap'd emulated-flash file.
Replace all four instances with the overflow-safe form already used by
the other esp_partition backends (partition_target.c,
partition_bootloader.c, partition_tee.c):
`size > partition->size - offset`, which is safe because the preceding
check already guarantees offset <= partition->size.
Signed-off-by: yi chen <94xhn1@gmail.com>
Set SECURE_BOOT_SHA384_EN when enabling ECDSA-P384 Secure Boot V2 on
ESP32-P4, as done on C5/H4/S31, so that ROM verifies the bootloader
using the SHA-384 scheme. The eFuse exists only on the rev >= v3.0
eFuse table, so the Kconfig option is gated on rev >= v3.0.
- Set internal NAN params based on the user configurable Platform
- On a secured NDP the responder could not derive keys
(passphrase/credential mismatch); reject cleanly and
fire ndp_terminated/ndp_confirm(REJECTED) on every
teardown path so the host frees the NDP-ID.
- Tear down the old NDP when the same peer re-initiates with
a new M1, instead of rejecting and leaking the NDL.
- Commit 08e98f6f30 utilises CONFIG_LWIP_ND6_SUPPORT_STATIC_ENTRIES
for adding static entries.
- It moves netif calls that generate GOT IPv6 to NAN_STARTED default
handler without guard, but guards the removal in NDP Confirm handler
- Fix the possible duplicate calls by putting calls from NAN_STARTED
handler under CONFIG_LWIP_ND6_SUPPORT_STATIC_ENTRIES guard
- subscriber security gate, so a gated (dropped) match still logged an
affirmative match line while no WIFI_EVENT_NAN_SVC_MATCH was posted.
Log only when the event is sent.
- security_cfg was copied into the service slot even with security_reqd=0,
while credential validation only runs when security_reqd is set. Such an
undeclared config silently armed the subscriber service-match security
gate, suppressing match events. Scrub security_cfg from the working copy
and warn instead.
