| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Nokogiri before 1.14.3 (CRuby implementation only, when using the packaged libxml2) bundles libxml2 v2.10.3, which is vulnerable to NULL pointer dereferences in XML Schema processing (xmlSchemaFixupComplexType, CVE-2023-28484, and xmlSchemaCheckCOSSTDerivedOK). An attacker who supplies a crafted/malformed XML schema can cause libxml2 to dereference a NULL pointer and potentially segfault, resulting in a denial of service. Nokogiri 1.14.3 upgrades the packaged libxml2 to v2.10.4 to resolve these issues. |
| Nokogiri before 1.13.2 (CRuby, when using packaged libraries) ships vendored libxml2 2.9.12 and libxslt 1.1.34, which are affected by two upstream CVEs. Via CVE-2021-30560 in libxslt, an application transforming XML with untrusted XSL stylesheets is vulnerable to a denial-of-service attack. Via CVE-2022-23308 in libxml2, an application parsing an untrusted document with parse option DTDVALID set to true and NOENT set to false may be vulnerable to denial of service, memory disclosure, or code execution. Nokogiri 1.13.2 upgrades vendored libxml2 to 2.9.13 and libxslt to 1.1.35. |
| Nokogiri versions before 1.13.5 contain an integer overflow vulnerability in packaged libxml2 buffer handling functions that allows attackers to cause out-of-bounds memory writes. Attackers can exploit this by crafting multi-gigabyte XML files to trigger buffer overflows resulting in information disclosure, data modification, or denial of service. |
| Nokogiri before 1.13.9 (CRuby implementation using packaged libraries) bundles libxml2 v2.9.14, which is affected by CVE-2022-40304 (data corruption / double-free from an entity reference cycle when entity content is allocated from a dict) and CVE-2022-40303 (integer overflows when parsing with XML_PARSE_HUGE). Nokogiri 1.13.9 upgrades the packaged libxml2 to v2.10.3 to address these issues. Processing crafted XML input may lead to denial of service or memory corruption. (The advisory also references CVE-2022-2309, a NULL pointer dereference via iterwalk/canonicalize, which maintainers determined does not affect Nokogiri users.) |
| Nokogiri before 1.11.4 (CRuby implementation only, when the packaged/vendored libxml2 is used) bundles libxml2 2.9.10, which is affected by multiple vulnerabilities addressed in libxml2 2.9.12, including a memory leak in xmlSchemaValidateStream (CVE-2019-20388), a global buffer over-read in xmlEncodeEntitiesInternal (CVE-2020-24977), a heap-based buffer overflow (CVE-2021-3517), and an out-of-bounds read (CVE-2021-3518). Processing crafted XML documents may lead to denial of service, information disclosure, or memory corruption. |
| In the Linux kernel, the following vulnerability has been resolved:
gpio: sloppy-logic-analyzer: fix use-after-free via debugfs trigger on unbind
The "trigger" debugfs file has a hand-rolled ->write handler
(trigger_write()) that dereferences the per-device gpio_la_poll_priv. The
file is created with debugfs_create_file_unsafe(), and the handler never
takes a debugfs reference. Nothing keeps the object alive while the
handler runs.
priv is allocated with devm_kzalloc(). devres frees it when the platform
device is unbound. debugfs_create_file_unsafe() installs no full_proxy
wrapper, so debugfs_remove_recursive() in gpio_la_poll_remove() does not
wait for an in-flight trigger_write(). The blob_lock taken there does not
help, because trigger_write() never takes it. A write that races an unbind
therefore writes into freed memory:
trigger_write() gpio_la_poll_remove()
priv = m->private
buf = memdup_user() [may sleep]
mutex_lock(&priv->blob_lock)
debugfs_remove_recursive() [no wait]
mutex_unlock(&priv->blob_lock)
(remove returns; devres frees priv)
priv->trig_data = buf <-- use-after-free write
priv->trig_len = count
The race is reachable by root via
/sys/bus/platform/drivers/gpio-sloppy-logic-analyzer/unbind.
Create "trigger" with debugfs_create_file() instead. Its full_proxy
wrapper makes debugfs_remove_recursive() drain any in-flight ->write
before it returns.
The use-after-free is confirmed under KASAN with a minimal reproducer of
the same debugfs_create_file_unsafe() plus devm_kzalloc() pattern
(available on request); it produces a slab-use-after-free write in the
handler. |
| In the Linux kernel, the following vulnerability has been resolved:
Input: hynitron_cstxxx - validate touch count and finger IDs
The driver allocates max_touch_num input slots, which are indexed from
zero through max_touch_num - 1. The current check allows a finger ID
equal to max_touch_num to reach cst3xx_report_contact(). While the input
core ignores out-of-range slot indices, reporting touch data without a
valid slot change corrupts the touch state of the previously active slot.
The touch count is read from the controller's report and is used to
index the fixed-size report buffer without first checking its range.
Reject counts larger than the supported number of touch slots before
checking the trailing byte or parsing touch data.
Reject finger IDs equal to or greater than max_touch_num, and return
immediately when an invalid finger ID is encountered so that corrupt
touch frames are discarded instead of reporting partial contact state.
The V821 Avaota F1 board configures the vendor driver with one touch
slot, so finger ID 1 is already invalid on that device. |
| In the Linux kernel, the following vulnerability has been resolved:
Input: synaptics-rmi4 - bound the F54 report size to the allocated buffer
rmi_f54_work() reads a diagnostics report from the device into
f54->report_data, sizing the transfer with rmi_f54_get_report_size():
report_size = rmi_f54_get_report_size(f54);
...
for (i = 0; i < report_size; i += F54_REPORT_DATA_SIZE) {
int size = min(F54_REPORT_DATA_SIZE, report_size - i);
...
rmi_read_block(.., f54->report_data + i, size);
}
report_data is allocated once at probe from F54's own electrode counts
(array3_size(f54->num_tx_electrodes, f54->num_rx_electrodes, sizeof(u16))),
but rmi_f54_get_report_size() computes the size from
drv_data->num_*_electrodes when those are set, i.e. from the F55
function's electrode counts. Both counts come straight from device
queries (F54 and F55 each report up to 255 electrodes) and nothing
constrains the F55 counts to the F54 ones.
A malicious or malfunctioning RMI4 device that reports larger F55
electrode counts than its F54 counts makes report_size exceed the
allocation, so the read loop writes past report_data (and the V4L2
dequeue memcpy() then reads past it). On conforming hardware the F55
configured electrodes are a subset of the F54 physical electrodes, so
report_size never exceeds the buffer and well-behaved devices are
unaffected.
Record the allocation size and reject a report that does not fit,
mirroring the existing zero-size check. |
| In the Linux kernel, the following vulnerability has been resolved:
Input: synaptics-rmi4 - zero report size on F54 work error
In rmi_f54_work(), if an error occurs during report request or command
verification, the code jumped directly to the 'error' label, bypassing
the 'abort' label where f54->report_size was normally zeroed out.
This left f54->report_size containing its previous successful payload
size. If a user then altered the V4L2 format to a smaller size, and a
subsequent run failed, rmi_f54_buffer_queue() would copy the stale,
larger payload size into the shrunken V4L2 buffer, causing a heap
buffer overflow.
Fix this by merging the 'abort' and 'error' labels into a single 'out'
exit path, and ensuring that f54->report_size is always set to 0 on
failure by checking for error and zeroing the local report_size first. |
| In the Linux kernel, the following vulnerability has been resolved:
Input: focaltech - fix array out-of-bounds in focaltech_process_rel_packet
Make finger2 (and also finger1) unsigned, so that if the finger index in
the packet is 0 then subtracting 1 creates an array index which overflows
above the existing check for FOC_MAX_FINGERS, as the existing comment says
it should, instead of writing to state->fingers[-1]. |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: SOF: ipc4-pcm: Continue the pipeline trigger in case of IPC timeout
Ignore IPC errors for pipeline state change if the firmware state is
crashed or the IPC has timed out.
If the firmware has crashed the kernel still needs to go through the state
changes to reset its internal to be able to correctly work the next time
the DSP is booted up.
The case with IPC timeout is a bit more problematic, but it has been
rootcaused to be the result of system scheduling blockage and the firmware
did actually received and handled the message, but the reply handling got
blocked by issues outside of the SOF stack.
So far the best way to handle this is to continue with setting the state. |
| SOY CMS contains an issue with deserialization of untrusted data. An arbitrary code may be executed by an attacker with the web server privilege. |
| In the Linux kernel, the following vulnerability has been resolved:
samples/damon/mtier: fail early if address range parameters are invalid
The comment on top of `struct damon_region` clearly says that
For any use case, @ar should be non-zero positive size.
which is now verified in damon_verify_new_region() if the kernel is built
with DAMON_DEBUG_SANITY.
The WARN_ONCE() can be triggered if the mtier sample module is enabled
before node{0,1}_{start,end}_addr have been properly initialized, which is
obviously not good.
------------[ cut here ]------------
start 0 >= end 0
WARNING: mm/damon/core.c:217 at damon_new_region+0xf4/0x118, CPU#59: bash/341468
Call trace:
damon_new_region+0xf4/0x118 (P)
damon_set_regions+0xfc/0x3c0
damon_sample_mtier_build_ctx+0xe8/0x3a8
damon_sample_mtier_start+0x1c/0x90
damon_sample_mtier_enable_store+0x98/0xb0
param_attr_store+0xb4/0x128
module_attr_store+0x2c/0x50
sysfs_kf_write+0x58/0x90
kernfs_fop_write_iter+0x16c/0x238
vfs_write+0x2c0/0x370
ksys_write+0x74/0x118
__arm64_sys_write+0x24/0x38
invoke_syscall+0xa8/0x118
el0_svc_common.constprop.0+0x48/0xf0
do_el0_svc+0x24/0x38
el0_svc+0x54/0x370
el0t_64_sync_handler+0xa0/0xe8
el0t_64_sync+0x1ac/0x1b0
---[ end trace 0000000000000000 ]---
Note that the same issue can happen if detect_node_addresses is true, and
node 0 or 1 is memoryless. Fix it together by checking the validity of
parameters right before damon_new_region() and fail early if they're
invalid. |
| In the Linux kernel, the following vulnerability has been resolved:
batman-adv: dat: ensure accessible eth_hdr proto field
When batadv_get_vid() accesses the proto field of the ethernet header, it
is not checking if the data itself is accessible. The caller is responsible
for it. But in contrast to other call sites, batadv_dat_get_vid() and its
caller didn't make sure this is true. This could have caused an
out-of-bounds access. |
| In the Linux kernel, the following vulnerability has been resolved:
coresight: ete: Always save state on power down
System register ETMs and ETE are unlikely to be preserved on CPU power
down. The ETE DT binding also never documented
"arm,coresight-loses-context-with-cpu" so nobody would have legitimately
been able to use that binding to fix it and ACPI has no such binding at
all.
Fix it by hard coding the setting for sysreg ETMs (ETE is always sysreg)
or ACPI boots. Use a local variable when setting up save_state so that
it's immune to concurrent probing when devices have different
configurations which is an issue with modifying the global.
This fixes the following error when using Coresight with ACPI on the FVP
which supports CPU PM:
coresight ete0: External agent took claim tag
WARNING: drivers/hwtracing/coresight/coresight-core.c:248 at coresight_disclaim_device_unlocked+0xe0/0xe8, CPU#0: perf/117 |
| Budibase backend-core (@budibase/backend-core, as used by @budibase/server) omits the shared address space range 100.64.0.0/10 from its default SSRF blacklist (DEFAULT_BLACKLIST) used by REST datasource query previews. When the default blacklist is active (i.e., a self-hosted deployment has not defined BLACKLIST_IPS), an authenticated user with the Builder permission can submit a REST datasource query preview request to POST /api/queries/preview targeting a reachable HTTP(S) service in the 100.64.0.0/10 range, causing the server to send a request to that target and return its response through the preview flow. Per the advisory, no released fix was identified at the time of publication; remediation is to add 100.64.0.0/10 to DEFAULT_BLACKLIST. |
| The source-address critical option in the Permissions returned by an authentication callback was only enforced for the PublicKeyCallback and VerifiedPublicKeyCallback paths, extending the fix for CVE-2026-46595. Permissions returned by the PasswordCallback, KeyboardInteractiveCallback, NoClientAuthCallback, and GSSAPIWithMICConfig.AllowLogin callbacks were not validated against the client's remote address, so a source-address restriction set by those callbacks was silently ignored. The check is now applied to the Permissions returned by any authentication callback. |
| An attacker that can reach a container's published TCP port may be able to force the host's forwarding process to buffer an unbounded amount of that client's data in memory, for as long as the backend container connection takes to complete — with no cap on how much accumulates or how long the wait can be stretched. This vulnerability is addressed in container version 1.2.0. |
| Joomla Extension - digital-peak.com - Authenticated, privileged blind SQL injection in DP Calendar 5.5.0 - 10.11.2 - Saving an article can trigger a blind SQL injection with content plugin, needs update permission for articles. |
| Joomla Extension - Jefferson49 - Unauthenticated blind SQLi in Sexy Polling Reloaded < 5.6.1 |
