https://cve.circl.lu/rss/recent/github/10 Most recent entries from github 2024-12-11T22:19:36.048272+00:00 Vulnerability Lookup info@circl.lu python-feedgen Contains only the most 10 recent entries. https://cve.circl.lu/vuln/ghsa-vr58-5gj9-563m ghsa-vr58-5gj9-563m 2024-12-11T22:19:36.058585+00:00 In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix handling of partial GPU mapping of BOs This commit fixes the bug in the handling of partial mapping of the buffer objects to the GPU, which caused kernel warnings. Panthor didn't correctly handle the case where the partial mapping spanned multiple scatterlists and the mapping offset didn't point to the 1st page of starting scatterlist. The offset variable was not cleared after reaching the starting scatterlist. Following warning messages were seen. WARNING: CPU: 1 PID: 650 at drivers/iommu/io-pgtable-arm.c:659 __arm_lpae_unmap+0x254/0x5a0 <snip> pc : __arm_lpae_unmap+0x254/0x5a0 lr : __arm_lpae_unmap+0x2cc/0x5a0 <snip> Call trace: __arm_lpae_unmap+0x254/0x5a0 __arm_lpae_unmap+0x108/0x5a0 __arm_lpae_unmap+0x108/0x5a0 __arm_lpae_unmap+0x108/0x5a0 arm_lpae_unmap_pages+0x80/0xa0 panthor_vm_unmap_pages+0xac/0x1c8 [panthor] panthor_gpuva_sm_step_unmap+0x4c/0xc8 [panthor] op_unmap_cb.isra.23.constprop.30+0x54/0x80 __drm_gpuvm_sm_unmap+0x184/0x1c8 drm_gpuvm_sm_unmap+0x40/0x60 panthor_vm_exec_op+0xa8/0x120 [panthor] panthor_vm_bind_exec_sync_op+0xc4/0xe8 [panthor] panthor_ioctl_vm_bind+0x10c/0x170 [panthor] drm_ioctl_kernel+0xbc/0x138 drm_ioctl+0x210/0x4b0 __arm64_sys_ioctl+0xb0/0xf8 invoke_syscall+0x4c/0x110 el0_svc_common.constprop.1+0x98/0xf8 do_el0_svc+0x24/0x38 el0_svc+0x34/0xc8 el0t_64_sync_handler+0xa0/0xc8 el0t_64_sync+0x174/0x178 <snip> panthor : [drm] drm_WARN_ON(unmapped_sz != pgsize * pgcount) WARNING: CPU: 1 PID: 650 at drivers/gpu/drm/panthor/panthor_mmu.c:922 panthor_vm_unmap_pages+0x124/0x1c8 [panthor] <snip> pc : panthor_vm_unmap_pages+0x124/0x1c8 [panthor] lr : panthor_vm_unmap_pages+0x124/0x1c8 [panthor] <snip> panthor : [drm] *ERROR* failed to unmap range ffffa388f000-ffffa3890000 (requested range ffffa388c000-ffffa3890000) https://cve.circl.lu/vuln/ghsa-w78w-44c5-7mwx ghsa-w78w-44c5-7mwx 2024-12-11T22:19:36.058565+00:00 In the Linux kernel, the following vulnerability has been resolved: vp_vdpa: fix id_table array not null terminated error Allocate one extra virtio_device_id as null terminator, otherwise vdpa_mgmtdev_get_classes() may iterate multiple times and visit undefined memory. https://cve.circl.lu/vuln/ghsa-x34g-xjxv-fc48 ghsa-x34g-xjxv-fc48 2024-12-11T22:19:36.058515+00:00 In the Linux kernel, the following vulnerability has been resolved: mptcp: cope racing subflow creation in mptcp_rcv_space_adjust Additional active subflows - i.e. created by the in kernel path manager - are included into the subflow list before starting the 3whs. A racing recvmsg() spooling data received on an already established subflow would unconditionally call tcp_cleanup_rbuf() on all the current subflows, potentially hitting a divide by zero error on the newly created ones. Explicitly check that the subflow is in a suitable state before invoking tcp_cleanup_rbuf(). https://cve.circl.lu/vuln/ghsa-h63v-hw6g-x8hp ghsa-h63v-hw6g-x8hp 2024-12-11T22:19:36.058495+00:00 due to a weakness in the encryption method used in cookie-encrypter an attack can use the world visible IV to edit encrypted cookies without decrypting the cookie itself. This is known as an AES CBC bit flipping attack. https://cve.circl.lu/vuln/ghsa-753p-wrj5-g8fj ghsa-753p-wrj5-g8fj 2024-12-11T22:19:36.058473+00:00 ### Impact A correctness error has been identified in the reference implementation of the HQC key encapsulation mechanism. Due to an indexing error, part of the secret key is incorrectly treated as non-secret data. This results in an incorrect shared secret value being returned when the decapsulation function is called with a malformed ciphertext. No concrete attack exploiting the error has been identified at this point. However, the error involves mishandling of the secret key, and in principle this presents a security vulnerability. ### Patches PQClean does not have a release process, as it is a collection of implementations. If you obtained a HQC implementation from PQClean, please update to a version that includes the fixes proposed in https://github.com/PQClean/PQClean/pull/578. Please also [refer to our security policy](https://github.com/PQClean/PQClean/blob/master/SECURITY.md). ### Workarounds Manually patching is always possible ### Further details In the 2023/04/30 version of the HQC specification and reference implementation, an extra field (sigma) was added to the secret key structure to enable implicit rejection of malformed ciphertexts. The logic to retrieve the public key from the secret key in the decapsulation function was not updated accordingly. As a result, sigma is treated as part of the public key. Later in the decapsulation call, a incorrectly constructed comparison check allows this error to go through undetected. Due to how these two bugs interfere with each other, the decapsulation function never uses sigma to perform implicit rejection; instead, it accepts malformed ciphertexts and returns shared secrets based on their decryptions. ### References This issue was first reported in OQS https://github.com/open-quantum-safe/liboqs/security/advisories/GHSA-gpf4-vrrw-r8v7. The vulnerability was identified by Célian Glénaz and Dahmun Goudarzi (Quarkslab). https://cve.circl.lu/vuln/ghsa-43h9-p3j4-39hm ghsa-43h9-p3j4-39hm 2024-12-11T22:19:36.058423+00:00 The default password hashing algorithm (PBKDF2-HMAC-SHA1) in Liferay Portal 7.2.0 through 7.4.3.15, and older unsupported versions, and Liferay DXP 7.4 before update 16, 7.3 before update 4, 7.2 before fix pack 17, and older unsupported versions defaults to a low work factor, which allows attackers to quickly crack password hashes. https://cve.circl.lu/vuln/ghsa-vvpf-53qx-cxhh ghsa-vvpf-53qx-cxhh 2024-12-11T22:19:36.058403+00:00 In Liferay Portal 7.2.0 through 7.4.3.12, and older unsupported versions, and Liferay DXP 7.4 before update 9, 7.3 before update 4, 7.2 before fix pack 19, and older unsupported versions, the default configuration does not sanitize blog entries of JavaScript, which allows remote authenticated users to inject arbitrary web script or HTML (XSS) via a crafted payload injected into a blog entry’s content text field. https://cve.circl.lu/vuln/ghsa-pqj8-xhcx-prxm ghsa-pqj8-xhcx-prxm 2024-12-11T22:19:36.058374+00:00 binux pyspider up to v0.3.10 was discovered to contain a Cross-Site Request Forgery (CSRF) via the Flask endpoints. https://cve.circl.lu/vuln/ghsa-43mq-6xmg-29vm ghsa-43mq-6xmg-29vm 2024-12-11T22:19:36.058320+00:00 File upload logic is flawed vulnerability in Apache Struts. This issue affects Apache Struts: from 2.0.0 before 6.4.0. Users are recommended to upgrade to version 6.4.0, which fixes the issue. You can find more details in  https://cwiki.apache.org/confluence/display/WW/S2-067 https://cve.circl.lu/vuln/ghsa-v778-237x-gjrc ghsa-v778-237x-gjrc 2024-12-11T22:19:36.058257+00:00 Applications and libraries which misuse the ServerConfig.PublicKeyCallback callback may be susceptible to an authorization bypass. The documentation for ServerConfig.PublicKeyCallback says that "A call to this function does not guarantee that the key offered is in fact used to authenticate." Specifically, the SSH protocol allows clients to inquire about whether a public key is acceptable before proving control of the corresponding private key. PublicKeyCallback may be called with multiple keys, and the order in which the keys were provided cannot be used to infer which key the client successfully authenticated with, if any. Some applications, which store the key(s) passed to PublicKeyCallback (or derived information) and make security relevant determinations based on it once the connection is established, may make incorrect assumptions. For example, an attacker may send public keys A and B, and then authenticate with A. PublicKeyCallback would be called only twice, first with A and then with B. A vulnerable application may then make authorization decisions based on key B for which the attacker does not actually control the private key. Since this API is widely misused, as a partial mitigation golang.org/x/cry...@v0.31.0 enforces the property that, when successfully authenticating via public key, the last key passed to ServerConfig.PublicKeyCallback will be the key used to authenticate the connection. PublicKeyCallback will now be called multiple times with the same key, if necessary. Note that the client may still not control the last key passed to PublicKeyCallback if the connection is then authenticated with a different method, such as PasswordCallback, KeyboardInteractiveCallback, or NoClientAuth. Users should be using the Extensions field of the Permissions return value from the various authentication callbacks to record data associated with the authentication attempt instead of referencing external state. Once the connection is established the state corresponding to the successful authentication attempt can be retrieved via the ServerConn.Permissions field. Note that some third-party libraries misuse the Permissions type by sharing it across authentication attempts; users of third-party libraries should refer to the relevant projects for guidance.