| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
erofs: fix crafted invalid cases for encoded extents
Robert recently reported two corrupted images that can cause system
crashes, which are related to the new encoded extents introduced
in Linux 6.15:
- The first one [1] has plen != 0 (e.g. plen == 0x2000000) but
(plen & Z_EROFS_EXTENT_PLEN_MASK) == 0. It is used to represent
special extents such as sparse extents (!EROFS_MAP_MAPPED), but
previously only plen == 0 was handled;
- The second one [2] has pa 0xffffffffffdcffed and plen 0xb4000,
then "cur [0xfffffffffffff000] += bvec.bv_len [0x1000]" in
"} while ((cur += bvec.bv_len) < end);" wraps around, causing an
out-of-bound access of pcl->compressed_bvecs[] in
z_erofs_submit_queue(). EROFS only supports 48-bit physical block
addresses (up to 1EiB for 4k blocks), so add a sanity check to
enforce this. |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: directly free partially initialized fs_info in btrfs_check_leaked_roots()
If fs_info->super_copy or fs_info->super_for_commit allocated failed in
btrfs_get_tree_subvol(), then no need to call btrfs_free_fs_info().
Otherwise btrfs_check_leaked_roots() would access NULL pointer because
fs_info->allocated_roots had not been initialised.
syzkaller reported the following information:
------------[ cut here ]------------
BUG: unable to handle page fault for address: fffffffffffffbb0
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 64c9067 P4D 64c9067 PUD 64cb067 PMD 0
Oops: Oops: 0000 [#1] SMP KASAN PTI
CPU: 0 UID: 0 PID: 1402 Comm: syz.1.35 Not tainted 6.15.8 #4 PREEMPT(lazy)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), (...)
RIP: 0010:arch_atomic_read arch/x86/include/asm/atomic.h:23 [inline]
RIP: 0010:raw_atomic_read include/linux/atomic/atomic-arch-fallback.h:457 [inline]
RIP: 0010:atomic_read include/linux/atomic/atomic-instrumented.h:33 [inline]
RIP: 0010:refcount_read include/linux/refcount.h:170 [inline]
RIP: 0010:btrfs_check_leaked_roots+0x18f/0x2c0 fs/btrfs/disk-io.c:1230
[...]
Call Trace:
<TASK>
btrfs_free_fs_info+0x310/0x410 fs/btrfs/disk-io.c:1280
btrfs_get_tree_subvol+0x592/0x6b0 fs/btrfs/super.c:2029
btrfs_get_tree+0x63/0x80 fs/btrfs/super.c:2097
vfs_get_tree+0x98/0x320 fs/super.c:1759
do_new_mount+0x357/0x660 fs/namespace.c:3899
path_mount+0x716/0x19c0 fs/namespace.c:4226
do_mount fs/namespace.c:4239 [inline]
__do_sys_mount fs/namespace.c:4450 [inline]
__se_sys_mount fs/namespace.c:4427 [inline]
__x64_sys_mount+0x28c/0x310 fs/namespace.c:4427
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x92/0x180 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x7f032eaffa8d
[...] |
| In the Linux kernel, the following vulnerability has been resolved:
mptcp: fix race condition in mptcp_schedule_work()
syzbot reported use-after-free in mptcp_schedule_work() [1]
Issue here is that mptcp_schedule_work() schedules a work,
then gets a refcount on sk->sk_refcnt if the work was scheduled.
This refcount will be released by mptcp_worker().
[A] if (schedule_work(...)) {
[B] sock_hold(sk);
return true;
}
Problem is that mptcp_worker() can run immediately and complete before [B]
We need instead :
sock_hold(sk);
if (schedule_work(...))
return true;
sock_put(sk);
[1]
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25
Call Trace:
<TASK>
__refcount_add include/linux/refcount.h:-1 [inline]
__refcount_inc include/linux/refcount.h:366 [inline]
refcount_inc include/linux/refcount.h:383 [inline]
sock_hold include/net/sock.h:816 [inline]
mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943
mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316
call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747
expire_timers kernel/time/timer.c:1798 [inline]
__run_timers kernel/time/timer.c:2372 [inline]
__run_timer_base+0x648/0x970 kernel/time/timer.c:2384
run_timer_base kernel/time/timer.c:2393 [inline]
run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403
handle_softirqs+0x22f/0x710 kernel/softirq.c:622
__do_softirq kernel/softirq.c:656 [inline]
run_ktimerd+0xcf/0x190 kernel/softirq.c:1138
smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160
kthread+0x711/0x8a0 kernel/kthread.c:463
ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 |
| The WikiCategoryTagCloud extension is vulnerable to reflected XSS via the linkstyle attribute, which is improperly concatenated into inline HTML without escaping. An attacker can inject JavaScript event handlers such as onmouseenter using carefully crafted input via the {{#tag:tagcloud}} parser function, resulting in arbitrary JavaScript execution when a victim hovers over a link in the category cloud.
The vulnerability exists because the linkstyle parameter is only passed through Sanitizer::checkCss() (which does not escape HTML) and is then directly inserted into a style attribute using string concatenation instead of Html::element or Html::openElement.
This issue affects Mediawiki - WikiCategoryTagCloud extension: from 1.39.X before 1.39.13, from 1.42.X before 1.42.7, from 1.43.X before 1.43.2. |
| Solady is software that provides Solidity snippets with APIs. Starting in version 0.0.125 and prior to version 0.1.24, when an account is deployed via a proxy, using regular Solidity to call its initialization function may result in a silent failure, if the initialization function does not return a `bool` or some other return data. This is because regular Solidity uses `extcodesize(proxy)` to decide if call succeeds. This is insufficient in the case when the proxy points to an empty implementation. Users should upgrade to Solady v0.1.24 or later to receive a patch. Deploy any affected implementations and their factories on new EVM chains as soon as possible. |
| Rucio is a software framework that provides functionality to organize, manage, and access large volumes of scientific data using customizable policies. The common Rucio helm-charts for the `rucio-server`, `rucio-ui`, and `rucio-webui` define the log format for the apache access log of these components. The `X-Rucio-Auth-Token`, which is part of each request header sent to Rucio, is part of this log format. Thus, each access log line potentially exposes the credentials (Internal Rucio token, or JWT in case of OIDC authentication) of the user. Due to the length of the token (Especially for a JWT) the tokens are often truncated, and thus not usable as credential; nevertheless, the (partial) credential should not be part of the logfile. The impact of this issue is amplified if the access logs are made available to a larger group of people than the instance administrators themselves. An updated release has been supplied for the `rucio-server`, `rucio-ui` and `rucio-webui` helm-chart. The change was also retrofitted for the currently supported Rucio LTS releases. The patched versions are rucio-server 37.0.2, 35.0.1, and 32.0.1; rucio-ui 37.0.4, 35.0.1, and 32.0.2; and rucio-webui 37.0.2, 35.1.1, and 32.0.1. As a workaround, one may update the `logFormat` variable and remove the `X-Rucio-Auth-Token`. |
| DiracX-Web is a web application that provides an interface to interact with the DiracX services. Prior to version 0.1.0-a8, an attacker can forge a request that they can pass to redirect an authenticated user to another arbitrary website. In the login page, DiracX-Web has a `redirect` field which is the location where the server will redirect the user. This URI is not verified, and can be an arbitrary URI. Paired with a parameter pollution, an attacker can hide their malicious URI. This could be used for phishing, and extract new data (such as redirecting to a new "log in" page, and asking another time credentials). Version 0.1.0-a8 fixes this vulnerability. |
| OpenZeppelin Contracts is a library for secure smart contract development. Starting in version 5.2.0 and prior to version 5.4.0, the `lastIndexOf(bytes,byte,uint256)` function of the `Bytes.sol` library may access uninitialized memory when the following two conditions hold: 1) the provided buffer length is empty (i.e. `buffer.length == 0`) and position is not `2**256 - 1` (i.e. `pos != type(uint256).max`). The `pos` argument could be used to access arbitrary data outside of the buffer bounds. This could lead to the operation running out of gas, or returning an invalid index (outside of the empty buffer). Processing this invalid result for accessing the `buffer` would cause a revert under normal conditions. When triggered, the function reads memory at offset `buffer + 0x20 + pos`. If memory at that location (outside the `buffer`) matches the search pattern, the function would return an out of bound index instead of the expected `type(uint256).max`. This creates unexpected behavior where callers receive a valid-looking index pointing outside buffer bounds. Subsequent memory accesses that don't check bounds and use the returned index must carefully review the potential impact depending on their setup. Code relying on this function returning `type(uint256).max` for empty buffers or using the returned index without bounds checking could exhibit undefined behavior. Users should upgrade to version 5.4.0 to receive a patch. |
| Let's Encrypt client and ACME library written in Go (Lego). In versions 4.25.1 and below, the github.com/go-acme/lego/v4/acme/api package (thus the lego library and the lego cli as well) don't enforce HTTPS when talking to CAs as an ACME client. Unlike the http-01 challenge which solves an ACME challenge over unencrypted HTTP, the ACME protocol requires HTTPS when a client communicates with the CA to performs ACME functions. However, the library fails to enforce HTTPS both in the original discover URL (configured by the library user) and in the subsequent addresses returned by the CAs in the directory and order objects. If users input HTTP URLs or CAs misconfigure endpoints, protocol operations occur over HTTP instead of HTTPS. This compromises privacy by exposing request/response details like account and request identifiers to network attackers. This was fixed in version 4.25.2. |
| Thinbus Javascript Secure Remote Password is a browser SRP6a implementation for zero-knowledge password authentication. In versions 2.0.0 and below, a protocol compliance bug causes the client to generate a fixed 252 bits of entropy instead of the intended bit length of the safe prime (defaulted to 2048 bits). The client public value is being generated from a private value that is 4 bits below the specification. This reduces the protocol's designed security margin it is now practically exploitable. The servers full sized 2048 bit random number is used to create the shared session key and password proof. This is fixed in version 2.0.1. |
| OpenEBS Local PV RawFile allows dynamic deployment of Stateful Persistent Node-Local Volumes & Filesystems for Kubernetes. Prior to version 0.10.0, persistent volume data is world readable and that would allow non-privileged users to access sensitive data such as databases of k8s workload. The rawfile-localpv storage class creates persistent volume data under /var/csi/rawfile/ on Kubernetes hosts by default. However, the directory and data in it are world-readable. It allows non-privileged users to access the whole persistent volume data, and those can include sensitive information such as a whole database if the Kubernetes tenants are running MySQL or PostgreSQL in a container so it could lead to a database breach. This issue has been patched in version 0.10.0. |
| get-jwks contains fetch utils for JWKS keys. In versions prior to 11.0.2, a vulnerability in get-jwks can lead to cache poisoning in the JWKS key-fetching mechanism. When the iss (issuer) claim is validated only after keys are retrieved from the cache, it is possible for cached keys from an unexpected issuer to be reused, resulting in a bypass of issuer validation. This design flaw enables a potential attack where a malicious actor crafts a pair of JWTs, the first one ensuring that a chosen public key is fetched and stored in the shared JWKS cache, and the second one leveraging that cached key to pass signature validation for a targeted iss value. The vulnerability will work only if the iss validation is done after the use of get-jwks for keys retrieval. This issue has been patched in version 11.0.2. |
| Dependency-Track is a component analysis platform that allows organizations to identify and reduce risk in the software supply chain. Prior to version 4.13.5, Dependency-Track may send credentials meant for a private NuGet repository to `api.nuget.org` via the HTTP `Authorization` header, and may disclose names and versions of components marked as internal to `api.nuget.org`. This can happen if the Dependency-Track instance contains .NET components, a custom NuGet repository has been configured, the custom repository has been configured with authentication credentials, and the repository server does not provide `PackageBaseAddress` resource in its service index. The issue has been fixed in Dependency-Track 4.13.5. Some workarounds are avaialble. Disable custom NuGet repositories until the patch has been applied, invalidate the previously used credentials, and generate new credentials for usage after the patch has been applied. |
| The parisneo/lollms repository is affected by a timing attack vulnerability in the `authenticate_user` function within the `lollms_authentication.py` file. This vulnerability allows attackers to enumerate valid usernames and guess passwords incrementally by analyzing response time differences. The affected version is the latest, and the issue is resolved in version 20.1. The vulnerability arises from the use of Python's default string equality operator for password comparison, which compares characters sequentially and exits on the first mismatch, leading to variable response times based on the number of matching initial characters. |
| Taiko Alethia is an Ethereum-equivalent, permissionless, based rollup designed to scale Ethereum without compromising its fundamental properties. In 2.3.1 and earlier, TaikoInbox._verifyBatches (packages/protocol/contracts/layer1/based/TaikoInbox.sol:627-678) advanced the local tid to whatever transition matched the current blockHash before knowing whether that batch would actually be verified. When the loop later broke (e.g., cooldown window not yet passed or transition invalidated), the function still wrote that newer tid into batches[lastVerifiedBatchId].verifiedTransitionId after decrementing batchId. Result: the last verified batch could end up pointing at a transition index from the next batch (often zeroed), corrupting the verified chain pointer. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: ath11k: fix peer HE MCS assignment
In ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent to
firmware as receive MCS while peer's receive MCS sent as transmit MCS,
which goes against firmwire's definition.
While connecting to a misbehaved AP that advertises 0xffff (meaning not
supported) for 160 MHz transmit MCS map, firmware crashes due to 0xffff
is assigned to he_mcs->rx_mcs_set field.
Ext Tag: HE Capabilities
[...]
Supported HE-MCS and NSS Set
[...]
Rx and Tx MCS Maps 160 MHz
[...]
Tx HE-MCS Map 160 MHz: 0xffff
Swap the assignment to fix this issue.
As the HE rate control mask is meant to limit our own transmit MCS, it
needs to go via he_mcs->rx_mcs_set field. With the aforementioned swapping
done, change is needed as well to apply it to the peer's receive MCS.
Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 |
| A vulnerability classified as critical was found in risesoft-y9 Digital-Infrastructure up to 9.6.7. Affected by this vulnerability is the function deleteFile of the file /Digital-Infrastructure-9.6.7/y9-digitalbase-webapp/y9-module-filemanager/risenet-y9boot-webapp-filemanager/src/main/java/net/risesoft/y9public/controller/Y9FileController.java. The manipulation of the argument fullPath leads to path traversal. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way. |
| A vulnerability was found in rowboatlabs rowboat up to 8096eaf63b5a0732edd8f812bee05b78e214ee97. It has been rated as critical. Affected by this issue is the function PUT of the file apps/rowboat/app/api/uploads/[fileId]/route.ts of the component Session Handler. The manipulation of the argument params leads to missing authentication. The attack may be launched remotely. Continious delivery with rolling releases is used by this product. Therefore, no version details of affected nor updated releases are available. It is expected that this issue will be fixed in the near future. |
| A security issue was discovered in the Kubernetes Image Builder where default credentials are enabled during the Windows image build process when using the Nutanix or VMware OVA providers. These credentials, which allow root access, are disabled at the conclusion of the build. Kubernetes clusters are only affected if their nodes use VM images created via the Image Builder project and the vulnerability was exploited during the build process, which requires an attacker to access the build VM and modify the image while the build is in progress. |
| A vulnerability has been found in ExpressGateway express-gateway up to 1.16.10. Affected is an unknown function in the library lib/rest/routes/apps.js of the component REST Endpoint. The manipulation leads to cross site scripting. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way. |
