| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A security flaw has been discovered in Linksys EA8100 1.0.3.216940. The affected element is an unknown function of the file etc/init.d/service_smbd.sh of the component SMB Service. Performing a manipulation of the argument ANON_ACCESS results in improper initialization. The attack can be initiated remotely. The exploit has been released to the public and may be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way. |
| In multiple functions of Android.bp, there is a possible way to bind to a privileged debug overlay service due to test or debugging code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In multiple locations, there is a possible way to bypass key authorization policies during wrapped key import due to a logic error. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In handle_rx_msg of tipc_virtio_dev, there is a possible Double Fetch TOCTOU due to Double Fetch. This could lead to local information disclosure with execution privileges needed. User interaction is for exploitation. |
| In fill of dma.rs, there is a possible way to trigger an out of bounds stack read during direct memory access fills due to a logic error. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation. |
| Improper exception handling in IOMMU could allow an invalidate command to be sent to PCIe devices that do not support Address Translation Cache (ATC), potentially resulting in denial of service. |
| Improper validation of specified quantities in input within AMD Power Management Firmware (PMFW) could allow a local attacker to pass unsanitized input, potentially resulting in a system crash or denial of service. |
| Improper validation of consistency within input in AMD SEV (Secure Encrypted Virtualization) firmware could allow an attacker with administrative privileges to create multiple RMP entries for the same guest physical address, potentially resulting in loss of guest integrity. |
| Improper authentication in Bootgen could result in the use of a fixed salt value for RSA padding instead of a randomly generated salt, potentially impacting data integrity. |
| Use after free in PostgreSQL COPY FROM error reporting allows a database user to disclose portions of server memory, via a longer input row following an ignored or nullified conversion error. file_fdw reaches the same code path in affected version 18. Within major versions 17-18, minor versions before PostgreSQL 18.7 and 17.12 are affected. Versions before PostgreSQL 17 are unaffected. |
| Inconsistent transition-capture state in PostgreSQL MERGE allows a table data modifier to make an AFTER trigger process the wrong new row, via a partitioned table MERGE that performs an INSERT before an UPDATE. Within major versions 15-18, minor versions before PostgreSQL 18.7, 17.12, 16.16, and 15.20 are affected. Versions before PostgreSQL 15 are unaffected. |
| Untrusted search path in PostgreSQL vacuumdb allows a database owner to execute arbitrary SQL as the database user running vacuumdb, via shadowing operators used in the --missing-stats-only catalog query. The pg_upgrade documentation recommends an affected vacuumdb invocation. Within major version 18, minor versions before PostgreSQL 18.7 are affected. Versions before PostgreSQL 18 are unaffected. |
| Improper input validation in PostgreSQL pg_restore allows a non-plain archive provider to execute arbitrary code as the operating system user running pg_restore, via a crafted archive. Note a contrast: crafted archive data may legitimately cause arbitrary SQL to execute at the restore destination, but it does not legitimately confer arbitrary code execution in the pg_restore OS process. Versions before PostgreSQL 18.7, 17.12, 16.16, 15.20, and 14.25 are affected. |
| Heap-based buffer overflow in PostgreSQL tsvector_delete() allows a database user to execute arbitrary code as the operating system user running the database, via a tsvector whose lexeme data uses a nonstandard but valid ordering that requires additional alignment padding in the result. Versions before PostgreSQL 18.7, 17.12, 16.16, 15.20, and 14.25 are affected. |
| SQL injection in PostgreSQL reindexdb allows an object creator to execute arbitrary SQL as the database user running reindexdb, via a crafted index name embedded in the parallel catalog query for --jobs with --index. Within major versions 17-18, minor versions before PostgreSQL 18.7 and 17.12 are affected. Versions before PostgreSQL 17 are unaffected. |
| Type confusion in PostgreSQL materialized set-returning functions allows a database user to execute arbitrary code as the operating system user running the database, via returning rows having different dynamic RECORD return types. json_populate_recordset() is one affected function. Versions before PostgreSQL 18.7, 17.12, 16.16, 15.20, and 14.25 are affected. |
| Type confusion in PostgreSQL anonymous RECORD types allows an object creator to execute arbitrary code as the operating system user running the database, via row types having dropped attributes in the same positions but with different widths or alignments. Within major versions 17-18, minor versions before PostgreSQL 18.7 and 17.12 are affected. Versions before PostgreSQL 17 are unaffected. |
| bootutil_img_hash() computes the image digest over ih_hdr_size + ih_img_size + ih_protect_tlv_size bytes, all three taken from the candidate image's header, and reads that span out of the slot without checking that it fits in the flash area. The three sizes are also summed without an overflow check. Nothing earlier on the validation path bounds the whole span either: bootutil_img_validate() compares the image size against bootutil_max_image_size() only after the hash has been computed.
The callers bound part of the span, or none of it:
On the swap and overwrite upgrade path, boot_validate_slot() first runs the image header check (boot_is_header_valid(), later boot_check_header_valid()). Before MCUboot 2.2.0 that check covered only ih_hdr_size + ih_img_size, so for every image the protected-TLV area (ih_protect_tlv_size, a uint16_t, up to 65535 bytes) was hashed without being bounded. From 2.2.0 the check includes ih_protect_tlv_size, except for a compressed image in the secondary slot when MCUBOOT_DECOMPRESS_IMAGES (CONFIG_BOOT_DECOMPRESSION) is enabled, which leaves the same gap of up to 64 KB.
The serial recovery image-list and image-state handlers (bs_list() and bs_set() in boot/boot_serial/src/boot_serial.c) and Zephyr's single-slot and firmware loaders (boot/zephyr/single_loader.c, boot/zephyr/firmware_loader.c) call bootutil_img_validate() with no header check at all, so on those paths ih_img_size is unbounded as well.
The image is hashed before its signature is checked, so anyone who can place an image in a slot (an OTA or SMP update delivered through the application, or serial recovery) reaches this read before authentication.
Whether a malformed header produces an actual read beyond the area depends on the flash backend:
Backends whose flash_area_read() bounds-checks the request (Zephyr, Espressif, NuttX, Mbed) return an error once the chunked read crosses the end of the area. Validation fails and the image is rejected, with no over-read.
With MCUBOOT_HASH_STORAGE_DIRECTLY (Zephyr CONFIG_BOOT_IMG_HASH_DIRECTLY_ON_STORAGE, available from 2.2.0, not enabled by default) the span is hashed through a single direct pointer into memory-mapped flash, with no bounds check.
The Cypress PSoC6 port's flash_area_read() (boot/cypress/cy_flash_pal/cy_flash_map.c, from 1.6.0) does not bound the read: its assert()s compare against the area's absolute offset rather than its size, and it copies with memcpy().
The bytes read past the area feed only the digest, which is compared internally and never returned, so nothing is disclosed. The realistic effect is a read fault during image validation: up to 64 KB past the slot on the upgrade path, and potentially much further on the paths that skip the header check. Where validation is repeated at every boot (a pending upgrade, or the single-slot loader checking its image), the fault can recur on each reset and keep the device from booting.
The fix makes bootutil_img_hash() add the three sizes with boot_u32_safe_add() and reject an image whose span, including the sector offset used in swap-using-offset mode, does not fit in the flash area, before any of it is hashed. Because the bound is applied where the bytes are read, it covers every caller. |
| The MCUboot TLV iterator bootutil_tlv_iter_next() in boot/bootutil/src/tlv.c walks image trailer TLVs with a single loop guard (it->tlv_off < it->tlv_end) and advances by sizeof(struct image_tlv) + tlv.it_len using the attacker-controlled it_len field, without validating that the entry's header or payload stays within it->tlv_end. As a result the 4-byte header read can extend up to 3 bytes past the declared TLV area, and the returned (off, len) can describe a payload that runs past it.
The path is pre-authentication: TLVs are parsed during bootutil_img_validate() before the signature is verified, and a crafted image can be presented through DFU / serial-recovery / OTA. However the impact is contained by surrounding guards: bootutil_img_validate() first rejects a TLV area larger than bootutil_max_image_size(), the default LOAD_IMAGE_DATA sink is flash_area_read() which bounds-checks against the flash partition and fails an out-of-partition read, and every payload consumer (EXPECTED_HASH_TLV, EXPECTED_KEY_TLV, EXPECTED_SIG_TLV, IMAGE_TLV_SEC_CNT) clamps len against a fixed buffer before copying.
The residual effect in a default flash build is therefore an out-of-region read confined to the attacker's own slot partition whose result is never observable, yielding at worst a clean validation failure rather than memory corruption or information disclosure. A genuine (though still bounded) out-of-bounds read remains under the non-default MCUBOOT_RAM_LOAD configuration, where LOAD_IMAGE_DATA is an unchecked memcpy. The fix is to validate each entry's header and payload against it->tlv_end inside the iterator. |
| MCUboot's Zephyr serial-recovery upload handler bs_upload() in boot/boot_serial/src/boot_serial.c decodes the host-supplied image field of an MCUmgr image-upload request into img_num (a full 32-bit value) and latches it on the off == 0 packet without any range check. It then passes img_num straight to flash_area_id_from_multi_image_slot(img_num, 0), which on the Zephyr port resolves to __flash_area_ids_for_slot() in boot/zephyr/include/sysflash/sysflash.h and indexes the static const int all_slots[] table as all_slots[img_num 2]. That table holds only MCUBOOT_IMAGE_NUMBER 2 entries, so any img_num >= MCUBOOT_IMAGE_NUMBER is an out-of-bounds read.
The path is reachable by anyone with access to the serial / SMP recovery console, which is unauthenticated by design, and the bad value is supplied before any image signature is verified. The defect is specific to the default non-direct upload path (MCUBOOT_SERIAL_DIRECT_IMAGE_UPLOAD disabled) on the Zephyr port with the array-backed slot layout (not CONFIG_SINGLE_APPLICATION_SLOT). It is not gated on a multi-image configuration: MCUBOOT_IMAGE_NUMBER defaults to 1, so even a default single-image build is affected for any image >= 1. The MCUBOOT_SERIAL_DIRECT_IMAGE_UPLOAD path is safe (its flash_area_id_from_direct_image() switch returns -EINVAL for unknown indices).
flash_area_id_from_multi_image_slot() takes a signed int image_index while img_num is uint32_t, so the attacker controls the sign of the index as well as its magnitude: an image of 0xFFFFFFFF converts to -1 and reads all_slots[-2], off the front of the table, while large positive values read off the end (CWE-192). Either way the index multiply img * 2 is performed in int, so a wild offset yields a bus/hard fault, giving a reliable denial of service of the bootloader during recovery. For moderately out-of-range indices the read returns adjacent .rodata as a garbage flash-area id that is handed to flash_area_open(); this normally fails with MGMT_ERR_EINVAL, but if the garbage id happens to match a valid non-image partition, the subsequent erase/write can target a partition outside the image set (CWE-787). The attacker-supplied value is never echoed back, so there is no information disclosure. The fix is to reject img_num >= BOOT_IMAGE_NUMBER on the off == 0 packet, before the slot lookup. The comparison must be made on the unsigned img_num: an equivalent guard applied after the conversion to int would not reject the negative case above. __flash_area_ids_for_slot() should bounds-check its own arguments as defence in depth.
This vulnerability was reported independently twice: by NVIDIA Project Vanessa on 2026-06-22, and by Kai Phan (@kaimandalic) on 2026-07-19 as GHSA-8v33-88p6-jffj, which is closed as a duplicate of this advisory. Both original reports are reproduced in full below. |
