Improper Enforcement of Message Integrity During Transmission in a Communication Channel vulnerability in Mitsubishi Electric MELSEC MX Controller MX-R model, MELSEC MX Controller MX-F model, Master/local module, CC-Link IE TSN interface board, Motion module, Motion Control Board, Block-type remote module, Block-type remote module with safety functions, Analog-Digital converter module, Digital-Analog converter module, CC-Link IE TSN compatible coupler, FPGA module, Tension meter, AC Servo MELSERVO-J5, AC Servo MELSERVO-JET, Liner Track System MTR-S series Linear track control module, Inverter FR-A800/F800/E800 Series, Industrial Robot CR800-D series controller Network Base Card, CC-Link IE TSN expansion unit, CC-Link IE TSN-CC-Link IE Field Network bridge module, CC-Link IE TSN-AnyWireASLINK bridge module, Energy Measuring Unit CC-Link IE TSN Communication Unit, Industrial Computer MELIPC series, GOT3000 Series, CC-Link IE TSN Communication Unit, Motion Control Software, CC-Link IE TSN Communication Software for Windows, Analysis Support Software MELSOFT VIMA, Master/Local module Designated communication LSI DeviceKit, Master/Local module Designated communication LSI, Remote Station Communication LSI with GbE-PHY, CC-Link IE TSN Master/Local module Designated communication LSI SDK, and Remote station software development kit allows an attacker with access to a CC-Link IE TSN network to tamper with communication data (control input/output values) by sending specially crafted packets under specific timing conditions. This could allow the attacker to cause a denial-of-service (DoS) condition in the affected product by interfering with its control function or causing it to operate incorrectly.

Kyuubi Engine UI proxy accepts a host and port from the request path and proxies HTTP requests to that destination. A remote requester with network access to the proxy can cause the Kyuubi server to send HTTP requests to arbitrary reachable hosts, resulting in SSRF or open-proxy behavior. This issue affects Apache Kyuubi: from 1.8.0 before 1.12.0. Users are recommended to upgrade to version 1.12.0, which disables the proxy by default. To restore proxied Engine UI, set kyuubi.frontend.rest.engine.ui.proxy.enabled=true and configure allowed target hosts with kyuubi.frontend.rest.engine.ui.proxy.hosts.

apache

Sparkle is a software update framework for macOS. Prior to version 2.9.2, `Autoupdate/SUBinaryDeltaApply.m` enforces `relativePath.pathComponents containsObject:@".."` and rejects writes whose immediate parent directory IS itself a symbolic link, but does not detect symlinks deeper in the relative path. `Autoupdate/SPUSparkleDeltaArchive.m`'s `extractItem:` will create symlinks in the destination tree from archive content (no `..` check on the symlink target), and a subsequent `Extract` item targeting `<symlink>/foo/bar` then escapes the destination tree via `fopen(path, "wb")` because the kernel resolves the intermediate symlink during the open call. This is a defense-in-depth issue: exploitation requires a maliciously-crafted `.delta` that passes EdDSA signature verification, i.e. EdDSA private-key compromise. With the AppInstaller running as root for system-domain installs, it gives the holder of a stolen signing key arbitrary file write at root level via the delta-apply path, which is a strictly broader primitive than the "drop-in replacement bundle" install they would otherwise have. Version 2.9.2 contains a patch for the issue.

sparkle-project

