| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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. |
| In the Linux kernel, the following vulnerability has been resolved:
fbdev: omapfb: panel-dsi-cm: initialize lock before registering display
dsicm_probe() registers the display before initializing ddata->lock.
Once omapdss_register_display() publishes the display, another consumer
can reach a dsicm callback that takes this mutex while it is still
uninitialized.
Initialize the mutex before registering the display so the published
callbacks always see a valid lock. |
| In the Linux kernel, the following vulnerability has been resolved:
s390/dasd: Propagate partial completion length across ERP recovery
dasd_default_erp_postaction() copies the timing and device state from
the finished ERP request back to the original request but drops
proc_bytes. A request that was partially completed, an ESE read of a
not-yet-allocated track returns fewer bytes than requested, and then
recovered through the ERP chain loses its partial-completion length.
__dasd_cleanup_cqr() then sees proc_bytes == 0 and completes the whole
request instead of requeueing the remainder, silently returning zeroed
data for the part that was never read.
Carry proc_bytes over to the original request like the other
per-request state. |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: FCP: do not copy out an uninitialised init response
fcp_ioctl_init() allocates its response buffer with kmalloc() and copies
the whole buffer back to userspace:
buf_size = init.step0_resp_size + init.step2_resp_size;
void *resp __free(kfree) =
kmalloc(buf_size, GFP_KERNEL);
...
if (copy_to_user(arg->resp, resp, buf_size))
return -EFAULT;
Nothing clears the buffer, and the only writer of its leading
step0_resp_size bytes is the step-0 control transfer:
err = snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0),
FCP_USB_REQ_STEP0,
USB_RECIP_INTERFACE | USB_TYPE_CLASS | USB_DIR_IN,
0, private->bInterfaceNumber,
step0_resp, private->step0_resp_size);
if (err < 0)
return err;
usb_fill_control_urb() does not set URB_SHORT_NOT_OK, so a short or
zero-length data stage completes with status 0 and snd_usb_ctl_msg()
returns a small actual_length. The only check is err < 0, so a short
transfer is accepted as success.
snd_usb_ctl_msg() copies the full size back unconditionally:
buf = kmemdup(data, size, GFP_KERNEL);
...
memcpy(data, buf, size);
Bytes the device never wrote are therefore restored into resp unchanged
and copied to userspace. step0_resp_size and step2_resp_size are each
validated only to 1..255, so the caller also picks the slab cache, from
kmalloc-8 up to kmalloc-512.
On 7.2.0-rc5 (arm64), device answering step 0 with a zero-length data
stage, s0 = s2 = 255:
# init_on_alloc off, no spray
step0 window [0,255): nonzero=94/255
000: 00 80 60 06 00 00 ff ff 18 00 00 00 57 01 ea 01
010: 08 78 22 13 00 00 ff ff a8 c4 5f 80 00 80 ff ff
# same kernel, kmalloc-512 pre-seeded with an 8-byte tag
step0 window [0,255): nonzero=219/255 tagbytes=232
# identical run, init_on_alloc=1
step0 window [0,255): nonzero=0/255 tagbytes=0
# all three runs
step2 window [255,510): device words matched=62/62
a8 c4 5f 80 00 80 ff ff is the little-endian kernel text address
ffff8000805fc4a8. The step-2 window is unaffected, so the disclosure is
exactly the step-0 region.
Zero the buffer, and require the step-0 transfer to deliver the full
step0_resp_size bytes so a short data stage is reported as an error.
Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com> |
| In the Linux kernel, the following vulnerability has been resolved:
ext4: move ext4_percpu_param_init() before ext4_mb_init()
When running `kvm-xfstests -c ext4/1k -C 1 generic/383` with the
`DOUBLE_CHECK` macro defined, the following panic is triggered:
==================================================================
EXT4-fs error (device vdc): ext4_validate_block_bitmap:423:
comm mount: bg 0: bad block bitmap checksum
BUG: unable to handle page fault for address: ff110000fa2cc000
PGD 3e01067 P4D 3e02067 PUD 0
Oops: Oops: 0000 [#1] SMP NOPTI
CPU: 0 UID: 0 PID: 2386 Comm: mount Tainted: G W
6.18.0-gba65a4e7120a-dirty #1152 PREEMPT(none)
RIP: 0010:percpu_counter_add_batch+0x13/0xa0
Call Trace:
<TASK>
ext4_mark_group_bitmap_corrupted+0xcb/0xe0
ext4_validate_block_bitmap+0x2a1/0x2f0
ext4_read_block_bitmap+0x33/0x50
mb_group_bb_bitmap_alloc+0x33/0x80
ext4_mb_add_groupinfo+0x190/0x250
ext4_mb_init_backend+0x87/0x290
ext4_mb_init+0x456/0x640
__ext4_fill_super+0x1072/0x1680
ext4_fill_super+0xd3/0x280
get_tree_bdev_flags+0x132/0x1d0
vfs_get_tree+0x29/0xd0
vfs_cmd_create+0x59/0xe0
__do_sys_fsconfig+0x4f6/0x6b0
do_syscall_64+0x50/0x1f0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
==================================================================
This issue can be reproduced using the following commands:
mkfs.ext4 -F -q -b 1024 /dev/sda 5G
tune2fs -O quota,project /dev/sda
mount /dev/sda /tmp/test
With DOUBLE_CHECK defined, mb_group_bb_bitmap_alloc() reads
and validates the block bitmap. When the validation fails,
ext4_mark_group_bitmap_corrupted() attempts to update
sbi->s_freeclusters_counter. However, this percpu_counter has not been
initialized yet at this point, which leads to the panic described above.
Fix this by moving the execution of ext4_percpu_param_init() to occur
before ext4_mb_init(), ensuring the per-CPU counters are initialized
before they are used. |
| An information leakage vulnerability exists in the Endpoint DLP component (epdlpdrv.sys) of Netskope Client for Windows prior to version R141. An internal communication channel used by the user-space hook DLL to pass messages through the kernel driver to the daemon lacked proper token-based message validation, allowing local unprivileged processes to send unauthorized queries. Additionally, a reply buffer used by the port message handler was not properly initialized before returning data, leaking residual kernel pool memory from prior allocations. A local unprivileged attacker could exploit this vulnerability to enumerate DLP configuration and feature flags, extract live session tokens, and read kernel memory fragments from other users' operations. |
