| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A security vulnerability has been detected in Open Asset Import Library Assimp Assimp 17c12da. The affected element is the function Assimp::MDLImporter::ParseBoneTrafoKeys_3DGS_MDL7 of the file code/AssetLib/MDL/MDLLoader.cpp of the component 3DGS MDL7 Bone Transformation Key Parser. The manipulation of the argument transmatrix_count/pcBoneTransforms leads to buffer overflow. It is possible to initiate the attack remotely. The exploit has been disclosed publicly and may be used. The identifier of the patch is 50d767984e78d51b53e2020fdf0967fd624bc377. It is recommended to apply a patch to fix this issue. |
| In the Linux kernel, the following vulnerability has been resolved:
ksmbd: use opener credentials for FSCTL mutations
SET_SPARSE, SET_ZERO_DATA and SET_COMPRESSION operate on an open SMB
handle but call VFS xattr, fallocate or fileattr helpers with the current
ksmbd worker credentials. Those helpers can revalidate inode permissions,
ownership and LSM policy independently of the SMB handle access mask.
Run each operation with the credentials captured in the target file when
the handle was opened. Keep credential handling local to these single-file
FSCTLs rather than applying session credentials to the complete IOCTL
handler, which also contains handle-less and multi-handle operations. |
| A weakness has been identified in code-projects Online Shopping System 1.0. Impacted is an unknown function of the file offersmail.php. Executing a manipulation of the argument email can lead to cross site scripting. The attack may be performed from remote. The exploit has been made available to the public and could be used for attacks. |
| A vulnerability was identified in GL.iNet A1300, AX1800, AXT1800, BE1400, BE3600, BE6500, BE9300, BE10000, E5800, MT2500, MT3000, MT3600BE, MT5000, MT6000, X2000, X3000 and XE3000 up to 4.8.x. Affected by this vulnerability is the function COPY/MOVE of the component WebDAV Service. Such manipulation leads to authorization bypass. It is possible to launch the attack remotely. The vendor explains: "After our investigation, we have confirmed that the vulnerability described (...) does indeed exist." |
| A vulnerability was identified in Webkul Bagisto up to 2.4.4. This vulnerability affects unknown code of the file /admin/customers of the component Backend Customer Behavior Data Endpoint. Such manipulation of the argument ID leads to improper privilege management. The attack can be executed remotely. The exploit is publicly available and might be used. The vendor confirms: "The reported issues were already identified through our internal security assessment process prior to this notification and are being handled through our established internal security and development lifecycle. Some of these items have already been addressed, while the remaining items are planned for resolution in upcoming product releases." |
| A vulnerability was determined in Webkul Bagisto up to 2.4.4. This affects an unknown part of the file /customer/account/rma/send-message of the component RMA Message Handler. This manipulation of the argument Message causes cross site scripting. Remote exploitation of the attack is possible. The exploit has been publicly disclosed and may be utilized. The vendor confirms: "The reported issues were already identified through our internal security assessment process prior to this notification and are being handled through our established internal security and development lifecycle. Some of these items have already been addressed, while the remaining items are planned for resolution in upcoming product releases." |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix stack slot index in nospec checks
check_stack_write_fixed_off() computes the byte slot for a fixed-offset
stack write as -off - 1, and records each written byte in slot_type[] with
(slot - i) % BPF_REG_SIZE.
The Spectre v4 sanitization pre-check uses slot_type[i] instead. For a
4-byte write at fp-8 after the lower half of fp-8 has been zeroed, the
pre-check scans bytes 0..3 and sees STACK_ZERO while the actual write updates
bytes 7..4. That can leave the second half-slot write without nospec_result
even though the bytes being overwritten still require sanitization.
Use the same slot index in the sanitization pre-check that the write path uses
when updating slot_type[]. |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: FCP: Fix NULL pointer dereference in interface lookup
A malformed USB device can provide a vendor-specific interface without
any endpoint descriptors. fcp_find_fc_interface() currently selects the
first vendor-specific interface and reads endpoint 0 from it, without
checking whether the interface actually has any endpoints.
When bNumEndpoints is zero, no endpoint array is allocated for the parsed
alternate setting, so get_endpoint(..., 0) yields an invalid endpoint
descriptor pointer. Dereferencing it through usb_endpoint_num() then
triggers a NULL pointer dereference.
Skip vendor-specific interfaces that do not have any endpoints. |
| In the Linux kernel, the following vulnerability has been resolved:
hwmon: adm1275: Prevent reading uninitialized stack
While adding support for the ROHM BD127X0 hot-swap controllers, sashiko
reported an error in device-name comparison, which can lead to reading
uninitialized stack memory.
Quoting Sashiko:
This is a pre-existing issue, but I noticed that just before this block in
adm1275_probe(), there might be an out-of-bounds stack read:
ret = i2c_smbus_read_block_data(client, PMBUS_MFR_MODEL, block_buffer);
if (ret < 0) { ... }
for (mid = adm1275_id; mid->name[0]; mid++) {
if (!strncasecmp(mid->name, block_buffer, strlen(mid->name)))
break;
}
Since i2c_smbus_read_block_data() reads up to 32 bytes into the
uninitialized stack array block_buffer without appending a null
terminator, strncasecmp() could read past the valid bytes returned in ret.
For example, if the device returns a shorter string like "adm12", checking
it against "adm1275" up to the length of "adm1275" will continue reading
into uninitialized stack bounds.
Prevent reading uninitialized memory by zeroing the stack array. |
| In the Linux kernel, the following vulnerability has been resolved:
VDUSE: avoid leaking information to userspace
The bounceing is not necessarily page aligned, so current VDUSE can
leak kernel information through mapping bounce pages to
userspace. Allocate bounce pages with __GFP_ZERO to avoid leaking
information to userspace. |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: Initialize KVM_S390_GET_CMMA_BITS memory
kvm_s390_get_cmma_bits() allocates its output buffer with vmalloc(),
which does not zero the returned pages:
values = vmalloc(args->count);
In the non-peek (migration) path, dat_get_cmma() reports a byte count
spanning from the first to the last dirty page, but __dat_get_cmma_pte()
writes values[gfn - start] only for pages whose CMMA dirty bit is set.
The walk uses DAT_WALK_IGN_HOLES, so clean and unmapped pages that lie
between two dirty pages within the reported span are visited but never
store their byte. Those gaps (up to KVM_S390_MAX_BIT_DISTANCE pages
each) stay uninitialized yet fall inside [0, count) and are copied out
by copy_to_user(), disclosing stale kernel memory to user space.
Before the switch to the new gmap implementation the buffer was fully
populated for every gfn in the span, so no uninitialized bytes were
exposed; the dirty-only walk introduced the leak.
Use vzalloc() so the gaps read back as zero. |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. |
| In the Linux kernel, the following vulnerability has been resolved:
gpu: host1x: Fix device reference leak in host1x_device_parse_dt() error path
After device_initialize(), the embedded struct device in struct
host1x_device should be released through the device core with
put_device().
In host1x_device_add(), if host1x_device_parse_dt() fails, the current
error path frees the object directly with kfree(device). That bypasses
the normal device lifetime handling and leaks the reference held on the
embedded struct device.
The issue was identified by a static analysis tool I developed and
confirmed by manual review.
Fix this by using put_device() in the host1x_device_parse_dt() failure
path. |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. |
| In the Linux kernel, the following vulnerability has been resolved:
s390/monwriter: Reject buffer reuse with different data length
When data buffers are reused, e.g. for interval sample records, the
first record determines the data length, and the size of the buffer for
user copy. Current monwriter code does not check if the data length was
changed for subsequent records, which also would never happen for valid
user programs.
However, a malicious user could change the data length, resulting in out
of bounds user copy to the kernel buffer, and memory corruption. By
default, the monwriter misc device is created with root-only permissions,
so practical impact is typically low.
Fix this by checking for changed data length and rejecting such records. |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. |
| A vulnerability was found in Webkul Bagisto up to 2.4.4. Affected by this issue is some unknown functionality of the file /admin/configuration/cache-management/execute of the component Configuration Management. The manipulation of the argument action results in authorization bypass. The attack may be launched remotely. The exploit has been made public and could be used. The vendor confirms: "The reported issues were already identified through our internal security assessment process prior to this notification and are being handled through our established internal security and development lifecycle. Some of these items have already been addressed, while the remaining items are planned for resolution in upcoming product releases." |
| A vulnerability has been found in Webkul Bagisto up to 2.4.4. Affected by this vulnerability is an unknown functionality of the file /customer/account/rma/update-status of the component RMA State Validation. The manipulation leads to enforcement of behavioral workflow. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. The vendor confirms: "The reported issues were already identified through our internal security assessment process prior to this notification and are being handled through our established internal security and development lifecycle. Some of these items have already been addressed, while the remaining items are planned for resolution in upcoming product releases." |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: libiscsi: Fix stale-data leak into the SCSI sense buffer
iscsi_scsi_cmd_rsp() copies the sense data of a SCSI Response from the
target-supplied data segment. The segment carries a 2-byte sense length
followed by the sense bytes, so it must hold 2 + senselen bytes, but the
bounds check only requires datalen >= senselen:
senselen = get_unaligned_be16(data);
if (datalen < senselen)
goto invalid_datalen;
memcpy(sc->sense_buffer, data + 2,
min_t(uint16_t, senselen, SCSI_SENSE_BUFFERSIZE));
A target that returns a SCSI Response whose datalen equals senselen
(with senselen <= SCSI_SENSE_BUFFERSIZE) makes the memcpy() from data +
2 read up to two bytes past the received data. Those bytes are stale
conn->data contents and end up in the command's sense buffer, which is
returned to userspace.
Account for the 2-byte sense length prefix in the check. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: libiscsi_tcp: Bound SCSI Response data segment to the connection buffer
iscsi_tcp_hdr_dissect() receives the data segment of several PDU types
into the fixed-size conn->data buffer, which is allocated for
ISCSI_DEF_MAX_RECV_SEG_LEN (8192) bytes. For the LOGIN_RSP, TEXT_RSP,
REJECT and ASYNC_EVENT opcodes the dissect path already rejects a PDU
whose DataSegmentLength exceeds that buffer.
The SCSI Command Response (ISCSI_OP_SCSI_CMD_RSP) path also copies its
data segment (sense/response data) into conn->data via
iscsi_tcp_data_recv_prep(), but it does so without the same check. The
only upstream bound on in.datalen is conn->max_recv_dlength, the
initiator's advertised MaxRecvDataSegmentLength, which is commonly
negotiated well above 8192 (open-iscsi defaults to 262144). A target
that returns a SCSI Response with a DataSegmentLength between 8193 and
max_recv_dlength therefore overflows the 8192-byte conn->data buffer.
Once the same bound applies, ISCSI_OP_SCSI_CMD_RSP is handled exactly
like those responses: bound the data segment, receive it into conn->data
when present, and otherwise complete the PDU with no data. Fold the
opcode into that case group rather than duplicating the check. |
