AES key schedule not cleared by the TinyCrypt AES-CTR backend in MCUboot bootutil

When MCUboot is built with the TinyCrypt crypto backend (MCUBOOT_USE_TINYCRYPT), bootutil_aes_ctr_drop() in boot/bootutil/include/bootutil/crypto/aes_ctr_tinycrypt.h was an empty stub. The AES-CTR context for this backend is the fully expanded AES-128 key schedule (struct tc_aes_key_sched_struct). Generic code relies on this hook to release and clear key state, so with TinyCrypt nothing was cleared. The mbedTLS and PSA backends do free or destroy their key state here. As a result, boot_state_clear(), which boot_go() calls before handing off to the application, left the image's AES content-encryption key schedule in the static boot_data state. This is the case after an encrypted upgrade in single-image builds, where boot_enc_zeroize() is not called. boot_decrypt_key() likewise left the ECIES-derived key-encryption key schedule on the stack. The affected build uses MCUBOOT_ENC_IMAGES with TinyCrypt, which is the default ECDSA and Ed25519 backend in the Zephyr port. The first AES-128 round key equals the cipher key, so anyone who can read the leftover bootloader RAM after boot can recover the image content key and decrypt that encrypted image. That includes a physical attacker with debug or RAM access, or code later running on the device. This weakens image-encryption key confidentiality (and so the confidentiality of the encrypted image's plaintext). The device's long-term private decryption key is not exposed, and image authenticity is not affected. The fix wipes the context with bootutil_wipe_memory().

AES image key left on the stack after serial-recovery encrypted-image handling in MCUboot

In MCUboot's serial-recovery encrypted-image support (boot/boot_serial/src/boot_serial_encryption.c), decrypt_image_inplace() and boot_image_validate_encrypted() each keep a stack-local struct boot_status. boot_enc_load() writes the plaintext per-image AES key into its enckey[] field. Neither function cleared this structure before returning. In addition, a decrypt failure inside the per-sector loop of decrypt_image_inplace() returned early and skipped the total_out: cleanup, which left the expanded AES key context (enc_data) on the stack as well. The error paths of boot_image_validate_encrypted() similarly skipped boot_enc_zeroize(). The affected code is built when encrypted images (MCUBOOT_ENC_IMAGES, Zephyr CONFIG_BOOT_ENCRYPT_IMAGE) are combined with serial recovery. It runs when an encrypted image is uploaded to the primary slot over the recovery protocol, and when the image list or state is queried while an encrypted image is in the secondary slot. After these functions return, the image's AES content key remains in dead stack memory. An attacker who can later read device RAM, for example through a debug port or retained RAM, can recover it. This weakens the confidentiality of image-encryption keys within the bootloader trust boundary. A recovered key exposes the plaintext of the encrypted firmware image it protects. The device's long-term private decryption key is not exposed. No remote or recovery-protocol channel that returns this memory is known, so exploitation requires a separate memory-read capability.

openstack-nova: OpenStack Nova: Resource allocation issue due to unstripped hint data in server creation API

In OpenStack Nova before 33.0.2, the server create API does not strip certain hint data. The resulting instance has no Placement allocation.

Improper validation of Reverse Map Table (RMP) entries in the Secure Encrypted Virtualization (SEV) firmware could allow a privileged attacker to trigger concurrent modifications to RMP entries without proper synchronization potentially resulting in loss of data integrity.

A time-of-check to time-of-use (TOCTOU) race condition in the AMD SEV Secure Encrypted Virtualization (SEV) firmware could allow an attacker with administrative privileges to bypass security checks on scatter lists, potentially resulting in loss of guest integrity.

Improper Handling of Overlapping Protected Memory Ranges in SEV Firmware Leading to Integrity Loss

Improper handling of overlap between protected memory ranges in the Secure Encrypted Virtualization (SEV) firmware could allow a privileged attacker to cause misconfigurations in the RMP potentially resulting in loss of integrity.

Improper access control within the AMD Secure Encrypted Virtualization (SEV) firmware could allow an attacker with administrative privileges to tamper with memory, potentially resulting in loss of guest memory integrity.

Improper Resource Reuse in AMD SEV Firmware Enables Hypervisor RMP Write

Improper resource reuse in the AMD Secure Encrypted Virtualization (SEV) firmware could allow an attacker with hypervisor access to write to the Reverse Map Table (RMP) protected memory, potentially resulting in loss of guest memory integrity.

Hypervisor Metadata Manipulation in AMD SEV Firmware

Operation on a resource after expiration or release in the Secure Encrypted Virtualization (SEV) firmware could allow a malicious hypervisor to manipulate metadata pages potentially resulting in the loss of confidentiality and integrity of guest memory.

