| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Roo Code through 3.54.0 contains a command approval bypass vulnerability that allows attackers to run denied shell commands because parseCommandLine() treats ${ command; } substitutions as parameter expansions. Attackers using indirect prompt injection can embed denied commands inside an allowlisted command like echo to execute them without user approval on bash 5.3+ or ksh93. |
| In the Linux kernel, the following vulnerability has been resolved:
power: sequencing: fix NULL-pointer dereference in pwrseq_device_register()
If dev_set_name() fails in pwrseq_device_register(), we jump to the
err_put_pwrseq label before initializing pwrseq->targets.
pwrseq_release() will try to iterate over targets unconditionally and
subsequently dereference an invalid pointer. Move the call to
dev_set_name() after the list head is initialized. |
| In the Linux kernel, the following vulnerability has been resolved:
net: iptunnel: fix stale transport header during tunnel decapsulation
Syzbot reported a crash in qdisc_pkt_len_segs_init() caused by a stale
transport_header offset after tunnel decapsulation.
BUG: unable to handle page fault for address: ffffed102091a42e
Oops: Oops: 0000 [#1] SMP KASAN NOPTI
CPU: 0 UID: 0 PID: 340 Comm: qdisc_uaf_repro Not tainted 7.2.0-rc4-00061-g248951ddc14d #256 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:__asan_load2
<IRQ>
qdisc_pkt_len_segs_init (net/core/dev.c:4145)
__dev_queue_xmit (net/core/dev.c:4787)
br_dev_queue_push_xmit (net/bridge/br_forward.c:53)
br_handle_frame_finish (net/bridge/br_input.c:229)
br_handle_frame (net/bridge/br_input.c:315)
__netif_receive_skb_core.constprop.0 (net/core/dev.c:6099)
__netif_receive_skb_list_core (net/core/dev.c:6287)
netif_receive_skb_list_internal (net/core/dev.c:6445)
napi_complete_done (net/core/dev.c:6813)
gro_cell_poll (net/core/gro_cells.c:74)
__napi_poll (net/core/dev.c:7735)
net_rx_action (net/core/dev.c:7798 net/core/dev.c:7955)
handle_softirqs (kernel/softirq.c:622)
do_softirq (kernel/softirq.c:523 kernel/softirq.c:510 )
__local_bh_enable_ip (kernel/softirq.c:450)
tun_get_user (drivers/net/tun.c:1986 (discriminator 1))
tun_chr_write_iter (drivers/net/tun.c:2032)
The issue is completely latent until qdisc read transport header in
commit 7fb4c1967011 ("net: pull headers in qdisc_pkt_len_segs_init()").
The crash requires four conditions to line up:
1. The incoming packet is encapsulated and carries GSO metadata. The outer
transport header offset is stored in skb->transport_header while the
packet is still in the outer tunnel context.
2. The tunnel receiver strips the outer headers. skb->data is advanced to
the inner frame, but skb->transport_header is left pointing to the
now-removed outer L4 header, so it becomes a negative offset relative to
the new data.
3. The inner frame is not delivered to the local IP stack. Instead, it
is forwarded at L2 by a bridge or HSR, so ip_rcv_core() never runs and
the transport header is not reset to the inner L4 offset.
4. The forwarding path calls __dev_queue_xmit(), which enters
qdisc_pkt_len_segs_init(). That function computes the GSO header length
from skb_transport_offset(skb). Because the offset is negative, the
unsigned cast overflows and pskb_may_pull(skb, hdr_len +
sizeof(struct tcphdr)) reads past the end of the skb, triggering a
KASAN fault or page fault.
The issue specifically requires GSO packets (shinfo->gso_size != 0), which
are processed/aggregated through gro_cells. Fix this by clearing
transport_header to the ~0U sentinel in gro_cell for all tunnnel driver.
GTP does not support GRO/GSO, drop the evil GSO packets in GTP directly. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/x86: x86-android-tablets: hold device reference for secondary fwnode teardown
In gpio_secondary_fwnode_init(), acpi_bus_find_device_by_name() returns a
device reference, but the local dev variable is declared with
__free(put_device), dropping the reference at the end of each iteration.
Meanwhile, devm_add_action_or_reset() saves the dev pointer for
gpio_secondary_unset() without incrementing its reference count, which
could lead to a use-after-free during driver teardown if the device is
released in the interim.
Acquire an explicit device reference with get_device() when registering
the devres action, and drop it with put_device() inside
gpio_secondary_unset(). |
| In the Linux kernel, the following vulnerability has been resolved:
net: ipv4: Fix UDP length overflow with PMTU discover and big MTU
This commit bounds cork->base.fragsize to IP_MAX_MTU to avoid a
possible overflow of UDP length that triggers a WARN in
udp_set_len_short when setsockopt IP_MTU_DISCOVER is set to
IP_PMTUDISC_PROBE, and a large packet is sent over a netdev with an
unusually large MTU.
Steps to reproduce:
1. Set device MTU bigger than IP_MAX_MTU + 20. cork->base.fragsize will
be set to that MTU in ip_setup_cork.
2. Set IP_MTU_DISCOVER to IP_PMTUDISC_PROBE. It lets maxnonfragsize be
set to device MTU (cork->fragsize) in __ip_append_data, rather than
to IP_MAX_MTU.
3. Send 65528 bytes of payload (+8 bytes of UDP header, +20 bytes of
IPv4 header). Device MTU allows it (it's only one byte bigger than
IP_MAX_MTU + IPv4 header, and the device MTU is bigger than that).
4. The UDP length in the built packet is 65536, which overflows the
16-bit length field and triggers the WARN in udp_set_len_short.
Note: IP_PMTUDISC_DO with IPv4 is safe, because ip_dst_mtu_maybe_forward
always clamps at IP_MAX_MTU, unlike ip6_dst_mtu_maybe_forward.
The Fixes tag points at the first commit where I could reproduce the
overflow with IPv4 and IP_PMTUDISC_PROBE. |
| Deserialization of untrusted data vulnerability in Ministry of Justice General Directorate of Information Technology UYAP Document Editor on Windows and Linux and Ministry of Justice General Directorate of Information Technology UYAP Document Editor on MacOS allows Object Injection.
This issue affects UYAP Document Editor: before 5.4.20; UYAP Document Editor: before 5.4.21. |
| Improper neutralization of special elements used in an OS command ('OS command injection') vulnerability in Ministry of Justice General Directorate of Information Technology UYAP Document Editor on Windows and Linux and Ministry of Justice General Directorate of Information Technology UYAP Document Editor on iOS allows OS Command Injection.
This issue affects UYAP Document Editor: before 5.4.20; UYAP Document Editor: before 5.4.21. |
| Frappe ERPNext before 15.111.0 and 16.x before 16.22.0 contains a privilege escalation vulnerability in a record-creation endpoint that takes the record type from the request and inserts the record with permission checks disabled. Any authenticated user, including one holding no operational role, can supply a privileged record type to create privileged accounts and take full control of the site. |
| Frappe ERPNext before 15.112.0 and 16.x before 16.23.0 contains a stored cross-site scripting vulnerability in a public portal form that accepts unauthenticated submissions and stores content later rendered with insufficient neutralisation. Unauthenticated attackers can submit crafted markup that executes in the browser sessions of staff who review the stored record. |
| Frappe ERPNext 16.x before 16.27.0 contains a stored cross-site scripting vulnerability that allows users with edit rights to inject script through a record name rendered without escaping. Attackers can set a malicious record name so the script runs in the browser of any colleague who opens the page. |
| Frappe ERPNext before 15.119.1 and 16.x before 16.32.0 contains a server-side template injection vulnerability because user-controlled message fields are not validated before template rendering, allowing expressions to run in an unrestricted context. Authenticated attackers holding a common operational role can inject template expressions to read and write arbitrary database data, delete documents, send outbound requests from the server, and send mail from the site. |
| Frappe ERPNext before 15.106.0 and 16.x before 16.16.0 contains an SQL injection vulnerability in multiple endpoints caused by missing input validation. Authenticated attackers can send specially crafted requests to these endpoints to manipulate database queries and extract sensitive information from the ERPNext database. |
| Frappe ERPNext before 15.110.0 and 16.x before 16.21.0 contains a missing authorization vulnerability in which certain endpoints fail to enforce proper authorization checks. Authenticated users can query these endpoints to read data beyond what their assigned role permits. |
| Frappe ERPNext before 16.14.0 contains a missing authorization vulnerability that allows authenticated users to modify master data beyond their permitted role. Attackers can send requests to certain endpoints lacking proper authorization checks to make unauthorized changes to master data records. |
| Frappe ERPNext before 15.121.0 and 16.x before 16.33.0 contains a missing authorization vulnerability in which certain endpoints fail to enforce proper authorization checks. Authenticated users can call these endpoints directly to read data beyond what their assigned role permits. |
| Frappe ERPNext before 15.120.0 and 16.x before 16.33.0 contains a missing authorization vulnerability in which certain endpoints fail to enforce proper permission checks. Authenticated low-privileged users can request these endpoints directly to read financial data beyond what their assigned role permits. |
| Frappe ERPNext before 15.121.0 and 16.x before 16.34.0 contains a missing authorization vulnerability in which certain endpoints fail to enforce proper authorization checks. Authenticated users can send requests to the affected endpoints to modify data beyond their permitted role, compromising data integrity. |
| Frappe ERPNext before 15.119.1 and 16.x before 16.32.0 contains an SQL injection vulnerability in some endpoints that lack input validation. Authenticated attackers with low privileges can send specially crafted requests to these endpoints to inject SQL and extract sensitive information from the ERPNext database. |
| Frappe Framework before 15.117.0 and 16.x before 16.30.0 contains an arbitrary file read vulnerability in the handling of attributes in outgoing email HTML. Attackers who can supply outgoing email content can set an attribute value referencing a local file path to expose sensitive server files. |
| Hugo from v0.162.0 before v0.167.0 contains an improper link resolution vulnerability that lets malicious themes or modules expose files outside their root via nested-mount ancestor directories. Attackers controlling a theme can place a symlink or NTFS junction at a virtual ancestor directory, causing resources.Match to list and publish local files during builds. |
