| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Use after free in DevTools in Google Chrome prior to 152.0.7977.65 allowed a remote attacker leveraging social engineering to execute arbitrary code inside the sandbox via a crafted Chrome extension. (Chromium security severity: Medium) |
| Use after free in ANGLE in Google Chrome prior to 152.0.7977.65 allowed a remote attacker to execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: High) |
| A vulnerability has been identified in the libarchive library, specifically within the archive_read_format_rar_seek_data() function. This flaw involves an integer overflow that can ultimately lead to a double-free condition. Exploiting a double-free vulnerability can result in memory corruption, enabling an attacker to execute arbitrary code or cause a denial-of-service condition. |
| In the Linux kernel, the following vulnerability has been resolved:
Drivers: hv: vmbus: use generic driver_override infrastructure
When a driver is probed through __driver_attach(), the bus' match()
callback is called without the device lock held, thus accessing the
driver_override field without a lock, which can cause a UAF.
Fix this by using the driver-core driver_override infrastructure taking
care of proper locking internally.
Note that calling match() from __driver_attach() without the device lock
held is intentional. [1] |
| In the Linux kernel, the following vulnerability has been resolved:
iommufd: Take dma_resv lock before dma_buf_unpin() in release path
dma_buf_unpin() requires the caller to hold the exporter's dma_resv
lock:
void dma_buf_unpin(struct dma_buf_attachment *attach)
{
...
dma_resv_assert_held(dmabuf->resv);
...
}
iopt_release_pages() calls dma_buf_unpin() without taking that lock,
so every iommufd_ioas_destroy()/iommufd_ioas_unmap() that releases
the last reference on a DMABUF-backed iopt_pages triggers a WARN.
This was hit while running tools/testing/selftests/iommu/iommufd:
WARNING: drivers/dma-buf/dma-buf.c:1137 at dma_buf_unpin+0x62/0x70
RIP: 0010:dma_buf_unpin+0x62/0x70
Call Trace:
<TASK>
dma_buf_unpin+0x62/0x70
iopt_release_pages+0xe4/0x190
iopt_unmap_iova_range+0x1c7/0x290
iopt_unmap_all+0x1a/0x30
iommufd_ioas_destroy+0x1d/0x50
iommufd_fops_release+0x93/0x150
__fput+0xfc/0x2c0
__x64_sys_close+0x3d/0x80
do_syscall_64+0x65/0x180
</TASK>
Take the dma_resv lock around dma_buf_unpin() in iopt_release_pages(),
matching the iopt_map_dmabuf() convention. dma_buf_detach() acquires the
reservation lock internally, so it must remain outside the locked region. |
| In the Linux kernel, the following vulnerability has been resolved:
i2c: amd-mp2: Unregister callback on adapter add failure
amd_mp2_register_cb() stores the platform I2C context in the MP2 PCI
driver's callback table before the adapter is registered. If
i2c_add_adapter() fails, probe returns and devres frees the context,
but the PCI driver can still dereference the stale pointer from its IRQ
and system-sleep callbacks.
Unregister the callback before returning the adapter registration error. |
| In the Linux kernel, the following vulnerability has been resolved:
ufs: core: tracing: Do not dereference pointers in TP_printk()
The trace events in drivers/ufs/core/ufs_trace.h were converted to take a
pointer to the hba structure as an argument for the tracepoint and then in
TP_printk() the printing of the dev_name from the ring buffer was
converted to using the dev dereferenced pointer from the hba saved
pointer.
This is not allowed as the TP_printk() is executed at the time the trace
event is read from /sys/kernel/tracing/trace file. That can happen
literally, seconds, minutes, hours, weeks, days, or even months later!
There is no guarantee that the hba pointer will still exist by the time it
is dereferenced when the "trace" file is read.
Instead, save the device name from the hba pointer at the time the
tracepoint is called and place it into the ring buffer event. Then the
TP_printk() can read the name directly from the ring buffer and remove the
possibility that it will read a freed pointer and crash the kernel.
This was detected when testing the trace event code that looks for
TP_printk() parameters doing illegal derferences[1]
[1] https://lore.kernel.org/all/[email protected]/ |
| Stomper 5e2741e is vulnerable to Use-After-Free. When a client sends multiple CONNECT frames on the same TCP connection, and subsequently another client (or a later connection) sends SEND frames to a destination previously subscribed on that connection, the broker may dereference a pointer to a StompStreamSocket object that has already been freed. This results in a heap use-after-free and process crash. Because the protocol does not authenticate or restrict such sequences by default. |
| Stomper 5e2741e is vulnerable to Use-After-Free. When a single client repeatedly issues SUBSCRIBE commands for the same destination over one connection and then closes that connection, the broker performs incorrect cleanup of its internal subscription structures. This results in a heap use-after-free during StompClient destruction, causing the broker process to crash. An unauthenticated client can exploit this to reliably trigger a denial of service. |
| A double-free vulnerability in the WatchGuard Fireware OS iked process allows a remote unauthenticated attacker to create a Denial of Service (DoS) condition in VPN processing by sending specially crafted network traffic. |
| In the Linux kernel, the following vulnerability has been resolved:
soc: xilinx: Shutdown and free rx mailbox channel
A mbox rx channel is requested using mbox_request_channel_byname() in
probe. In remove callback, the rx mailbox channel is cleaned up when the
rx_chan is NULL due to incorrect condition check. The mailbox channel is
not shutdown and it can receive messages even after the device removal.
This leads to use after free. Also the channel resources are not freed.
Fix this by checking the rx_chan correctly. |
| Missing privilege verification in the secure context cleanup handler in FreeRTOS-Kernel before 11.3.1 might allow local users to cause a use-after-free condition in secure-world memory via the SVC handler for secure context deallocation. To remediate this issue, users should upgrade to version 11.3.1 or later. |
| Software installed and run as a non-privileged user may conduct GPU system calls which cause GPU memory leaks and possible kernel heap corruption.
Scenario caused by memory free paths not maintaining state data of upgraded higher order allocations. This could cause memory leak or double free event. |
| Use after free in Accessibility in Google Chrome prior to 152.0.7977.65 allowed a remote attacker leveraging social engineering to execute arbitrary code outside the sandbox via UI Interaction. (Chromium security severity: High) |
| Use after free in Chromoting in Google Chrome on on Windows prior to 152.0.7977.65 allowed a remote attacker to execute arbitrary code outside the sandbox via crafted network traffic. (Chromium security severity: High) |
| In the Linux kernel, the following vulnerability has been resolved:
Input: ims-pcu - fix race condition in reset_device sysfs callback
The ims_pcu_reset_device() sysfs callback calls ims_pcu_execute_command()
without acquiring pcu->cmd_mutex. This can lead to data races and
corruption of the shared command buffer if triggered concurrently with
other commands.
Acquire pcu->cmd_mutex before calling ims_pcu_execute_command(). |
| Use after free in WebRTC in Google Chrome prior to 152.0.7977.65 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: High) |
| Use after free in Views in Google Chrome on on Mac prior to 152.0.7977.65 allowed a remote attacker to execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: Critical) |
| Use after free in ANGLE in Google Chrome prior to 152.0.7977.65 allowed a remote attacker to execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: High) |
| Use after free in Views in Google Chrome on on Mac prior to 152.0.7977.65 allowed a remote attacker to execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: Medium) |
