In the Linux kernel, the following vulnerability has been resolved: keys: Check the authorization payload in process keyring searches An authorization payload and its saved credentials must remain valid while search_process_keyrings_rcu() searches the requestor's keyrings. The function validates the authorization key, then separately loads payload.data[0] and unconditionally reads rka->cred. Validation does not prevent request_key_auth_revoke() from clearing the payload. A request-key helper can assume authority and fork a descendant that inherits the authorization key. If the descendant misses in its own keyrings, it falls back to the saved requestor credentials. Successful target instantiation invalidates the authorization key without clearing the payload. After the helper exits, UMH_WAIT_PROC returns to the requester, which calls complete_request_key() and revokes that key. With the descendant paused after validation, the paths can interleave as follows: 1. The descendant enters search_process_keyrings_rcu() under RCU and key_validate() succeeds. 2. The helper instantiates the target, invalidates the authorization key, and exits. 3. The requester resumes from UMH_WAIT_PROC, calls complete_request_key(), and revokes the authorization key. request_key_auth_revoke() sets its payload pointer to NULL. 4. The descendant loads NULL and dereferences rka->cred. This NULL dereference can oops the kernel. RCU delays payload disposal but does not prevent the pointer from being cleared. Load the payload with dereference_key_rcu() and require a non-NULL result before validating the authorization key and searching its saved credentials. A non-NULL payload and its credentials remain alive for the caller's RCU read-side section; a cleared payload skips the fallback search and follows the existing error selection. KASAN report as below: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] RIP: 0010:search_process_keyrings_rcu+0x32b/0x790
In the Linux kernel, the following vulnerability has been resolved: keys: make keyring indexes independent of kernel addresses KEYCTL_READ returns the serial numbers in a keyring in associative-array traversal order. The first word of the index is a public, deterministic hash of the type pointer, domain pointer and description. An unprivileged user can therefore insert keys with known descriptions, predict their order for each possible KASLR slide, and recover the kernel image address. On an x86-64 build with 16 MiB alignment, 45 user keys suffice to distinguish the candidate slides. Remove the addresses from the whole index, not just its first hash word. Assign each key type and domain a nonzero 64-bit ID and hash those IDs and the description with a once-initialized SipHash key. Use the full IDs in the later index chunks as well. Truncating or hashing the IDs there would lose the guarantee that distinct type/domain/description tuples have a differing index bit. Allocate IDs lazily since private key types need not be registered. Cache them in the index key so tree walks and copies of an existing index do not need to dereference a type descriptor that may have been unregistered. Keep the 32-bit chunk layout and diff_objects() bit offsets consistent, and retain the separate root slot for keyrings used by recursive search. The key comparison, permissions and userspace data format are unchanged; only the address-dependent in-memory ordering is replaced.
In the Linux kernel, the following vulnerability has been resolved: keys: Protect the read method check against type removal keyctl_read_key() checks key->type->read without holding key->sem. A reference keeps the key alive, but does not pin the module containing its type. A surviving RxRPC key can therefore be read while AF_RXRPC is being unloaded: KEYCTL_READ task Module unload and key GC ---------------- ------------------------ lookup_user_key() permission / possession checks load key->type af_rxrpc_exit() unregister_key_type() GC: down_write(key->sem) GC: retype to key_type_dead GC: up_write(key->sem) unregister_key_type() returns free_module() read saved type's read member The final access can read freed module storage. The read invocation in __keyctl_read_key() is already protected by key->sem, but the earlier method check is outside that critical section. Move the method check into __keyctl_read_key(), after key_validate() and under its existing read hold on key->sem. The check and invocation then use the same protected type for length queries and every read retry. The GC cannot retype the key until the semaphore is released, and type unregistration waits for that GC pass before the module can be freed. Return -EOPNOTSUPP when validation succeeds and the type has no read method. A temporary buffer may now be allocated before this result; allocation and copying to userspace remain outside the semaphore.
In the Linux kernel, the following vulnerability has been resolved: keys/trusted_keys: return immediately after TPM unseal failure trusted_tpm_unseal() proceeds to pcrlock() when the TPM unseal operation fails. If pcrlock() succeeds, its return value overwrites the unseal error, causing key instantiation to succeed. Return immediately when unseal fails to preserve the original error.
In the Linux kernel, the following vulnerability has been resolved: asymmetric_keys: reject trust keys without IDs The PKCS#8 parser deliberately leaves the asym_key_ids payload slot empty. key_or_keyring_common() unconditionally dereferences that slot when a PKCS#8 key is supplied to a key_or_keyring restriction. Both the plain and :chain forms reach this branch, allowing an unprivileged caller to trigger a NULL pointer dereference through KEYCTL_RESTRICT_KEYRING followed by add_key(). Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000 KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:key_or_keyring_common (crypto/asymmetric_keys/restrict.c:205 crypto/asymmetric_keys/restrict.c:279) Call Trace: <TASK> __key_create_or_update (security/keys/key.c:884) key_create_or_update (security/keys/key.c:1021) __do_sys_add_key (security/keys/keyctl.c:134) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) </TASK> Kernel panic - not syncing: Fatal exception Reject an asymmetric restriction key without key IDs. A PKCS#8 private key cannot identify the signer of a candidate certificate and is not a valid trust anchor.
In the Linux kernel, the following vulnerability has been resolved: ftrace: Initialize modname and offset in print_rec() print_rec() leaves 'modname' and 'offset' uninitialized and kallsyms_lookup() only sets them on success. When the lookup fails like when a module is being loaded or unloaded, 'modname' holds a garbage value, passes the 'if (modname)' check, and is dereferenced by seq_printf(). Oops: general protection fault RIP: 0010:string+0x48/0xe0 Call Trace: vsnprintf+0x1f5/0x650 seq_printf+0x8e/0xb0 print_rec+0x6c/0xc0 t_show+0x4c/0x440 seq_read_iter+0x119/0x480 This can be triggered by reading available_filter_functions while a module is being loaded or unloaded. Initialize both variables so a failed lookup skips the module name.
Out-of-bounds read in Apache Arrow Rust (`arrow` crate) versions 33.0.0 through 57.3.1, 58.4.0, 59.3.1, and 60.0.0 can expose memory contents beyond a RunEndEncoded child values array when malformed run-end values are accepted through the ArrayData interface. The independent assessment assigns CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N, making this remote and unauthenticated, but practical exposure is limited to applications that pass untrusted or malformed RunEndEncoded data into that interface; applications processing only trusted, internally generated Arrow data are not realistically exposed. No public exploit has been identified at time of analysis, and the vendor recommends upgrading to 60.1.0, 59.3.2, 58.4.1, or 57.3.2.
SQL injection in Apache Syncope 3.0.0-M0 through 3.0.16, 4.0.0-M0 through 4.0.8, and 4.1.0-M0 through 4.1.3 lets an authenticated administrator holding adequate entitlements pass unsanitized opEvent parameters into SQL statements and, where the backing database permits stacked queries, execute arbitrary SQL. It is an incomplete fix for CVE-2026-77051, so installations remediated only against that earlier CVE remain exposed. The vendor directs users to upgrade to 4.0.9 or 4.1.4; no public exploit code or confirmed active exploitation was identified at time of analysis, and the high-privilege administrator prerequisite is the main constraint on realistic abuse.
Apache Syncope administrators who hold entitlements for the Implementations feature can define a malicious Groovy class that executes untrusted code on a separate thread, escaping the Groovy security sandbox and compromising the application's confidentiality, integrity, and availability. The flaw affects Syncope 3.0.0-M0 through 3.0.16, 4.0.0-M0 through 4.0.8, and 4.1.0-M0 through 4.1.3; exploitation requires a high-privilege administrative account, so exposure is limited to deployments where Implementations access is broadly delegated. No public exploit identified at time of analysis, and the vendor directs users to upgrade to 4.0.9 or 4.1.4.
Authorization bypass in Apache Syncope allows an authenticated delegated administrator to relocate a Realm subtree across administrative realm boundaries without holding permission on the destination realm, giving the attacker unwarranted write influence over resources outside their delegated scope (integrity impact) with limited read exposure. Affected releases are 3.0.0-M0 through 3.0.16, 4.0.0-M0 through 4.0.8, and 4.1.0-M0 through 4.1.3, and the vendor recommends upgrading to 4.0.9 or 4.1.4. Exploitation requires a valid delegated-admin account in Syncope - there is no unauthenticated path - and no public exploit code or active exploitation has been identified at time of analysis.
Improper privilege management in Apache Syncope 3.0.12 through 3.0.16, 4.0.0-M0 through 4.0.8 and 4.1.0-M0 through 4.1.3 allows an authenticated non-admin account that is permitted to perform AuthProfile self-updates to configure impersonation used by WA (Web Access) surrogate authentication, effectively letting a low-privileged user act as another identity. Our assessment scores this CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N - network-reachable, authenticated (PR:L), no user interaction, with high confidentiality and integrity impact and no availability impact - because the flaw grants an authorization bypass rather than code execution. Exploitation requires a valid low-privilege account plus a deployment that actually uses WA surrogate authentication; no public exploit code has been identified at time of analysis and the issue is not in CISA KEV, so priority is scheduled patching (this_week) rather than emergency response.
An authenticated Apache Syncope administrator who holds entitlements to manage workflow definitions can import a BPMN process containing a JUEL expression attribute through the REST API and then start that process, causing the expression to be evaluated server-side with no sandbox and resulting in arbitrary code execution in the Syncope server context (assessed CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H). The flaw is an improper isolation or compartmentalization weakness (CWE-653) affecting Syncope 3.0.0-M0 through 3.0.16, 4.0.0-M0 through 4.0.8, and 4.1.0 through 4.1.3; because the vector requires high privileges (PR:H), exposure concentrates in deployments where workflow-management entitlements are broadly delegated. No public exploit code and no confirmed active exploitation were identified at time of analysis, and fixes are available in 4.0.9 and 4.1.4.
A resource exhaustion issue exists in Free5GC v4.2.3 during PFCP Session Establishment failure handling. When the SMF does not receive a PFCP Session Establishment Response from the UPF, allocated UE IP address resources are not properly released. Repeated failed session establishment attempts can therefore exhaust the UE IP address pool, preventing new UEs from establishing PDU sessions and resulting in denial of service.
Keyfactor EJBCA through 9.3.3 performs insufficient authorization checks when self-renewing a client certificate via the RA (Registration Authority) User Interface. This allows a remote user, authenticated with a valid client certificate, to renew their certificate even if the end entity status and/or profile settings should deny renewal. The attacker must have a valid TLS client certificate, and must be authorized to use the RA User Interface, either with the certificate, or via a role membership for PublicAccessAuthenticationToken.
A memory exhaustion issue exists in Open5GS v2.8.0 in the HTTP/2 SBI server. Repeated header names cause previously allocated header strings to be leaked, and HPACK compression allows an unauthenticated remote attacker to trigger tens of thousands of duplicate headers with a small request. Repeated crafted requests can cause persistent heap growth, exhaust process memory, and terminate the affected Open5GS network function, resulting in denial of service.
An authentication bypass vulnerability in the Universal Plug and Play (UPnP) framework of the Sercomm AOT-4221SR 4.6 Dual Band GPON ONU device allows an attackers to execute arbitrary SOAP requests via port 5555. This flaw exposes 15 administrative, WAN, LAN, and firewall services without requiring credentials, enabling attackers to modify core routing tables, alter DNS servers, remove firewall rules, and completely compromise the network.
An integer underflow vulnerability in the NAS decoder of OpenAirInterface (OAI) CN5G AMF v2.2.1 allows an unauthenticated remote attacker to cause a denial of service (DoS) via crafted NAS Registration Requests containing a truncated SUCI in the 5GS Mobile Identity IE. Insufficient length validation in the DecodeSuci() function results in an out-of-bounds heap read, causing the AMF process to crash.
Directory Traversal vulnerability in Gleez GleezCMS v.1.2.0 allows a remote attacker to obtain sensitive information via the action_serve function in media.php
An out-of-bounds memory access vulnerability in the N2 SCTP interface of OpenAirInterface (OAI) CN5G AMF v2.2.1 allows an unauthenticated remote attacker to cause a denial of service (DoS) by repeatedly establishing SCTP associations, resulting in a process crash due to improper file descriptor bounds checking in the FD_SET() operation.
A denial-of-service vulnerability exists in open5GS v2.8.0 in the PFCP transaction handling path. When the PFCP transaction or timer resource pool is exhausted, ogs_pfcp_xact_remote_create() returns NULL, but the failure is not handled properly and leads to an ogs_assert(new) failure in ogs_pfcp_xact_receive(). An attacker able to send PFCP messages to the affected SMF/UPF can exhaust transaction resources and cause the network function process to terminate with SIGABRT, resulting in service disruption and preventing further session establishment until the affected component is restarted.