| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
ipv6: ioam: refresh hdr pointer before ioam6_event()
Reported by Sashiko:
In ipv6_hop_ioam(), the hdr pointer is initialized to point into the
skb's linear data buffer. Later, the code calls skb_ensure_writable(),
which might reallocate the buffer:
if (skb_ensure_writable(skb, optoff + 2 + hdr->opt_len))
goto drop;
/* Trace pointer may have changed */
trace = (struct ioam6_trace_hdr *)(skb_network_header(skb)
+ optoff + sizeof(*hdr));
ioam6_fill_trace_data(skb, ns, trace, true);
ioam6_event(IOAM6_EVENT_TRACE, dev_net(skb->dev),
GFP_ATOMIC, (void *)trace, hdr->opt_len - 2);
If the skb is cloned or lacks sufficient linear headroom,
skb_ensure_writable() will invoke pskb_expand_head(), which reallocates
the skb's data buffer and frees the old one, invalidating pointers to
it. While the code recalculates the trace pointer immediately after the
call to skb_ensure_writable(), it fails to recalculate the hdr pointer.
This patch fixes the above by recalculating the hdr pointer before
passing hdr->opt_len to ioam6_event(), so that we avoid any UaF. |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_exthdr: fix register tracking for F_PRESENT flag
nft_exthdr_init() passes user-controlled priv->len to
nft_parse_register_store(), which marks that many bytes in the
register bitmap as initialized. However, when NFT_EXTHDR_F_PRESENT
is set, the eval paths write only 1 byte (nft_reg_store8) or
4 bytes (*dest = 0 on TCP/DCCP error path). When len > 4,
registers beyond the first are never written, retaining
uninitialized stack data from nft_regs.
Bail out if userspace requests too much data when F_PRESENT is set. |
| In the Linux kernel, the following vulnerability has been resolved:
hwmon: (gigabyte_waterforce) Stop device IO before calling hid_hw_stop
Calling hid_hw_stop() does not stop the device IO.
This results in a race condition between hid_input_report() and the point
immediately following the execution of hid_device_io_start() within
the driver probe function. If the probe operation fails after "io start"
has been initiated, this race condition will result in a UAF vulnerability.
Fix the problem by calling hid_device_io_stop() before calling
hid_hw_stop(). |
| A flaw was found in acm-search-v2-rhel9. An attacker with administrative privileges on the hub cluster, specifically with patch access to the Search Custom Resource (CR), could exploit a vulnerability in the `Collector.ImageOverride` field. This allows the attacker to deploy an arbitrary container image across all managed clusters. The consequence is remote code execution (RCE), enabling the attacker to execute commands and potentially access sensitive information across the entire fleet of managed clusters. |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: synproxy: add mutex to guard hook reference counting
As the synproxy infrastructure register netfilter hooks on-demand when a
user adds the first iptables target or nftables expression, if done
concurrently they can race each other.
Introduce a mutex to serialize the refcount control blocks access from
both frontends. While a per namespace mutex might be more efficient, it
is not needed for target/expression like SYNPROXY. |
| In the Linux kernel, the following vulnerability has been resolved:
sched_ext: Avoid UAF in scx_root_enable_workfn() init failure path
In scx_root_enable_workfn(), put_task_struct(p) is called before scx_error()
dereferences p->comm and p->pid. If the iterator's reference is the last
drop, the task is freed synchronously and the deref becomes a UAF.
Move put_task_struct() past scx_error(). |
| Improper handling of overlap between protected memory ranges for some Intel(R) Xeon(R) 6 processors when using Intel(R) TDX within SMM may allow an escalation of privilege. SMM adversary with a privileged user combined with a high complexity attack may enable escalation of privilege. This result may potentially occur via local access when attack requirements are present with special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (high), integrity (high) and availability (none) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts. |
| In the Linux kernel, the following vulnerability has been resolved:
mac802154: hold an interface reference across the scan worker
mac802154_scan_worker() captures the scanning sub-interface under RCU
and then keeps dereferencing sdata->dev after rcu_read_unlock() and
outside the rtnl -- in the failure traces, in
mac802154_transmit_beacon_req() (skb->dev = sdata->dev), and in the
end_scan cleanup. Nothing keeps that netdev alive across the worker
iteration.
A concurrent DEL_INTERFACE or PHY removal can unregister the interface
once the worker drops the rtnl between its two drv_set_channel()
sections. unregister_netdevice() frees the netdev asynchronously from
netdev_run_todo() with the rtnl already dropped, so neither holding the
rtnl nor the per-PHY IEEE802154_IS_SCANNING flag prevents a stale worker
iteration from dereferencing the freed netdev -- a KASAN
slab-use-after-free, reachable by racing TRIGGER_SCAN against
DEL_INTERFACE (both CAP_NET_ADMIN).
Pin the netdev with netdev_hold() while the RCU read lock is still held,
and release it at every worker exit. |
| In the Linux kernel, the following vulnerability has been resolved:
iio: core: fix uninitialized data in debugfs
If *ppos is non-zero then simple_write_to_buffer() will not initialize
the start of buf[]. Non zero values for *ppos aren't going to work
anyway. Test for them at the start of the function and return -EINVAL. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/vc4: Shut down BO cache timer before teardown
The BO cache timer callback schedules time_work, and time_work can rearm
the timer through vc4_bo_cache_free_old().
vc4_bo_cache_destroy() deletes the timer and then cancels the work, which
does not break that cycle: the work being cancelled can rearm the timer,
and the timer then queues work again after teardown.
Use timer_shutdown_sync() instead, so the timer cannot be rearmed and the
cycle ends with cancel_work_sync(). |
| Use after free in Blink in Google Chrome prior to 151.0.7922.137 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High) |
| In the Linux kernel, the following vulnerability has been resolved:
ovpn: avoid putting unrelated P2P peer on socket release
ovpn_peer_release_p2p() is called when an OVPN UDP socket is being
destroyed. It checks the currently published P2P peer and releases it only
if that peer still uses the socket being destroyed.
A peer replacement can publish a new peer before the old UDP socket is
destroyed. When the old socket destruction path runs afterwards,
ovpn_peer_release_p2p() observes the new peer through ovpn->peer. Since the
new peer uses a different socket, the function takes the socket mismatch
branch.
That branch still calls ovpn_peer_put(peer). At this point, however, peer
is the currently published replacement peer, not the peer associated with
the socket being destroyed. Dropping its reference can free it while
ovpn->peer still points to it, leading to later use-after-free accesses
from the peer and socket cleanup paths.
KASAN reports this as a slab-use-after-free on the kmalloc-1k ovpn_peer
object. In the reproducer, the object is allocated from ovpn_peer_new() via
ovpn_nl_peer_new_doit(), and freed through ovpn_peer_release_rcu() from RCU
callback processing. Observed access sites include ovpn_peer_remove(),
ovpn_socket_release(), ovpn_nl_peer_del_notify(), and unlock_ovpn().
Fix this by returning from the socket mismatch branch without putting the
peer. |
| In the Linux kernel, the following vulnerability has been resolved:
hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop
Calling hid_hw_stop() does not stop the device IO.
This results in a race condition between hid_input_report() and the point
immediately following the execution of hid_device_io_start() within
the driver probe function. If the probe operation fails after "io start"
has been initiated, this race condition will result in a UAF vulnerability.
Fix the problem by calling hid_device_io_stop() before calling
hid_hw_stop(). |
| In the Linux kernel, the following vulnerability has been resolved:
usb: core: port: Deattach Type-C connector on component unbind
connector_unbind() is the mirror of connector_bind(), but it is missing
the symmetric call to typec_deattach() that connector_bind() makes via:
if (port_dev->child)
typec_attach(port_dev->connector, &port_dev->child->dev);
When a Thunderbolt dock is unplugged, two teardown paths race:
1. The component framework calls connector_unbind() first, which sets
port_dev->connector = NULL without calling typec_deattach(). This
leaves port->usb2_dev/port->usb3_dev in struct typec_port pointing at
the USB device that is about to be freed.
2. usb_disconnect() then calls typec_deattach(port_dev->connector, ...),
but port_dev->connector is already NULL, so the call is a no-op and
port->usb2_dev is never cleared.
3. Concurrently, UCSI detects a PD partner-disconnect event and calls
typec_unregister_partner(), which reads port->usb2_dev (now a dangling
pointer to freed memory) and passes it to typec_partner_unlink_device()
-> sysfs_remove_link() -> dev_name() on the freed device, corrupting
the typec/UCSI partner state.
This corruption leaves the Thunderbolt tunnel in an inconsistent state on
the next dock hot-plug. On affected hardware the dock's I225/igc NIC fails
to enumerate: AER fires a slot reset while the igc driver is still
initialising ("PCIe link lost"), and the subsequent igc_reset attempt hits
igc_rd32 on an already-detached device:
igc 0000:2e:00.0 eth0: PCIe link lost, device now detached
igc: Failed to read reg 0x0!
WARNING: CPU: 9 PID: 129 at drivers/net/ethernet/intel/igc/igc_main.c:7005
igc_rd32+0xa4/0xc0 [igc]
Call Trace:
igc_disable_pcie_master+0x16/0xa0 [igc]
igc_reset_hw_base+0x14/0x170 [igc]
igc_reset+0x63/0x110 [igc]
igc_io_slot_reset+0x9e/0xd0 [igc]
report_slot_reset+0x5d/0xc0
pcie_do_recovery+0x209/0x400
aer_isr_one_error_type+0x235/0x430
aer_isr+0x4e/0x80
irq_thread+0xf4/0x1f0
4. UCSI later handles the PD partner-disconnect and calls
typec_unregister_partner(), which still sees the stale port->usb2_dev
and tries to remove its sysfs link a second time:
kernfs: can not remove 'typec', no directory
WARNING: CPU: 6 PID: 55 at fs/kernfs/dir.c:1706 kernfs_remove_by_name_ns+0xe9/0xf0
Workqueue: events ucsi_handle_connector_change [typec_ucsi]
Call Trace:
sysfs_remove_link+0x19/0x50
typec_unregister_partner+0x6e/0x120 [typec]
ucsi_unregister_partner+0x107/0x150 [typec_ucsi]
ucsi_handle_connector_change+0x3ec/0x490 [typec_ucsi]
process_one_work+0x18e/0x3e0
worker_thread+0x2e3/0x420
kthread+0x10a/0x230
ret_from_fork+0x121/0x140
ret_from_fork_asm+0x1a/0x30
With worse timing the same stale pointer is dereferenced after the
backing memory is freed, turning the warning into a use-after-free.
Fix the asymmetry: call typec_deattach() before clearing
port_dev->connector, matching what connector_bind() does on the bind side.
typec_partner_deattach() is already protected by port->partner_link_lock,
so it serialises safely with the concurrent typec_unregister_partner() path. |
| In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Fix address space mismatch in kexec command line lookup
When searching the loaded segments for the "kexec" command line marker,
the kexec_load(2) path (file_mode == 0) passes the user-space segment
buffer straight to strncmp() through a bogus (char __user *) cast. This
dereferences a user pointer in kernel context, which is wrong and is
flagged by sparse:
arch/loongarch/kernel/machine_kexec.c:84:51: sparse: incorrect type in
argument 2 (different address spaces) @@ expected char const * @@ got
char [noderef] __user *
Here copy the marker-sized prefix of each segment into a small on-stack
buffer with copy_from_user() before comparing, and skip segments that
fault. The subsequent copy_from_user() that stages the full command line
into the safe area is left unchanged. |
| In Eclipse RDF4J, several XML parser entry points do not fully restrict XML External Entity (XXE) processing when parsing untrusted XML-based RDF data or query results, permitting DOCTYPE declarations, external entity references, and external DTD loading. This is due to an incomplete fix for CVE-2018-1000644: the earlier fix did not cover all parser entry points. The issue is resolved in RDF4J 5.3.2, which rejects or disables DOCTYPE declarations, external entities, and external DTD loading by default. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock
ieee80211_do_stop() removes AP_VLAN packets from the parent AP
ps->bc_buf while holding ps->bc_buf.lock with IRQs disabled. It then
calls ieee80211_free_txskb() before dropping the lock.
ieee80211_free_txskb() is not just a passive SKB release. For SKBs with
TX status state it can report a dropped frame through cfg80211/nl80211,
and that path can reach netlink tap transmit. This is the same reason
the pending queue cleanup in ieee80211_do_stop() already unlinks SKBs
under the queue lock and frees them after IRQ state is restored.
The buggy scenario involves two paths, with each column showing the
order within that path:
AP_VLAN management TX: AP_VLAN stop:
1. attach ACK-status state 1. clear the running state
2. queue a multicast SKB on 2. take ps->bc_buf.lock with IRQs
parent ps->bc_buf disabled
3. unlink the AP_VLAN SKB
4. call ieee80211_free_txskb()
Unlink matching AP_VLAN SKBs from ps->bc_buf under the existing lock,
but move them to a local free queue. Drop the lock and restore IRQ state
before calling ieee80211_free_txskb().
WARNING: kernel/softirq.c:430 at __local_bh_enable_ip |
| Untrusted Pointer Dereference in ASUS GPU Tweak III, GPUTweakII, AI Suite3, and VGAdll: An IOCTL vulnerability allows a local attacker to write a specific value to an arbitrary memory address, potentially leading to privilege escalation.
Refer to the '
Security Update for ASUS GPU Tweak III, GPU Tweak II, AI Suite 3, and Armoury Crate Security Bulletin ' section on the ASUS Security Advisory for more information. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: initialize SDIO data work before cleanup
brcmf_sdio_probe() stores the newly allocated bus in sdiodev->bus before
allocating the ordered workqueue. If that allocation fails, the function
jumps to fail and calls brcmf_sdio_remove().
brcmf_sdio_remove() unconditionally cancels bus->datawork. Initialize the
work item before the first failure path that can reach brcmf_sdio_remove(),
so the cleanup path always observes a valid work object.
This issue was found by our static analysis tool and then confirmed by
manual review of the probe error path and the remove-time work drain. The
problem pattern is an early setup failure that reaches a cleanup helper
which cancels an embedded work item before its initializer has run.
A QEMU PoC forced alloc_ordered_workqueue() to fail at the same point in
brcmf_sdio_probe(), before INIT_WORK(&bus->datawork) is reached. The
resulting fail path calls brcmf_sdio_remove(), and DEBUG_OBJECTS reports
the invalid work drain with brcmf_sdio_probe() and brcmf_sdio_remove() in
the stack. |
| In the Linux kernel, the following vulnerability has been resolved:
mtd: virt_concat: fix use-after-free in mtd_virt_concat_destroy()
mtd_concat_destroy() frees item->concat so calling
mtd_virt_concat_put_mtd_devices(item->concat) after that leads to a
use-after-free.
Fix it by moving mtd_virt_concat_put_mtd_devices() before
mtd_concat_destroy(). |