In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: add skb_cow_data() before in-place crypto llsec_do_encrypt_unauth(), llsec_do_encrypt_auth(), llsec_do_decrypt_unauth(), and llsec_do_decrypt_auth() all perform in-place cryptographic transformations on skb data. They build a scatterlist with sg_init_one() pointing into the skb's linear data area and then pass the same scatterlist as both src and dst to the crypto API (e.g. crypto_skcipher_encrypt/decrypt, crypto_aead_encrypt/decrypt). On the RX path, __ieee802154_rx_handle_packet() clones the received skb before handing it to each subscriber via ieee802154_subif_frame(). The cloned skb shares the same underlying data buffer via reference counting. When llsec_do_decrypt() subsequently modifies this shared buffer in place, it corrupts data that other clones -- potentially belonging to other sockets or subsystems -- still reference. On the TX path, similar data sharing can occur when an skb's head has been cloned (skb_cloned() returns true). The fix is to call skb_cow_data() before performing any in-place crypto operation. skb_cow_data() ensures that the skb's data area is not shared: if the skb head is cloned or the data spans multiple fragments, it copies the data into a private buffer that can be safely modified in place. This is the same pattern used by: - ESP (net/ipv4/esp4.c, net/ipv6/esp6.c) - MACsec (drivers/net/macsec.c) - WireGuard (drivers/net/wireguard/receive.c) - TIPC (net/tipc/crypto.c) Without this guard, in-place crypto on shared skb data leads to: - Silent data corruption of other skb clones - Use-after-free when the crypto API scatterwalk writes through a page that has already been freed by another clone's kfree_skb() - Kernel crashes under concurrent 802.15.4 traffic with security enabled (KASAN/KMSAN reports slab-use-after-free) Found by 0sec (https://0sec.ai) using automated source analysis.

In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level When recovering hugepages in the shadow MMU, verify that the base gfn of the shadow page is actually contained within the target memslot, *before* querying the max mapping level given the shadow page's gfn. Failure to pre-check the validity of the gfn can lead to an out-of-bounds access to the slot's lpage_info (which typically manifests as a host #PF because the lpage_info is vmalloc'd) if the guest creates a hugepage mapping (in its PTEs) that extends "below" the bounds of a memslot. When faulting in memory for a guest, and the size of the guest mapping is greater than KVM's (current) max mapping, then KVM will create a "direct" shadow page (direct in that there are no gPTEs to shadow, and so the target gfn is a direct calculation given the base gfn of the shadow page). The hugepage recovery flow looks for such direct shadow pages, as forcing 4KiB mappings when dirty logging generates the guest > host mapping size case. When the 4KiB restriction is lifted, then KVM can replace the shadow page with a hugepage. But if KVM originally used a smaller mapping than the guest because the range of memory covered by the guest hugepage exceeds the bounds of a memslot, then KVM will link a direct shadow page with a gfn that is outside the bounds of the memslot being used to fault in memory. The rmap entry added for the leaf mapping is correct and within bounds, but the gfn of the leaf SPTE's parent shadow page will be out of bounds. BUG: unable to handle page fault for address: ffffc90000806ffc #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 1002a7067 PMD 10612f067 PTE 0 Oops: Oops: 0000 [#1] SMP CPU: 13 UID: 1000 PID: 757 Comm: mmu_stress_test Not tainted 7.1.0-rc1-48ce1e26eace-x86_pir_to_irr_comments-vm #341 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kvm_mmu_max_mapping_level+0x79/0x2b0 [kvm] Call Trace: <TASK> kvm_mmu_recover_huge_pages+0x21b/0x320 [kvm] kvm_set_memslot+0x1ee/0x590 [kvm] kvm_set_memory_region.part.0+0x3a1/0x4d0 [kvm] kvm_vm_ioctl+0x9bf/0x15d0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0xbb0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f21c0f1a9bf </TASK> Don't bother pre-checking the bounds of the potential hugepage, i.e. don't check that e.g. sp->gfn + KVM_PAGES_PER_HPAGE(sp->role.level + 1) is also within the memslot, as the checks performed by kvm_mmu_max_mapping_level() are a superset of the basic bounds checks. I.e. pre-checking the full range would be a dubious micro-optimization.

linux

ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 6.9.13-49 and 7.1.2-24, an infinite loop in the subimage-search operation can happen when using a crafted image. This issue has been patched in versions 6.9.13-49 and 7.1.2-24.

imagemagick

free5GC is an open-source implementation of the 5G core network. Prior to 4.2.2, free5GC's NEF mounts the nnef-pfdmanagement route group without inbound OAuth2/bearer-token authorization. A network attacker who can reach NEF on the SBI can use a forged or arbitrary bearer token (e.g. Authorization: Bearer not-a-real-token) to read PFD application data via GET /applications and GET /applications/{appID}, and to create or delete PFD change-notification subscriptions via POST /subscriptions and DELETE /subscriptions/{subID}. Same root cause as the other NEF SBI findings: the route group is mounted without any inbound auth middleware. Unlike the OAM and traffic-influence groups, nnef-pfdmanagement IS declared in the runtime ServiceList, so this is the production-intended path that operators expect to be protected by OAuth2 setting receive from NRF: true -- and it is not. This vulnerability is fixed in 4.2.2.

free5gc

free5GC is an open-source implementation of the 5G core network. Prior to 4.2.2, free5GC's BSF PUT /nbsf-management/v1/subscriptions/{subId} handler has an unsynchronized write on the global Subscriptions map. The handler first reads the map under RLock() via BSFContext.GetSubscription(subId), but if the subscription does not exist, ReplaceIndividualSubcription() writes back to the same map directly without taking the mutex (bsfContext.BsfSelf.Subscriptions[subId] = subscription). Under concurrent authenticated PUT load, one goroutine can read while another writes the map, which causes the Go runtime to abort the process with fatal error: concurrent map read and map write (Go runtime panics that come from concurrent map access bypass recover() and terminate the process). The BSF container exits with code 2 -- the entire BSF SBI surface goes down until restart. This vulnerability is fixed in 4.2.2.

free5gc

NanoMQ MQTT Broker (NanoMQ) is an all-around Edge Messaging Platform. In versions 0.24.10 and below, when NanoMQ handles high-concurrency reconnect traffic using a reconnect-collision payload, the broker can crash due to a NULL pointer dereference during MQTT session resumption for clean_start=0 clients. The transport's p_peer callback (tcptran_pipe_peer()) iterates cpipe->subinfol while copying session metadata from the cached old pipe to the new reconnecting pipe, without checking whether the pointer is NULL. Under a reconnect race, cpipe->subinfol can be freed and set to NULL before session restore invokes this function, resulting in a remote unauthenticated Denial-of-Service (process crash) condition. This issue has been fixed in version 0.24.11.

OpenImageIO is a toolset for reading, writing, and manipulating image files of any image file format relevant to VFX / animation. Prior to 3.0.18.0 and 3.1.13.0, a heap-based buffer overflow in the HEIF decoder of OpenImageIO allows out-of-bounds writes via crafted images due to a subimage metadata mismatch, leading to memory corruption and potential code execution. This vulnerability is fixed in 3.0.18.0 and 3.1.13.0.

openimageio

Yubico webauthn-server-core (aka java-webauthn-server) 2.8.0 before 2.8.2 incorrectly checks a function's return value in the second factor flow, leading to impersonation.

uBidAuction 2.0.1 contains a reflected cross-site scripting vulnerability in the backend/mailingLog/manage module. The date_created, date_from, date_to, and created_at parameters in the filter functionality are not properly sanitized, allowing remote attackers to inject malicious scripts via crafted GET requests that execute in victims' browsers.

uBidAuction 2.0.1 contains a reflected cross-site scripting vulnerability in the auctions/manage module. The date_created, date_from, date_to, and created_at parameters in the filter functionality are not properly sanitized, allowing remote attackers to inject malicious scripts via crafted GET requests that execute in victims' browsers.

uBidAuction 2.0.1 contains a reflected cross-site scripting vulnerability in the tickets/manage module. The date_created, date_from, date_to, and created_at parameters in the filter functionality are not properly sanitized, allowing remote attackers to inject malicious scripts via crafted GET requests that execute in victims' browsers.

uBidAuction 2.0.1 contains a reflected cross-site scripting vulnerability in the posts/manage module. The date_created, date_from, date_to, and created_at parameters in the filter functionality are not properly sanitized, allowing remote attackers to inject malicious scripts via crafted GET requests that execute in victims' browsers.

uBidAuction 2.0.1 contains a reflected cross-site scripting vulnerability in the auctions/myAuctions/status/loose module. The date_created, date_from, date_to, and created_at parameters in the filter functionality are not properly sanitized, allowing remote attackers to inject malicious scripts via crafted GET requests that execute in victims' browsers.

uBidAuction 2.0.1 contains a reflected cross-site scripting vulnerability in the auctions/myAuctions/status/active module. The date_created, date_from, date_to, and created_at parameters in the filter functionality are not properly sanitized, allowing remote attackers to inject malicious scripts via crafted GET requests that execute in victims' browsers.

uBidAuction 2.0.1 contains a reflected cross-site scripting vulnerability in the orders/myOrders module. The date_created, date_from, date_to, and created_at parameters in the filter functionality are not properly sanitized, allowing remote attackers to inject malicious scripts via crafted GET requests that execute in victims' browsers.

uBidAuction 2.0.1 contains a reflected cross-site scripting vulnerability in the news/manage module. The date_created, date_from, date_to, and created_at parameters in the filter functionality are not properly sanitized, allowing remote attackers to inject malicious scripts via crafted GET requests that execute in victims' browsers.

Origin Validation Error vulnerability in TUBITAK BILGEM Software Technologies Research Institute Liderahenk allows Accessing Functionality Not Properly Constrained by ACLs. This issue affects Liderahenk: from 2.0.1 before 2.0.2.

Improper neutralization of special elements used in an OS command ('OS command injection') vulnerability in TUBITAK BILGEM Software Technologies Research Institute Pardus OS My Computer allows OS Command Injection. This issue affects Pardus OS My Computer: from <=0.7.5 before 0.8.0.

Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in TUBITAK BILGEM Software Technologies Research Institute Pardus Software Center allows Path Traversal. This issue affects Pardus Software Center: before 0.6.4.