| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A filename supplied during file upload is not properly sanitized before being used in system command execution, allowing an attacker to inject shell metacharacters and achieve command injection via the audit file upload functionality. |
| Ollama (HEAD f0078ae) contains an uncontrolled memory allocation vulnerability in the GGUF metadata parser that allows remote attackers to crash the server by supplying a crafted GGUF file with attacker-controlled length and count fields in string lengths, tensor dimension counts, and metadata array counts that are used as allocation sizes without validation against remaining file size. Attackers can upload a sub-1KB crafted GGUF file via the blob upload and model create or pull API endpoints to trigger unrecoverable Go runtime out-of-memory fatal errors or makeslice panics that bypass recovery middleware and crash the entire server process. |
| DoS vulnerability in the vibration service. Impact: Successful exploitation of this vulnerability may affect availability. |
| A vulnerability was identified in danger danger-js up to 13.0.7. Impacted is the function danger.git.diffForFile of the file source/platforms/git/localGetFileAtSHA.ts of the component CLI. Such manipulation of the argument File leads to os command injection. The attack needs to be performed locally. Upgrading to version 13.0.8 is recommended to address this issue. The name of the patch is 087a7290264cc6fb7154ea8c2552a7b2cb8b33a3. It is advisable to upgrade the affected component. |
| A potential out-of-bounds write vulnerability could allow a local privileged attacker to modify power management settings in System Management Mode. |
| A potential out of bounds write vulnerability could allow a local privileged attacker to execute code in System Management Mode. |
| django-pyas2 through 1.2.3 is vulnerable to OS command injection via the cmd_receive and cmd_send fields on the Partner model. These fields are passed directly to os.system() in pyas2/utils.py without sanitization, allowing an authenticated admin user to execute arbitrary commands on the server when an AS2 message is received or sent. |
| The MCTP-over-I2C+GPIO target binding in Zephyr (subsys/pmci/mctp/mctp_i2c_gpio_target.c) processes pseudo-register writes from an I2C bus master byte-by-byte in mctp_i2c_gpio_target_write_received() without validating the order or the receive buffer. In the affected versions the MCTP_I2C_GPIO_RX_MSG_ADDR (data) handler dereferences and writes through b->rx_pkt without checking that the receive buffer was allocated: a controller that selects the data register and writes a byte without first sending the length register (which is what allocates the buffer) causes a write of an attacker-chosen byte through a NULL/unallocated mctp_pktbuf pointer (i.e. into a small attacker-advanceable offset above address 0), producing memory corruption or a hard fault.
The same handler also performs a write-then-check bounds test, allowing a one-byte heap overflow at data[255] when more than 255 data bytes are sent.
Because the I2C target callback is invoked with raw bytes supplied by whatever device is the bus master and the binding performs no authentication, a malicious or malfunctioning controller on the bus can trigger these without any prior protocol state, leading to memory corruption and/or denial of service on the target device.
The vulnerable code was introduced when the I2C+GPIO target binding was added and shipped in Zephyr v4.3.0 and v4.4.0. The fix defers allocation to the first data byte with a NULL check, treats a missing length as a zero-sized packet rejected by libmctp, and moves the bounds check before the store. |
| Autel Maxi Charger Single firmware through V1.03.51 is vulnerable to OS command injection in the /test endpoint exposed on TCP port 9002. An unauthenticated attacker can supply crafted input in the url parameter to execute arbitrary operating system commands. |
| Autel Maxi Charger Single firmware through V1.03.51 is vulnerable to OS command injection when processing OCPP GetDiagnostics requests. A malicious or compromised OCPP server can supply a crafted diagnostics URL that results in arbitrary command execution on the charging station. |
| Incorrect boundary conditions in the Graphics component. This vulnerability was fixed in Firefox 153, Firefox ESR 115.38, Firefox ESR 140.13, Thunderbird 153, and Thunderbird 140.13. |
| Incorrect boundary conditions in the JavaScript: WebAssembly component. This vulnerability was fixed in Firefox 153, Firefox ESR 140.13, Thunderbird 153, and Thunderbird 140.13. |
| Sandbox escape due to invalid pointer in the Disability Access APIs component. This vulnerability was fixed in Firefox 153 and Thunderbird 153. |
| A flaw was found in libssh. A remote authenticated client can issue SSH_FXP_READ requests with an arbitrarily large length, causing a libssh SFTP server to allocate excessive memory and potentially exhaust it through repeated requests. |
| A flaw was found in the Visual Studio Code Ansible Lightspeed extension. This command injection vulnerability (CWE-78) arises from improper handling of the ansible.executionEnvironment.containerOptions and ansible.executionEnvironment.volumeMounts settings, allowing an attacker to inject shell separators. This can be triggered automatically during Language Server initialization or manually when executing a playbook. Successful exploitation leads to remote code execution (RCE) on the victim's machine with the privileges of the Visual Studio Code user, potentially resulting in a complete system compromise. |
| In the Linux kernel, the following vulnerability has been resolved:
USB: serial: mct_u232: fix memory corruption with small endpoint
The driver overrides the maximum transfer size for a specific device
which only accepts 16 byte packets for its 32 byte bulk-out endpoint.
Make sure to never increase the maximum transfer size to prevent slab
corruption should a malicious device report a smaller endpoint max
packet size than expected. |
| In the Linux kernel, the following vulnerability has been resolved:
Input: atmel_mxt_ts - fix boundary check in mxt_prepare_cfg_mem
When a configuration file provides an object size that is larger than the
driver's known mxt_obj_size(object), the driver intends to discard the
extra bytes.
The loop iterates using for (i = 0; i < size; i++). Inside the loop, the
condition to skip processing extra bytes is:
if (i > mxt_obj_size(object))
continue;
Since i is a 0-based index, the valid indices for the object are 0 through
mxt_obj_size(object) - 1.
When i == mxt_obj_size(object), the condition evaluates to false, and the
code processes the byte instead of discarding it.
This causes the code to calculate byte_offset = reg + i - cfg->start_ofs
and writes the byte there, overwriting exactly one byte of the adjacent
instance or object.
Update the boundary check to skip extra bytes correctly by using >=. |
| In the Linux kernel, the following vulnerability has been resolved:
HID: wacom: Fix OOB write in wacom_hid_set_device_mode()
wacom_hid_set_device_mode() currently assumes that the HID_DG_INPUTMODE
usage is always located in the first field (field[0]) of the feature report.
However, a device can specify HID_DG_INPUTMODE in a different field.
If HID_DG_INPUTMODE is in a field other than the first one and the first
field has a report_count smaller than the usage_index of HID_DG_INPUTMODE,
this leads to an out-of-bounds write to r->field[0]->value.
Fix this by storing the field index of HID_DG_INPUTMODE in 'struct
hid_data' during feature mapping. In wacom_hid_set_device_mode(), use
this stored field index to access the correct field and add bounds
checks to ensure both the field index and the value index are within
valid ranges before writing. |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: SEV: Compute the correct max length of the in-GHCB scratch area
When setting the length of the GHCB scratch area, and the area is in the
GHCB shared buffer, set the effective length of the scratch area to the max
possible size given the start of the guest-provided pointer, and the end of
the shared buffer.
The code was "fine" when first introduced, as KVM doesn't consult the
length of the buffer when emulating MMIO, because the passed in @len always
specifies the *max* size required. But for PSC requests, the incoming @len
is just the minimum length (to process the header), and KVM needs to know
the full size of the scratch area to avoid buffer overflows (spoiler alert).
Opportunistically rename @len => @min_len to better reflect its role. |
| In the Linux kernel, the following vulnerability has been resolved:
iio: imu: st_lsm6dsx: fix stack leak in tagged FIFO buffer
The tagged FIFO path declares iio_buff on the stack with __aligned(8)
but no initializer, but there is a hole in the structure, which will
then leak to userspace as ST_LSM6DSX_SAMPLE_SIZE bytes (6) will be
copied, but the space between that and the timestamp are not
initialized.
Commit c14edb4d0bdc ("iio:imu:st_lsm6dsx Fix alignment and data leak
issues") moved the untagged FIFO path to a kzalloc'd buffer in hw->scan,
but for the tagged path it only added the alignment qualifier and not
the initializer :(
Fix this by just zero-initializing the structure on the stack. |
