| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| There is an HTML injection vulnerability in Esri Portal for ArcGIS versions 12.0 and prior that allows a remote, authenticated attacker to insert arbitrary HTML into the Portal for ArcGIS Home application. Users working with ArcGIS Enterprise 11.1, 11.3, 11.5 and 12.0 are encouraged to patch. All users are advised to upgrade to the latest long-term support release. |
| There is a missing authentication vulnerability in Esri Portal for ArcGIS versions 12.0 and prior that may allow a remote, unauthenticated attacker to access a specific resource (not user content) that should only be accessible by authenticated users. Users working with ArcGIS Enterprise 11.1, 11.3, 11.5, or 12.0 are encouraged to patch. All users are advised to upgrade to the latest long-term support release. |
| There is an information disclosure vulnerability in Esri Portal for ArcGIS versions 11.5 through 12.0 and earlier that may allow a remote, unauthenticated attacker to reflect sensitive information in a http response body. |
| There is an information disclosure vulnerability in Esri Portal for ArcGIS versions 12.0 and earlier that may under difficult to reproduce circumstances allow a remote, unauthenticated attacker to reflect sensitive information in a http response body. |
| Unauthenticated Cross Site Scripting (XSS) in Advance Product Search <= 1.4.8 versions. |
| The WS Form LITE – Drag & Drop Contact Form Builder plugin for WordPress is vulnerable to PHP Object Injection in all versions up to, and including, 1.10.80 via deserialization of untrusted input from form submission meta values. This makes it possible for unauthenticated attackers to inject a PHP Object. No known POP chain is present in the vulnerable software, which means this vulnerability has no impact unless another plugin or theme containing a POP chain is installed on the site. If a POP chain is present via an additional plugin or theme installed on the target system, it may allow the attacker to perform actions like delete arbitrary files, retrieve sensitive data, or execute code depending on the POP chain present. |
| GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.8 before 19.0.6, 19.1 before 19.1.4, and 19.2 before 19.2.2 that under certain conditions could have allowed an authenticated user to achieve remote code execution due to a path traversal vulnerability in the package registry. |
| The O-RAN E2T I-Release Prometheus metric Increment function can crash in sctpThread.cpp for message.peerInfo->sctpParams->e2tCounters[IN_SUCC][MSG_COUNTER][ProcedureCode_id_RICsubscription]->Increment(). |
| The O-RAN E2T I-Release Prometheus metric Increment function can crash in sctpThread.cpp for message.peerInfo->counters[IN_INITI][MSG_COUNTER][ProcedureCode_id_E2setup]->Increment(). |
| An issue with the Autodiscover component in Nagios XI 2024R1.01 allows a remote attacker to escalate privileges via a crafted Dashlet. |
| Cross Site Scripting vulnerability in Lavalite CMS v.10.1.0 allows attackers to execute arbitrary code and obtain sensitive information via a crafted payload to the URL. |
| An issue in Ecommerce-CodeIgniter-Bootstrap commit v. d22b54e8915f167a135046ceb857caaf8479c4da allows a remote attacker to execute arbitrary code via the removeSecondaryImage method of the Publish.php component. |
| An out-of-bounds write vulnerability exists in the JPEG2000Codec::DecodeByStreamsCommon functionality of Mathieu Malaterre Grassroot DICOM 3.0.23. A specially crafted DICOM file can lead to a heap buffer overflow. An attacker can provide a malicious file to trigger this vulnerability. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/v3d: Serialize the scheduler timeout handlers
V3D exposes several independent hardware queues (BIN, RENDER, TFU and
CSD) but has only a single, global reset. A timeout on any one queue
therefore has to stop, reset and restart the schedulers of every other
queue as well. That makes concurrent timeout handlers unsafe.
`reset_lock` was never able to make them safe, as a driver-side lock can
only cover the driver's &drm_sched_backend_ops.timedout_job callback.
The scheduler handles the timed out job and its pending list around that
callback, outside of the driver's control, so a global reset triggered
by one queue can still interfere with another queue that is in the
middle of handling a timeout of its own.
Consequently, if a reset happens in the CSD queue while a CL-intensive
application is running, the global reset stops and restarts the CL
queue's scheduler while that queue is handling a timeout of its own. As
drm_sched_stop() and drm_sched_start() subtract and add the credits of
every job sitting on the pending list of the scheduler they are called
on, and as the CL queue's handler concurrently takes its job off that
same list and puts it back, the stop and the start no longer see the
same set of jobs. The CL queue is left with more credits in flight than
its limit:
[ 327.302739] ------------[ cut here ]------------
[ 327.302744] WARNING: CPU: 2 PID: 43 at drivers/gpu/drm/scheduler/sched_main.c:102 drm_sched_run_job_work+0x238/0x4d0 [gpu_sched]
[ 327.302884] CPU: 2 UID: 0 PID: 43 Comm: kworker/u16:1 Not tainted 6.18.39-v8-16k+ #3 PREEMPT
[ 327.302889] Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT)
[ 327.302893] Workqueue: v3d_bin drm_sched_run_job_work [gpu_sched]
[ 327.302984] Call trace:
[ 327.302987] drm_sched_run_job_work+0x238/0x4d0 [gpu_sched] (P)
[ 327.302997] process_scheduled_works+0x180/0x3d0
[ 327.303010] worker_thread+0x268/0x3e8
[ 327.303016] kthread+0x140/0x250
[ 327.303022] ret_from_fork+0x10/0x20
[ 327.303031] ---[ end trace 0000000000000000 ]---
From that point on, the credit count of the CL queue is broken, causing
a complete GPU hang and UI freeze.
The DRM scheduler already provides a mechanism to serialize the timeout
handlers of different schedulers: an ordered workqueue passed as
drm_sched_init()'s @timeout_wq parameter. By default, each scheduler
queues its timeout work on the system workqueue, which runs the handlers
concurrently. Give all of the queues a shared ordered workqueue instead,
as recommended by the DRM scheduler documentation for hardware that has
distinct queues but resets globally. |
| In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8723bs: fix OOB read in WMM_param_handler()
WMM_param_handler() copies a fixed-size WMM parameter element out of a
received information element without checking that the element is long
enough, causing an out-of-bounds read for a short WMM IE.
The handler reads sizeof(struct WMM_para_element) (18) bytes at
pIE->data + 6, so it requires pIE->length to be at least 24
(WLAN_WMM_LEN), but it never validates the length. Two of its three
callers reach it after matching only the WMM OUI: OnAssocRsp() in
rtw_mlme_ext.c matches a 6-byte OUI, and join_cmd_hdl() matches a
4-byte OUI, before calling the handler. A vendor-specific IE carrying
the WMM OUI but a length between 6 and 23, placed in an association
response or in the IE blob handed to join_cmd_hdl(), passes the OUI
check and then makes the memcmp() and memcpy() at pIE->data + 6 read
past the end of the element. OnAssocRsp() parses a frame received from
the AP, so this is reachable from a remote peer.
The remaining caller in rtw_wlan_util.c already guards the handler with
"pIE->length == WLAN_WMM_LEN". Move the equivalent check into the
handler itself so every caller is covered; the sibling IE handlers in
the same parsing loop (HT_caps_handler(), HT_info_handler(),
ERP_IE_handler()) likewise bound their accesses by pIE->length. |
| In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: reallocate update replies for mismatched IDs
ovs_flow_cmd_new() preallocates the optional reply skb before it takes
ovs_mutex and before it knows which existing flow will be updated.
That is normally fine because the skb is sized from the request flow
identifier. That identifier also becomes the inserted flow's identifier.
For updates, however, a request with a UFID may miss the UFID lookup and
then fall back to the flow key lookup. That lookup can legitimately find
an existing key-identified flow. UFIDs are optional and the flow key is
the primary identifier.
For echoed replies, ovs_flow_cmd_fill_info() writes the matched flow's
identifier, not the request identifier used for the preallocation. A short
request UFID can therefore leave too little room for the key identifier.
The fill can then fail with -EMSGSIZE and hit the BUG_ON(error < 0) in the
update path.
Once the update target has been resolved, reallocate the reply skb if the
matched flow needs a larger reply than the request identifier allowed. Do
this before replacing the actions so the request can still fail cleanly if
the rare extra allocation fails. |
| In the Linux kernel, the following vulnerability has been resolved:
Input: evdev - fix information leak in evdev_pass_values()
In evdev_pass_values(), the input_event structure is allocated on the
kernel stack and populated field-by-field. However, it is never fully
initialized. On architectures where struct input_event contains explicit
or implicit padding (such as the 32-bit __pad field on SPARC64), these
padding bytes are left uninitialized.
When this event structure is subsequently passed to the client buffer
and later copied to userspace, the uninitialized padding bytes leak
kernel stack memory, potentially exposing sensitive information.
Similar issues exist in __evdev_queue_syn_dropped and __pass_event.
Fix this by explicitly zeroing the entire event structure with memset()
before populating its fields. This ensures all padding bytes are cleared
before the data crosses the security boundary. |
| In the Linux kernel, the following vulnerability has been resolved:
Input: evdev - sanitize event type index when fetching event masks
The user-supplied event type index passed to EVIOCGMASK / EVIOCSMASK
ioctls is used to index the static counts array in evdev_get_mask_cnt()
and client evmasks array in evdev_get_mask().
While the event type is architecturally bounded by EV_CNT, speculative
execution may mispredict bounds checks and perform out-of-bounds loads.
Sanitize the event type index in evdev_get_mask_cnt() branchlessly using
array_index_mask_nospec(). This clamps the index to 0 for safe array
access and forces the returned count to 0 speculatively when the index
is out of bounds.
We do not need additional array_index_nospec() calls in evdev_get_mask()
because evdev_get_mask_cnt() speculatively forces the count (and
resulting xfer_size) to 0 for out-of-bounds types, preventing any
speculative memory access to client evmasks array. |
| A flaw was found in cri-o, where an arbitrary systemd property can be injected via a Pod annotation. Any user who can create a pod with an arbitrary annotation may perform an arbitrary action on the host system. |
| Unauthenticated Privilege Escalation in Digits <= 9.2 versions. |
