| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| When building the iovec array for a received TLS 1.2 CBC record, ktls_ocf_tls_cbc_decrypt() incremented the iovec index for every mbuf in the chain, including mbufs that were skipped because they contained only TLS header bytes. This left uninitialized entries in the iovec array. The iovec array was allocated without zeroing.
A remote TLS peer can cause the kernel to read from uninitialized iovec entries during HMAC computation, resulting in a kernel panic. The peer must be able to control TCP segmentation such that the first mbuf of a CBC record contains only the 5-byte TLS record header. |
| Uninitialized resource in Skia in Google Chrome prior to 152.0.7977.65 allowed a remote attacker who had compromised the renderer process to potentially obtain cross-origin data via a crafted HTML page. (Chromium security severity: Medium) |
| To retrieve the previous timer value, the kernel calls realtimer_gettime(), which obtains the current time for the timer's clock. For a timer using CLOCK_TAI this can fail when no TAI offset has been configured, but the error return was not checked, so the uninitialized output buffer was copied to userspace.
An unprivileged local user can obtain uninitialized kernel stack memory by creating a POSIX timer with CLOCK_TAI and calling timer_settime(2), potentially disclosing sensitive kernel data. |
| Uninitialized resource in ANGLE in Google Chrome prior to 152.0.7977.65 allowed a remote attacker to obtain cross-origin data via a crafted HTML page. (Chromium security severity: High) |
| Uninitialized resource in ANGLE in Google Chrome prior to 152.0.7977.65 allowed a remote attacker to potentially bypass web origin policy via a crafted HTML page. (Chromium security severity: Medium) |
| Uninitialized resource in ANGLE in Google Chrome prior to 152.0.7977.65 allowed a remote attacker to obtain cross-origin data via a crafted HTML page. (Chromium security severity: High) |
| Uninitialized resource in GPU in Google Chrome prior to 152.0.7977.65 allowed a remote attacker who had compromised the renderer process to potentially read memory outside the sandbox via a crafted HTML page. (Chromium security severity: Medium) |
| Uninitialized resource in GPU in Google Chrome prior to 152.0.7977.65 allowed a remote attacker who had compromised the renderer process to potentially obtain cross-origin data via a crafted HTML page. (Chromium security severity: High) |
| Uninitialized resource in GPU in Google Chrome prior to 152.0.7977.65 allowed a remote attacker who had compromised the renderer process to potentially read memory outside the sandbox via a crafted HTML page. (Chromium security severity: Medium) |
| Uninitialized resource in ANGLE in Google Chrome prior to 152.0.7977.65 allowed a remote attacker to potentially obtain cross-origin data via a crafted HTML page. (Chromium security severity: Medium) |
| Uninitialized resource in ANGLE in Google Chrome on on Windows prior to 152.0.7977.65 allowed a remote attacker to obtain cross-origin data via a crafted HTML page. (Chromium security severity: Medium) |
| In the Linux kernel, the following vulnerability has been resolved:
power: supply: max17040: handle missing status supplier
MAX17040 does not report charger state itself, so the driver forwards
POWER_SUPPLY_PROP_STATUS to a supplier power supply. If no supplier is
registered, power_supply_get_property_from_supplier() returns -ENODEV and
leaves the output value untouched.
max17040_get_property() currently ignores that error and returns success,
so userspace can read an uninitialized status value from the battery power
supply. This happens on systems that use the fuel gauge without a charger
supplier relationship in firmware.
Return POWER_SUPPLY_STATUS_UNKNOWN when no supplier provides STATUS, and
propagate other supplier lookup errors. |
| Uninitialized resource in Video in Google Chrome prior to 152.0.7977.65 allowed a remote attacker to read memory inside the sandbox via a crafted HTML page. (Chromium security severity: Medium) |
| In the Linux kernel, the following vulnerability has been resolved:
Input: synaptics-rmi4 - propagate F54 worker errors to V4L2 queue
Previously, rmi_f54_buffer_queue() waited for the worker thread to
finish but ignored whether it succeeded. If the worker failed (e.g.,
due to a timeout or register read failure), the queue thread would
silently return success, delivering stale or uninitialized memory to
userspace.
Add a 'report_error' field to struct f54_data to store the worker's exit
status. Check this field in rmi_f54_buffer_queue() after the worker
finishes, and mark the buffer as VB2_BUF_STATE_ERROR if an error
occurred. |
| Uninitialized resource in GPU in Google Chrome on on Android prior to 152.0.7977.65 allowed a remote attacker to potentially read memory inside the sandbox via a crafted HTML page. (Chromium security severity: Low) |
| Uninitialized resource in GPU in Google Chrome on on Android prior to 152.0.7977.65 allowed a remote attacker to read memory outside the sandbox via a crafted HTML page. (Chromium security severity: Low) |
| Uninitialized resource in WebXR in Google Chrome prior to 152.0.7977.65 allowed a remote attacker leveraging social engineering to potentially leak cross-origin data via a crafted HTML page. (Chromium security severity: Medium) |
| Uninitialized resource in Skia in Google Chrome prior to 152.0.7977.65 allowed a remote attacker to potentially read memory inside the sandbox via a crafted HTML page. (Chromium security severity: Low) |
| OpenEXR is the reference implementation and specification for the EXR image file format, widely used in the motion picture industry. In versions 3.3.0 through 3.3.12 and 3.4.0 through 3.4.13, the PyOpenEXR Python bindings return stale heap data when reading a crafted deep scanline EXR that uses layer-prefixed RGB channels. With the default channel coalescing (separate_channels=False), the wrapper groups channels such as left.R, left.G, and left.B into a single RGB sample array, but the lane-offset calculation in PyPart::setDeepSliceData() only recognizes the exact unprefixed names G, B, and A. As a result, prefixed channels like left.G and left.B are decoded into lane 0 while lanes 1 and 2 are left uninitialized and returned to Python. A Python application that reads untrusted deep EXR files through the default OpenEXR.File API and then logs, serializes, previews, or otherwise processes the resulting NumPy sample arrays may expose uninitialized same-process heap contents, in addition to receiving incorrect green and blue channel data. This issue is fixed in versions 3.3.13 and 3.4.14. |
| A vulnerability was found in vLLM up to 0.19.0. The affected element is the function has_mamba_layers of the file vllm/v1/kv_cache_interface.py of the component KV Block Handler. Performing a manipulation results in uninitialized resource. It is possible to initiate the attack remotely. The attack is considered to have high complexity. The exploitability is described as difficult. The exploit has been made public and could be used. The existence of this vulnerability is still disputed at present. The proposed patch did not fix the issue. A 3rd party explains: "The divergence could be explained by a benign and expected vLLM behavior where vLLM server could group concurrent requests together resulting in different input shapes based on varying request arrival time. The differences in grouped input shapes could call different kernels with could produce difference results due to rounding and differences in order of operations. There is an environment variable VLLM_BATCH_INVARIANT=1 for users that desire to have deterministic output with temperature 0.0." |
