| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
drm/xe/nvm: Fix double-free on aux add failure
After a successful auxiliary_device_init(), aux_dev->dev.release
(xe_nvm_release_dev()) is responsible for the kfree(nvm). When
there is failure with auxiliary_device_add(), driver will call
auxiliary_device_uninit(), which call put_device(). So that the
.release callback will be triggered to free the memory associated
with the auxiliary_device.
Move the kfree(nvm) into the auxiliary_device_init() failure path
and remove the err goto path to fix below error.
"
[ 13.232905] ==================================================================
[ 13.232911] BUG: KASAN: double-free in xe_nvm_init+0x751/0xf10 [xe]
[ 13.233112] Free of addr ffff888120635000 by task systemd-udevd/273
[ 13.233120] CPU: 8 UID: 0 PID: 273 Comm: systemd-udevd Not tainted 6.19.0-rc2-lgci-xe-kernel+ #225 PREEMPT(voluntary)
...
[ 13.233125] Call Trace:
[ 13.233126] <TASK>
[ 13.233127] dump_stack_lvl+0x7f/0xc0
[ 13.233132] print_report+0xce/0x610
[ 13.233136] ? kasan_complete_mode_report_info+0x5d/0x1e0
[ 13.233139] ? xe_nvm_init+0x751/0xf10 [xe]
...
"
v2: drop err goto path. (Alexander)
(cherry picked from commit a3187c0c2bbd947ffff97f90d077ac88f9c2a215) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix NULL pointer dereference in amdgpu_gmc_filter_faults_remove
On APUs such as Raven and Renoir (GC 9.1.0, 9.2.2, 9.3.0), the ih1 and
ih2 interrupt ring buffers are not initialized. This is by design, as
these secondary IH rings are only available on discrete GPUs. See
vega10_ih_sw_init() which explicitly skips ih1/ih2 initialization when
AMD_IS_APU is set.
However, amdgpu_gmc_filter_faults_remove() unconditionally uses ih1 to
get the timestamp of the last interrupt entry. When retry faults are
enabled on APUs (noretry=0), this function is called from the SVM page
fault recovery path, resulting in a NULL pointer dereference when
amdgpu_ih_decode_iv_ts_helper() attempts to access ih->ring[].
The crash manifests as:
BUG: kernel NULL pointer dereference, address: 0000000000000004
RIP: 0010:amdgpu_ih_decode_iv_ts_helper+0x22/0x40 [amdgpu]
Call Trace:
amdgpu_gmc_filter_faults_remove+0x60/0x130 [amdgpu]
svm_range_restore_pages+0xae5/0x11c0 [amdgpu]
amdgpu_vm_handle_fault+0xc8/0x340 [amdgpu]
gmc_v9_0_process_interrupt+0x191/0x220 [amdgpu]
amdgpu_irq_dispatch+0xed/0x2c0 [amdgpu]
amdgpu_ih_process+0x84/0x100 [amdgpu]
This issue was exposed by commit 1446226d32a4 ("drm/amdgpu: Remove GC HW
IP 9.3.0 from noretry=1") which changed the default for Renoir APU from
noretry=1 to noretry=0, enabling retry fault handling and thus
exercising the buggy code path.
Fix this by adding a check for ih1.ring_size before attempting to use
it. Also restore the soft_ih support from commit dd299441654f ("drm/amdgpu:
Rework retry fault removal"). This is needed if the hardware doesn't
support secondary HW IH rings.
v2: additional updates (Alex)
(cherry picked from commit 6ce8d536c80aa1f059e82184f0d1994436b1d526) |
| In the Linux kernel, the following vulnerability has been resolved:
rocker: fix memory leak in rocker_world_port_post_fini()
In rocker_world_port_pre_init(), rocker_port->wpriv is allocated with
kzalloc(wops->port_priv_size, GFP_KERNEL). However, in
rocker_world_port_post_fini(), the memory is only freed when
wops->port_post_fini callback is set:
if (!wops->port_post_fini)
return;
wops->port_post_fini(rocker_port);
kfree(rocker_port->wpriv);
Since rocker_ofdpa_ops does not implement port_post_fini callback
(it is NULL), the wpriv memory allocated for each port is never freed
when ports are removed. This leads to a memory leak of
sizeof(struct ofdpa_port) bytes per port on every device removal.
Fix this by always calling kfree(rocker_port->wpriv) regardless of
whether the port_post_fini callback exists. |
| In the Linux kernel, the following vulnerability has been resolved:
net: wwan: t7xx: fix potential skb->frags overflow in RX path
When receiving data in the DPMAIF RX path,
the t7xx_dpmaif_set_frag_to_skb() function adds
page fragments to an skb without checking if the number of
fragments has exceeded MAX_SKB_FRAGS. This could lead to a buffer overflow
in skb_shinfo(skb)->frags[] array, corrupting adjacent memory and
potentially causing kernel crashes or other undefined behavior.
This issue was identified through static code analysis by comparing with a
similar vulnerability fixed in the mt76 driver commit b102f0c522cf ("mt76:
fix array overflow on receiving too many fragments for a packet").
The vulnerability could be triggered if the modem firmware sends packets
with excessive fragments. While under normal protocol conditions (MTU 3080
bytes, BAT buffer 3584 bytes),
a single packet should not require additional
fragments, the kernel should not blindly trust firmware behavior.
Malicious, buggy, or compromised firmware could potentially craft packets
with more fragments than the kernel expects.
Fix this by adding a bounds check before calling skb_add_rx_frag() to
ensure nr_frags does not exceed MAX_SKB_FRAGS.
The check must be performed before unmapping to avoid a page leak
and double DMA unmap during device teardown. |
| Apache NiFi 1.1.0 through 2.7.2 are missing authorization when updating configuration properties on extension components that have specific Required Permissions based on the Restricted annotation. The Restricted annotation indicates additional privileges required to add the annotated component to the flow configuration, but framework authorization did not check restricted status when updating a component previously added. The missing authorization requires a more privileged user to add a restricted component to the flow configuration, but permits a less privileged user to make property configuration changes. Apache NiFi installations that do not implement different levels of authorization for Restricted components are not subject to this vulnerability because the framework enforces write permissions as the security boundary. Upgrading to Apache NiFi 2.8.0 is the recommended mitigation. |
| A vulnerability was found in Beetel 777VR1 up to 01.00.09. This affects an unknown function of the component Telnet Service/SSH Service. The manipulation results in insecure default initialization of resource. The attack can only be performed from the local network. The exploit has been made public and could be used. The vendor was contacted early about this disclosure but did not respond in any way. |
| Emails sent by pretix can utilize placeholders that will be filled with customer data. For example, when {name}
is used in an email template, it will be replaced with the buyer's
name for the final email. This mechanism contained two security-relevant
bugs:
*
It was possible to exfiltrate information about the pretix system through specially crafted placeholder names such as {{event.__init__.__code__.co_filename}}.
This way, an attacker with the ability to control email templates
(usually every user of the pretix backend) could retrieve sensitive
information from the system configuration, including even database
passwords or API keys. pretix does include mechanisms to prevent the usage of such
malicious placeholders, however due to a mistake in the code, they were
not fully effective for the email subject.
*
Placeholders in subjects and plain text bodies of emails were
wrongfully evaluated twice. Therefore, if the first evaluation of a
placeholder again contains a placeholder, this second placeholder was
rendered. This allows the rendering of placeholders controlled by the
ticket buyer, and therefore the exploitation of the first issue as a
ticket buyer. Luckily, the only buyer-controlled placeholder available
in pretix by default (that is not validated in a way that prevents the
issue) is {invoice_company}, which is very unusual (but not
impossible) to be contained in an email subject template. In addition
to broadening the attack surface of the first issue, this could
theoretically also leak information about an order to one of the
attendees within that order. However, we also consider this scenario
very unlikely under typical conditions.
Out of caution, we recommend that you rotate all passwords and API keys contained in your pretix.cfg https://docs.pretix.eu/self-hosting/config/ file. |
| Smoothwall Express 3.1-SP4-polar-x86_64-update9 contains a reflected cross-site scripting vulnerability that allows unauthenticated attackers to inject malicious scripts by submitting crafted input to the ipblock.cgi endpoint. Attackers can inject script tags through the SRC_IP and COMMENT parameters in POST requests to execute arbitrary JavaScript in users' browsers. |
| Smoothwall Express 3.1-SP4-polar-x86_64-update9 contains a reflected cross-site scripting vulnerability that allows unauthenticated attackers to inject malicious scripts by manipulating the MACHINES parameter. Attackers can craft requests to the timedaccess.cgi endpoint with script payloads in the MACHINES parameter to execute arbitrary JavaScript in users' browsers. |
| Smoothwall Express 3.1-SP4-polar-x86_64-update9 contains a reflected cross-site scripting vulnerability that allows unauthenticated attackers to inject malicious scripts by exploiting insufficient input validation. Attackers can submit POST requests to the smoothinfo.cgi endpoint with script payloads in the WRAP or SECTIONTITLE parameters to execute arbitrary JavaScript in victim browsers. |
| Smoothwall Express 3.1-SP4-polar-x86_64-update9 contains multiple stored cross-site scripting vulnerabilities in the preferences.cgi script that allow attackers to inject malicious scripts through the HOSTNAME, KEYMAP, and OPENNESS parameters. Attackers can submit POST requests with script payloads to preferences.cgi to store malicious code that executes in the browsers of users accessing the preferences page. |
| Smoothwall Express 3.1-SP4-polar-x86_64-update9 contains multiple reflected cross-site scripting vulnerabilities in the hosts.cgi script that allow attackers to inject malicious scripts through unvalidated parameters. Attackers can submit POST requests to the hosts.cgi endpoint with script payloads in the IP, HOSTNAME, or COMMENT parameters to execute arbitrary JavaScript in users' browsers. |
| Smoothwall Express 3.1-SP4-polar-x86_64-update9 contains multiple reflected cross-site scripting vulnerabilities in the portfw.cgi script that allow attackers to inject malicious scripts through unvalidated parameters. Attackers can submit POST requests with script payloads in the EXT, SRC_PORT_SEL, SRC_PORT, DEST_IP, DEST_PORT_SEL, or COMMENT parameters to execute arbitrary JavaScript in users' browsers. |
| Smoothwall Express 3.1-SP4-polar-x86_64-update9 contains a reflected cross-site scripting vulnerability that allows attackers to inject malicious scripts by manipulating the MACHINE and MACHINECOMMENT parameters. Attackers can send POST requests to the outgoing.cgi endpoint with script payloads to execute arbitrary JavaScript in users' browsers and steal session data. |
| Smoothwall Express 3.1-SP4-polar-x86_64-update9 contains multiple reflected cross-site scripting vulnerabilities in the dmzholes.cgi script that allow attackers to inject malicious scripts through unvalidated parameters. Attackers can submit POST requests with script payloads in the SRC_IP, DEST_IP, or COMMENT parameters to execute arbitrary JavaScript in users' browsers. |
| Smoothwall Express 3.1-SP4-polar-x86_64-update9 contains a reflected cross-site scripting vulnerability that allows unauthenticated attackers to inject malicious scripts by submitting crafted input to the xtaccess.cgi endpoint. Attackers can inject script payloads through the EXT, DEST_PORT, or COMMENT parameters via POST requests to execute arbitrary JavaScript in victim browsers. |
| ArangoDB Community Edition 3.4.2-1 contains multiple cross-site scripting vulnerabilities in the Aardvark web admin interface (index.html) through search, user management, and API parameters. Attackers can inject scripts via parameters in /_db/_system/_admin/aardvark/index.html to execute JavaScript in authenticated users' browsers. |
| An issue in Datart v1.0.0-rc.3 allows attackers to execute arbitrary code via the url parameter in the JDBC configuration |
| In the Linux kernel, the following vulnerability has been resolved:
riscv: Sanitize syscall table indexing under speculation
The syscall number is a user-controlled value used to index into the
syscall table. Use array_index_nospec() to clamp this value after the
bounds check to prevent speculative out-of-bounds access and subsequent
data leakage via cache side channels. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: wlcore: ensure skb headroom before skb_push
This avoids occasional skb_under_panic Oops from wl1271_tx_work. In this case, headroom is
less than needed (typically 110 - 94 = 16 bytes). |
