https://cve.circl.lu/rss/recent/github/10Most recent entries from github2024-12-11T22:19:36.048272+00:00Vulnerability Lookupinfo@circl.lupython-feedgenContains only the most 10 recent entries.https://cve.circl.lu/vuln/ghsa-vr58-5gj9-563mghsa-vr58-5gj9-563m2024-12-11T22:19:36.058585+00:00In 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-7mwxghsa-w78w-44c5-7mwx2024-12-11T22:19:36.058565+00:00In 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-fc48ghsa-x34g-xjxv-fc482024-12-11T22:19:36.058515+00:00In 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-x8hpghsa-h63v-hw6g-x8hp2024-12-11T22:19:36.058495+00:00due 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-g8fjghsa-753p-wrj5-g8fj2024-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-39hmghsa-43h9-p3j4-39hm2024-12-11T22:19:36.058423+00:00The 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-cxhhghsa-vvpf-53qx-cxhh2024-12-11T22:19:36.058403+00:00In 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-prxmghsa-pqj8-xhcx-prxm2024-12-11T22:19:36.058374+00:00binux 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-29vmghsa-43mq-6xmg-29vm2024-12-11T22:19:36.058320+00:00File 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-067https://cve.circl.lu/vuln/ghsa-v778-237x-gjrcghsa-v778-237x-gjrc2024-12-11T22:19:36.058257+00:00Applications 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.