| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Use after free in Chromoting in Google Chrome on Windows prior to 148.0.7778.96 allowed a local attacker to perform OS-level privilege escalation via a malicious file. (Chromium security severity: High) |
| Use after free in PresentationAPI in Google Chrome prior to 148.0.7778.96 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High) |
| Use after free in CSS in Google Chrome prior to 148.0.7778.96 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: Medium) |
| Use after free in V8 in Google Chrome prior to 148.0.7778.96 allowed an attacker who convinced a user to install a malicious extension to execute arbitrary code inside a sandbox via a crafted Chrome Extension. (Chromium security severity: Medium) |
| Use after free in Navigation in Google Chrome prior to 148.0.7778.96 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Medium) |
| Use after free in TopChrome in Google Chrome prior to 148.0.7778.96 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Medium) |
| Use after free in Blink in Google Chrome prior to 148.0.7778.96 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: Medium) |
| Use after free in DevTools in Google Chrome prior to 148.0.7778.96 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Medium) |
| Use after free in Views in Google Chrome prior to 148.0.7778.96 allowed an attacker who convinced a user to install a malicious extension to execute arbitrary code via a crafted Chrome Extension. (Chromium security severity: Medium) |
| Use after free in GPU in Google Chrome prior to 148.0.7778.96 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Medium) |
| Use after free in WebAudio in Google Chrome prior to 148.0.7778.96 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: Medium) |
| Use after free in ANGLE in Google Chrome on Mac prior to 148.0.7778.96 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High) |
| Use after free in Chromoting in Google Chrome on Linux prior to 148.0.7778.96 allowed a remote attacker to execute arbitrary code via malicious network traffic. (Chromium security severity: Critical) |
| Use after free in ReadingMode in Google Chrome prior to 148.0.7778.96 allowed a remote attacker who had compromised the renderer process to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: Medium) |
| Use after free in WebRTC in Google Chrome prior to 148.0.7778.96 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: Medium) |
| Use after free in UI in Google Chrome prior to 148.0.7778.96 allowed a remote attacker who had compromised the renderer process to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: Medium) |
| A vulnerability was found in ckolivas lrzip up to 0.651. This impacts the function lzma_decompress_buf of the file stream.c. Performing a manipulation results in use after free. Attacking locally is a requirement. The exploit has been made public and could be used. The project was informed of the problem early through an issue report but has not responded yet. |
| In the Linux kernel, the following vulnerability has been resolved:
xfs: save ailp before dropping the AIL lock in push callbacks
In xfs_inode_item_push() and xfs_qm_dquot_logitem_push(), the AIL lock
is dropped to perform buffer IO. Once the cluster buffer no longer
protects the log item from reclaim, the log item may be freed by
background reclaim or the dquot shrinker. The subsequent spin_lock()
call dereferences lip->li_ailp, which is a use-after-free.
Fix this by saving the ailp pointer in a local variable while the AIL
lock is held and the log item is guaranteed to be valid. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: virt_wifi: remove SET_NETDEV_DEV to avoid use-after-free
Currently we execute `SET_NETDEV_DEV(dev, &priv->lowerdev->dev)` for
the virt_wifi net devices. However, unregistering a virt_wifi device in
netdev_run_todo() can happen together with the device referenced by
SET_NETDEV_DEV().
It can result in use-after-free during the ethtool operations performed
on a virt_wifi device that is currently being unregistered. Such a net
device can have the `dev.parent` field pointing to the freed memory,
but ethnl_ops_begin() calls `pm_runtime_get_sync(dev->dev.parent)`.
Let's remove SET_NETDEV_DEV for virt_wifi to avoid bugs like this:
==================================================================
BUG: KASAN: slab-use-after-free in __pm_runtime_resume+0xe2/0xf0
Read of size 2 at addr ffff88810cfc46f8 by task pm/606
Call Trace:
<TASK>
dump_stack_lvl+0x4d/0x70
print_report+0x170/0x4f3
? __pfx__raw_spin_lock_irqsave+0x10/0x10
kasan_report+0xda/0x110
? __pm_runtime_resume+0xe2/0xf0
? __pm_runtime_resume+0xe2/0xf0
__pm_runtime_resume+0xe2/0xf0
ethnl_ops_begin+0x49/0x270
ethnl_set_features+0x23c/0xab0
? __pfx_ethnl_set_features+0x10/0x10
? kvm_sched_clock_read+0x11/0x20
? local_clock_noinstr+0xf/0xf0
? local_clock+0x10/0x30
? kasan_save_track+0x25/0x60
? __kasan_kmalloc+0x7f/0x90
? genl_family_rcv_msg_attrs_parse.isra.0+0x150/0x2c0
genl_family_rcv_msg_doit+0x1e7/0x2c0
? __pfx_genl_family_rcv_msg_doit+0x10/0x10
? __pfx_cred_has_capability.isra.0+0x10/0x10
? stack_trace_save+0x8e/0xc0
genl_rcv_msg+0x411/0x660
? __pfx_genl_rcv_msg+0x10/0x10
? __pfx_ethnl_set_features+0x10/0x10
netlink_rcv_skb+0x121/0x380
? __pfx_genl_rcv_msg+0x10/0x10
? __pfx_netlink_rcv_skb+0x10/0x10
? __pfx_down_read+0x10/0x10
genl_rcv+0x23/0x30
netlink_unicast+0x60f/0x830
? __pfx_netlink_unicast+0x10/0x10
? __pfx___alloc_skb+0x10/0x10
netlink_sendmsg+0x6ea/0xbc0
? __pfx_netlink_sendmsg+0x10/0x10
? __futex_queue+0x10b/0x1f0
____sys_sendmsg+0x7a2/0x950
? copy_msghdr_from_user+0x26b/0x430
? __pfx_____sys_sendmsg+0x10/0x10
? __pfx_copy_msghdr_from_user+0x10/0x10
___sys_sendmsg+0xf8/0x180
? __pfx____sys_sendmsg+0x10/0x10
? __pfx_futex_wait+0x10/0x10
? fdget+0x2e4/0x4a0
__sys_sendmsg+0x11f/0x1c0
? __pfx___sys_sendmsg+0x10/0x10
do_syscall_64+0xe2/0x570
? exc_page_fault+0x66/0xb0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
</TASK>
This fix may be combined with another one in the ethtool subsystem:
https://lore.kernel.org/all/[email protected]/T/#u |
| In the Linux kernel, the following vulnerability has been resolved:
writeback: Fix use after free in inode_switch_wbs_work_fn()
inode_switch_wbs_work_fn() has a loop like:
wb_get(new_wb);
while (1) {
list = llist_del_all(&new_wb->switch_wbs_ctxs);
/* Nothing to do? */
if (!list)
break;
... process the items ...
}
Now adding of items to the list looks like:
wb_queue_isw()
if (llist_add(&isw->list, &wb->switch_wbs_ctxs))
queue_work(isw_wq, &wb->switch_work);
Because inode_switch_wbs_work_fn() loops when processing isw items, it
can happen that wb->switch_work is pending while wb->switch_wbs_ctxs is
empty. This is a problem because in that case wb can get freed (no isw
items -> no wb reference) while the work is still pending causing
use-after-free issues.
We cannot just fix this by cancelling work when freeing wb because that
could still trigger problematic 0 -> 1 transitions on wb refcount due to
wb_get() in inode_switch_wbs_work_fn(). It could be all handled with
more careful code but that seems unnecessarily complex so let's avoid
that until it is proven that the looping actually brings practical
benefit. Just remove the loop from inode_switch_wbs_work_fn() instead.
That way when wb_queue_isw() queues work, we are guaranteed we have
added the first item to wb->switch_wbs_ctxs and nobody is going to
remove it (and drop the wb reference it holds) until the queued work
runs. |
