| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In chppWifiRangingEventNotification of clients/wifi.c, there is a possible Heap Buffer Overflow due to a logic error in the code. This could lead to remote (proximal/adjacent) escalation of privilege with execution privileges needed. User interaction is for exploitation. |
| In multiple locations, there is a possible out-of-bounds write due to an incorrect bounds check. This could lead to remote escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In multiple locations, there is a possible permission bypass due to a logic error in the code. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. |
| In NotifySipResponse of SessionEx.cpp, there is a possible way to corrupt memory via a dangling connection pointer in the pending response queue due to a use after free. This could lead to remote escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In cpm_mbox_power_ctrl_sswrp of cpm_mbox.c, there is a possible permission bypass due to a precondition check failure. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. |
| In authenticate of verify_image, there is a possible Signature verification logic bypass due to a logic error in the code. This could lead to local escalation of privilege with execution privileges needed. User interaction is for exploitation. |
| In tipc_dev_probe of tipc_virtio_dev.c, there is a possible way to corrupt memory via an off-by-one cleanup loop on probe failure due to a logic error. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. |
| In EncodeLastScanBufferElement of data_manager.cc, there is a possible out-of-bounds write due to a logic error in the code. This could lead to remote escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In edgetpu_group_clear_responses of edgetpu_group.c, there is a possible Use After Free due to a logic error in the code. This could lead to local escalation of privilege with execution privileges needed. User interaction is for exploitation. |
| In smmu_unmap_visit_leaf of arm-smmu-v3.c, there is a possible way to release active direct memory access page references during unmapping due to a logic error. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. |
| In smmu_detach_dev of private/google-modules/iommu/arm-smmu-v3/drivers/iommu/arm/arm-smmu-v3/pkvm/arm-smmu-v3.c, there is a possible Use After Free due to a logic error in the code. This could lead to local escalation of privilege with User execution privileges needed. User interaction is not needed for exploitation. |
| In port_shutdown of ipc.c, there is a possible Use After Free due to a race condition. This could lead to local escalation of privilege with execution privileges needed. User interaction is for exploitation. |
| Privilege escalation in the Nimbus Desktop Client component. This vulnerability was fixed in Firefox 160, Firefox ESR 153.7, Thunderbird 160, and Thunderbird 153.7. |
| Privilege escalation in the DOM: Navigation component. This vulnerability was fixed in Firefox 160, Firefox ESR 153.7, Thunderbird 160, and Thunderbird 153.7. |
| In multiple locations, there is a possible way to bypass key authorization policies during wrapped key import due to a logic error. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In the Linux kernel, the following vulnerability has been resolved:
inet: reject unhashed sockets during established lookups
TCP established ehash lookups are lockless. The socket caches involved
use SLAB_TYPESAFE_BY_RCU, so memory can be reused before an RCU reader
that retained its old address has finished.
After a tuple match, __inet_lookup_established() and
__inet6_lookup_established() acquire a reference and repeat the tuple
check. They do not check whether the new object is hashed. If the
address is reused for a socket with the same tuple, the lookup can
acquire a reference to the new object and return it while its nulls node
is unhashed.
A PoC that drives reuse with a SYN cookie request socket reproduced the
crash. The new request socket is unhashed and has a NULL rsk_listener.
A lookup that had loaded the address of the old request socket acquired
the reference published by tcp_get_cookie_sock() and returned the new
object. tcp_v4_rcv() then read sk_state through the NULL listener.
The resulting crash was:
BUG: kernel NULL pointer dereference, address: 0000000000000012
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
...
Oops: Oops: 0000 [#1] SMP NOPTI
CPU: 4 UID: 0 PID: 0 Comm: swapper/4 Not tainted 7.3.0-00591-g0e135910deec #1 PREEMPT(lazy)
...
RIP: 0010:tcp_v4_rcv+0x44e/0x1280
...
R10: 0000000000000001 R11: 00000000024ca8c0 R12: 0000000000000000
...
CR2: 0000000000000012 CR3: 0000000103d50004 CR4: 0000000000770ef0
...
Call Trace:
<IRQ>
? raw_local_deliver+0xae/0x240
ip_protocol_deliver_rcu+0x2d/0x180
ip_local_deliver_finish+0x84/0x100
ip_sublist_rcv_finish+0x5f/0x70
ip_sublist_rcv+0x12a/0x1d0
ip_list_rcv+0xfd/0x130
__netif_receive_skb_list_core+0x223/0x250
netif_receive_skb_list_internal+0x1d2/0x2c0
? try_fill_recv+0x39/0x7b0
napi_complete_done+0x74/0x170
virtnet_poll+0x445/0x600
__napi_poll+0x27/0x1e0
net_rx_action+0x2fe/0x3b0
handle_softirqs+0xc2/0x2c0
__irq_exit_rcu+0x74/0xd0
common_interrupt+0x7f/0x90
</IRQ>
...
Kernel panic - not syncing: Fatal exception in interrupt
After taking a reference, check whether the nulls node is unhashed in
both IPv4 and IPv6 established lookups. If it is unhashed or the tuple
no longer matches, drop the reference and restart the lookup.
Lookups racing with the TIME_WAIT hashdance, or with a request being
replaced by its child, now restart and find the new socket instead of
returning the old one.
Request sockets that were never inserted into ehash can have a nonzero
refcount, and a stale lookup can hold a transient reference. Therefore,
when SYN cookie, Fast Open, and request migration paths fail after
setting a nonzero refcount, release the references held by those paths
with reqsk_put() instead of freeing the request directly. |
| In the Linux kernel, the following vulnerability has been resolved:
xen-blkback: Avoid UAF when reading I/O statistics
Reading I/O statistics via sysfs concurrently with tearing down a
frontend device might result in UAF or a NULL dereference, as the
reading of the statistics data is not synchronized with freeing the
data.
Use a rwlock for synchronizing.
This is XSA-528 / CVE-2026-100082 |
| In the Linux kernel, the following vulnerability has been resolved:
xen-netback: defer xenvif_mcast_addr_list_free()
In order for the function to legitimately avoid locking/RCU, it needs to
run after all TX/RX processing has finished/stopped: Lookups happen from
xenvif_start_xmit(), while adds/removes happen from xenvif_tx_action()
(called out of xenvif_poll()).
Move the call out of xenvif_disconnect_data() (the call to the function
from connect()'s error path doesn't require any cleaning up there), and
put it past the synchronization point in backend_disconnect().
This is XSA-527 / CVE-2026-100081. |
| In the Linux kernel, the following vulnerability has been resolved:
xen-netback: Fix UAF when reading statistics data
The network statistic data in the driver is protected by RCU.
Unfortunately when tearing down the queues after an error during
connecting to the frontend (e.g. due to illegal Xenstore data filled
in by the guest), the statistic data is being freed without
synchronizing the RCU state. In case the data is being read via sysfs
in this phase, access to already freed memory or memory being in new
use is possible.
Fix that by calling synchronize_net() before freeing the queue data.
This is XSA-526 / CVE-2026-100080 |
| zlib 1.2.11 through 1.3.2 contains a heap buffer overflow: after an underlying write() fails, gz_write() returns without resetting strm.next_in, leaving it pointed at the caller's buffer. A later gz* write call then derives a position from the stale pointer and writes past a heap allocation; any write() failure reaches it, including EPIPE on a blocking descriptor, and in versions before 1.3.1.2 the failed write must be followed by a gzclearerr() call. |
