| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| OpenSlide is a C library for reading whole slide image files. Prior to 4.0.1, a behavior change in libtiff 4.7.1 causes the indirect TIFF tile path in src/openslide-decode-tiff.c and _openslide_tiff_read_tile() to request a full-height destination for a partial bottom tile row, allowing uninitialized heap memory to enter pixel data returned by openslide_read_region(). A crafted but valid slide can trigger the issue in TIFF-based formats other than Hamamatsu NDPI when a network service renders attacker-provided slides. Successful extraction depends on pixel transparency handling and recompression, OpenSlide with libtiff 4.7.0 or earlier is not affected, and official binary builds 4.0.0.10 and 4.0.0.11 are affected. This issue is fixed in OpenSlide 4.0.1 and official binary build 4.0.0.12. |
| A memory initialization issue was addressed with improved memory handling. This issue is fixed in iOS 26.7 and iPadOS 26.7, iOS 27 and iPadOS 27, macOS Golden Gate 27, macOS Sequoia 15.8, macOS Tahoe 26.7, tvOS 27, visionOS 27, watchOS 27. An app with root privileges may be able to read uninitialized kernel memory. |
| Uninitialized resource in Skia in Google Chrome prior to 153.0.8010.47 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 153.0.8010.36 allowed a remote attacker who had compromised the renderer process to read memory outside the sandbox via a crafted HTML page. (Chromium security severity: High) |
| Uninitialized resource in GPU in Google Chrome on on Android prior to 153.0.8010.36 allowed a remote attacker who had compromised the renderer process to 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 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 who had compromised the renderer process to read memory outside the sandbox via a crafted HTML page. (Chromium security severity: Medium) |
| Uninitialized resource in Dawn 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: Medium) |
| Uninitialized resource in GPU in Google Chrome on on Android prior to 153.0.8010.36 allowed a remote attacker to read memory outside the sandbox via a crafted HTML page. (Chromium security severity: Medium) |
| Uninitialized resource in ANGLE in Google Chrome prior to 153.0.8010.47 allowed a remote attacker to read memory outside the sandbox via a crafted HTML page. (Chromium security severity: High) |
| Use of uninitialized resource in Windows GDI+ allows an authorized attacker to disclose information locally. |
| Use of uninitialized resource in Windows Management Instrumentation allows an authorized attacker to disclose information over a network. |
| Insertion of sensitive information into log file in Windows Program Compatibility Assistant Service allows an authorized attacker to disclose information locally. |
| Heap-based buffer overflow in Windows ALPC allows an authorized attacker to elevate privileges locally. |
| Use of uninitialized resource in Windows Win32K allows an authorized attacker to disclose information locally. |
| Use of uninitialized resource in SQL Server allows an authorized attacker to disclose information over a network. |
| Use of uninitialized resource in SQL Server allows an authorized attacker to disclose information over a network. |
| Use of uninitialized resource in SQL Server allows an authorized attacker to disclose information over a network. |
| Use of uninitialized resource in Windows Win32 Kernel Subsystem allows an authorized attacker to disclose information locally. |
| In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: fix info-leak on partial LZNT decompress in ni_read_frame()
ni_read_frame() decompresses an LZNT $DATA frame into the vmapped target
pages and then trusts decompress_lznt()'s return value:
unc_size = decompress_lznt(frame_ondisk, ondisk_size, frame_mem,
frame_size);
if ((ssize_t)unc_size < 0) err = unc_size;
else if (!unc_size || unc_size > frame_size) err = -EINVAL;
decompress_lznt() stops as soon as the compressed stream is exhausted
(e.g. a zero chunk header) and returns the number of bytes it actually
wrote, which may be far less than frame_size. The bytes between unc_size
and frame_size are never written. The only memset() that follows zeroes
the region beyond i_valid; when the frame lies entirely within the file's
valid size that memset() does not run, so the gap retains whatever was in
the just-vmapped pages. All pages are then marked uptodate and returned
to userspace, disclosing uninitialized (recently-freed) kernel page
memory. A crafted compressed file whose stream decompresses to only a few
bytes leaks the remainder of every frame on a plain read(2), which is
enough to recover kernel pointers and defeat KASLR.
Zero the [unc_size, frame_size) tail immediately after a successful LZNT
decompress so the remainder reads back as zero. |
