| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix root leak if its reloc root is unexpected in merge_reloc_roots()
If we have an unexpected reloc_root for our root, we jump to the out label
but never drop the reference we obtained for root, resulting in a leak.
Add a missing btrfs_put_root() call. |
| A security vulnerability has been detected in NellyW8 MCP4EDA 1.0.0. Affected by this vulnerability is an unknown functionality of the component run_openlane/view_waveform. The manipulation of the argument design_name/vcd_file leads to command injection. Local access is required to approach this attack. The project was informed of the problem early through an issue report but has not responded yet. |
| A security flaw has been discovered in adolfosalasgomez3011 slidev-builder-mcp 2.1.0. This affects the function generateChart of the file src/tools/generateAssets.ts of the component generateAssets Tool. Performing a manipulation of the argument outputDir results in command injection. The attack is only possible with local access. The project was informed of the problem early through an issue report but has not responded yet. |
| A vulnerability was found in INQUIRELAB mcp-bridge-api up to b30a82aa1d1d1139e0de846c41c8aadee6e06114. The impacted element is an unknown function of the file mcp-bridge.js of the component Servers Endpoint. Performing a manipulation of the argument command/args results in command injection. It is possible to initiate the attack remotely. This product is using a rolling release to provide continious delivery. Therefore, no version details for affected nor updated releases are available. The pull request to fix this issue awaits acceptance. |
| Klever-Go is the Go implementation of the Klever blockchain protocol. Versions from 1.7.14 through 1.7.17 are vulnerable to a remotely triggerable denial of service. Both REST APIs are started with the Gin Engine.Run convenience method, which serves requests through Go's default HTTP server with no ReadHeaderTimeout, ReadTimeout, or MaxHeaderBytes configured. As a result, incoming connections that never complete their request headers are held open indefinitely. When a REST listener is reachable beyond localhost through the documented all-interface bind or a Docker port-publish deployment, a single unauthenticated client can open many slow-header connections and hold them open until server file descriptors are exhausted, preventing the API from accepting new connections. This renders the REST API unavailable to legitimate clients. This issue is fixed in version 1.7.18. |
| In the Linux kernel, the following vulnerability has been resolved:
staging: vme_user: fix location monitor leak in tsi148 bridge
tsi148_probe() allocates a location monitor resource and links it into
tsi148_bridge->lm_resources. The probe error path frees this list, but
tsi148_remove() only frees the dma, slave and master resource lists, so
the location monitor resource is leaked on device unbind or module
unload.
Free the lm_resources list in tsi148_remove() as well, before
tsi148_bridge is freed. |
| In the Linux kernel, the following vulnerability has been resolved:
HID: wacom: use GFP_ATOMIC in wacom_wac_queue_flush()
wacom_wac_queue_flush() is called via the .raw_event callback
(wacom_raw_event → wacom_wac_pen_serial_enforce → wacom_wac_queue_flush).
For USB HID devices, this callback is invoked from hid_irq_in(), which
is a URB completion handler running in atomic context. Using GFP_KERNEL
in this path can sleep, leading to a "scheduling while atomic" bug.
Use GFP_ATOMIC instead. The existing code already handles allocation
failure by skipping the fifo entry and continuing. |
| A security vulnerability has been detected in HKUDS nanobot up to 0.2.1. Impacted is the function ExecTool._guard_command/ExecTool._spawn of the file nanobot/agent/tools/shell.py of the component Shell Allowlist Handler. Such manipulation leads to os command injection. The attack can be executed remotely. The exploit has been disclosed publicly and may be used. Upgrading to version 0.3.0 is recommended to address this issue. The name of the patch is 4562. It is advisable to upgrade the affected component. Multiple issues were reported to the project. They reacted with a high level of professionalism and kindness: "These five reports are variants of the same root cause: validation of shell commands containing multiple segments, wrappers, comments, or chained commands. The issue was fixed by validating every executable shell segment against the configured allowlist". |
| In the Linux kernel, the following vulnerability has been resolved:
IB/mad: Drop unmatched RMPP responses before reassembly
Kernel-handled RMPP receive processing starts reassembly for active
DATA responses before the response is matched to an outstanding send.
The normal match happens later, after ib_process_rmpp_recv_wc() has
either assembled a complete message or consumed the segment.
That ordering lets an unsolicited response that routes to a kernel
RMPP agent by the high TID bits allocate or extend RMPP receive state
before the full TID and source address are checked against a real
request. A reordered burst can therefore reach the receive-side
insertion path even though the response would not match any send.
For kernel-handled RMPP DATA responses, require the existing
ib_find_send_mad() match before entering RMPP reassembly. The matcher
already checks the full TID, management class and source address/GID
against the agent wait, backlog and in-flight send lists. If there is
no match, drop the response without creating RMPP state.
This leaves the RMPP window behavior unchanged and only rejects
responses that have no corresponding request. |
| In the Linux kernel, the following vulnerability has been resolved:
xfrm: clear mode callbacks after failed mode setup
xfrm_state_gc_task can run long after a failed IPTFS state setup. In the
reproduced case, __xfrm_init_state() cached x->mode_cbs, IPTFS setup
returned -ENOMEM before publishing mode_data, and the temporary module
reference from xfrm_get_mode_cbs() was dropped immediately. The dead state
then kept x->mode_cbs until deferred GC ran after xfrm_iptfs had been
unloaded.
Clear x->mode_cbs when mode init or clone fails before publishing
mode_data. Those states never installed mode-specific state or the
long-term IPTFS module pin, so deferred GC has nothing mode-specific to
destroy and must not retain a callback table pointer past the temporary
lookup reference.
The buggy scenario involves two paths, with each column showing the order
within that path:
failed setup path:
1. cache x->mode_cbs
2. mode setup fails before mode_data
3. drop the temporary module ref
4. dead state keeps x->mode_cbs cached
GC/unload path:
1. xfrm_state_put() queues GC work
2. xfrm_iptfs unloads later
3. xfrm_state_gc_task runs
4. GC dereferences stale x->mode_cbs
This also covers the failed clone path where clone_state() returns before
publishing mode_data.
Validation reproduced this kernel report:
Kernel panic - not syncing: Fatal exception
CONFIG_FAULT_INJECTION_STACKTRACE_FILTER=y
failslab_stacktrace_filter matched xfrm_iptfs frames
ack_error=-12
FAULT_INJECTION: forcing a failure
BUG: unable to handle page fault
Workqueue: events xfrm_state_gc_task
RIP: xfrm_state_gc_task+0x142/0x650
Modules linked in: esp4_offload xfrm_user [last unloaded: xfrm_iptfs]
Kernel panic - not syncing: Fatal exception |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: nl80211: free RNR data on MBSSID mismatch
nl80211_parse_beacon() rejects EMA RNR data when there are fewer RNR
entries than MBSSID entries.
The rejected RNR allocation has not been attached to the beacon data yet,
so free it before returning the error. |
| `Element.findall()` and fully-consumed `Element.iterfind()` exhibit `O(n^2)` time complexity when using XPath index predicates (e.g. `[1]`, `[last()]`, `[last()-N]`) on XML documents with many same-tag siblings. `Element.find()` is only affected when the first match is near the end of the sibling list, such as with `[last()]` or `[last()-N]`; `.//item[1]` short-circuits after the first match. |
| A flaw was found in cluster-backup-operator. A namespace administrator in open-cluster-management-backup can create a Restore Custom Resource (CR) with malicious hooks. These hooks allow the execution of arbitrary commands within any matching restored pod, leading to the exfiltration of ServiceAccount tokens. This bypasses normal access controls, granting the attacker unauthorized execution access to pods and their associated Service Accounts. |
| In the Linux kernel, the following vulnerability has been resolved:
dpaa2-eth: put MAC endpoint device on disconnect
fsl_mc_get_endpoint() returns the MAC endpoint device with a reference
taken through device_find_child(). The Ethernet connect path stores that
device in mac->mc_dev and keeps it for the lifetime of the connected MAC
object.
However, the disconnect path only disconnects and closes the MAC before
freeing the dpaa2_mac object. It does not drop the endpoint device
reference stored in mac->mc_dev, so every successful connect leaks that
device reference when the MAC is later disconnected.
Drop the endpoint device reference after closing the MAC and before
freeing the dpaa2_mac object. |
| Broadcast control frames can disconnect multiple aircraft simultaneously leading to delayed clearances and air traffic controller overload. This type of attack can be carried out remotely over radio frequency. |
| Unnumbered Disconnect (U DISC) and malformed Aviation Very High Frequency Link Control frames can terminate sessions and lead to a loss of CPDLC functions requiring a reversion to voice communication and increased controller workload. This type of attack can be carried out remotely over radio frequency. |
| A vulnerability was detected in NightTrek Supabase-MCP cc994ab2d2a36b0af6ee7c7f3e6ce8e08cda2170/db03237d92f7dc2f0da0d70a87dba84ebcde5b66. Affected by this issue is some unknown functionality of the component generate_types. The manipulation of the argument schema results in command injection. The attack needs to be approached locally. The project was informed of the problem early through an issue report but has not responded yet. |
| A security flaw has been discovered in Shenzhen Aitemi M300 Wi-Fi Repeater r0-ea7890a. Impacted is the function sprintf of the file /protocol.csp?fname=net&opt=smacfilter_conf&function=set&act=add&name=test&enable=1. Performing a manipulation of the argument enable/name/mac results in command injection. The attack may be initiated remotely. The exploit has been released to the public and may be used for attacks. |
| In the Linux kernel, the following vulnerability has been resolved:
net: hsr: fix memory leak on slave unregistration by removing synced VLANs
When an HSR master device is brought UP, it auto-adds VLAN 0 via
vlan_vid0_add(), which propagates VID 0 to its slave devices (slave A and B).
If a slave device is later unregistered while HSR is active (e.g., during
netns cleanup or interface destruction), hsr_del_port() is called to
detach the slave port from the HSR master. However, hsr_del_port() currently
does not delete the VLAN IDs that were synced to the slave device by HSR.
As a result, the slave device retains a refcount on VID 0 (and any other
synced VLANs). When the slave device is destroyed, its vlan_info /
vlan_vid_info structure remains allocated, leading to a memory leak.
Fix this by calling vlan_vids_del_by_dev(port->dev, master->dev) in
hsr_del_port() before unlinking slave A or slave B ports, matching the
propagation logic in hsr_ndo_vlan_rx_add_vid() / hsr_ndo_vlan_rx_kill_vid()
and the cleanup behavior in bonding and team drivers. |
| In the Linux kernel, the following vulnerability has been resolved:
gve: fix Rx queue stall on alloc failure
When the system is under extreme memory pressure, page allocations can
fail during the Rx buffer refill loop. If the number of buffers posted
to hardware falls below a critical low threshold and the refill loop
exits due to allocation failures, the queue can stall:
1. The device drops incoming packets because there are no descriptors.
2. Since no packets are processed, no Rx completions are generated.
3. Because no completions occur, NAPI is never scheduled, preventing
the refill loop from running again even after memory is freed.
This results in a permanent queue stall.
Resolve this by introducing a starvation recovery timer for each Rx queue.
If the number of buffers posted to hardware falls below a critical low
threshold, start a timer to periodically reschedule NAPI. Once NAPI runs
and successfully refills the queue above the threshold, the timer is
not rescheduled.
The threshold is set to 32 because a single maximum-sized Receive Segment
Coalescing (RSC) packet can consume up to 19 descriptors in the Rx path.
Lower thresholds (such as 8 or 16) would be insufficient to process a
complete maximum-sized RSC packet, risking packet drops or unexpected
hardware behavior under memory pressure. Setting the threshold to 32
guarantees a safe margin to handle at least one full RSC packet. |