AMD SEV Firmware Unverified Ownership Check Enables Guest Memory Overwrite

Unverified ownership in Secure Encrypted Virtualization (SEV) firmware could allow a privileged attacker with access to a malicious hypervisor to overwrite guest memory if segmented Reverse Map Table (RMP) is enabled potentially resulting in loss of guest data integrity.

Improper access control in AMD SEV firmware allows malicious hypervisor to bypass RMP protections

Improper access control in AMD Secure Encrypted Virtualization (SEV) firmware could allow a malicious hypervisor to bypass Reverse Map Table (RMP) protections, potentially impacting the integrity of Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP) guest memory.

Ansible-core: ansible-core: ansible.builtin.git invokes git without a `--` separator, allowing argument injection via a `-`-leading repository url (e.g. --upload-pack) -> rce

A flaw was found in ansible-core's ansible.builtin.git module. The module invokes git (ls-remote, clone, fetch) with the repository URL as a positional argument and without a "--" separator, so a repository URL that begins with a dash is interpreted by git as a command-line option. A caller that passes an attacker-controlled repository URL to the module can trigger argument injection (for example --upload-pack/--exec), resulting in arbitrary command execution on the host running the module.

Foreman: api filter lookup ignores a search-limited filter permission

A flaw has been found in **permission filters** in the **foreman** package. The API loads a filter by its identifier and does not apply the search limit on the caller's permission. A low-privileged network attacker or user must already be allowed to delete filters for one role only. They can delete filters that belong to other unlocked roles. Those other roles then lose the access the deleted filters had granted.

Foreman: cross-tenant disclosure of template revisions via unauthorized audit lookup

A flaw was found in Foreman. The template revision endpoint does not enforce object-level authorization when retrieving an audited template revision. An authenticated, low privileged user with a template-related permission, such as view_ptables, can obtain historical template contents belonging to another organization or location by supplying the corresponding audit ID. This can result in unauthorized disclosure of historical template contents, which may contain sensitive configuration information, credentials, or other secrets. The REST API revision endpoints correctly restrict this lookup.

Linksys EA8100 Web UI cookie httponly flag

A vulnerability was identified in Linksys EA8100 1.0.3.216940. Impacted is an unknown function of the component Web UI. Such manipulation leads to cookie without 'httponly' flag. It is possible to launch the attack remotely. This attack is characterized by high complexity. The exploitability is considered difficult. The exploit is publicly available and might be used. The vendor was contacted early about this disclosure but did not respond in any way.

PostgreSQL type-cache invalidation gap executes arbitrary code

Type confusion from incomplete PostgreSQL type-cache invalidation allows an object creator to execute arbitrary code as the operating system user running the database, via a composite type change while its cache entry is being populated. Within major version 18, minor versions before PostgreSQL 18.7 are affected. Versions before PostgreSQL 18 are unaffected.

PostgreSQL logical replication can write to subscriber system catalogs, executing arbitrary code

Missing authorization in PostgreSQL logical replication allows a compromised publisher to execute arbitrary code as the operating system user running the superuser-owned subscription, via naming a system catalog as a replication target. Only subscriptions owned by a superuser are vulnerable. Versions before PostgreSQL 18.7, 17.12, 16.16, 15.20, and 14.25 are affected.

PostgreSQL REASSIGN OWNED bypasses role SET and CREATEDB checks

Missing authorization in PostgreSQL REASSIGN OWNED allows a role granted INHERIT but not SET to transfer objects to the granted role. It also allows reassignment of database ownership without the CREATEDB privilege. The equivalent ALTER ... OWNER commands block this. Versions before PostgreSQL 18.7, 17.12, 16.16, 15.20, and 14.25 are affected.

PostgreSQL extended-statistics pseudo-type confusion executes arbitrary code

Type confusion in PostgreSQL extended statistics allows an object creator to execute arbitrary code as the operating system user running the database, via a statistics expression of an anonymous RECORD type whose backend-local type identifier denotes a different row type in another session. Versions before PostgreSQL 18.7, 17.12, 16.16, 15.20, and 14.25 are affected.

PostgreSQL FDW batch-insert mismatch executes arbitrary code

Heap-based buffer overflow in PostgreSQL foreign batch inserts allows a foreign server to execute arbitrary code, via reporting that it inserted more rows than the server supplied. postgres_fdw can legitimately encounter this when a rule on the remote table expands an INSERT into additional rows. Versions before PostgreSQL 18.7, 17.12, 16.16, 15.20, and 14.25 are affected.