| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: target: iscsi: Reserve a terminator byte for the login payload
iscsi_target_check_login_request() rejects a login PDU whose
DataSegmentLength exceeds MAX_KEY_VALUE_PAIRS, but the test is '>' and
login->req_buf is allocated with exactly MAX_KEY_VALUE_PAIRS
bytes. Since iscsit_get_login_rx() receives payload_length + padding
bytes, where
padding = ((-payload_length) & 3);
any payload_length from 8189 to 8192 fills the whole 8192 byte
buffer. The write stays in bounds, but no byte is left for a NUL
terminator.
The buffer is subsequently consumed as a C string. In the CHAP path
chap_check_algorithm() calls kstrdup(a_str), and extract_param() calls
strstr(in_buf, pattern) followed by strlen_semi(), none of which take a
length. convert_null_to_semi() additionally rewrites every embedded NUL
to ';', so even a payload made of well formed NUL separated key=value
records is left without a terminator. These walk past the end of the
object into adjacent slab memory. It is reachable by an unauthenticated
initiator against a portal configured for CHAP; when authentication is
not required iscsi_login_zero_tsih_s2() rewrites AuthMethod to None and
the CHAP path is never entered.
Allocate one extra byte. kzalloc() zeroes it and nothing ever writes to
it, as every writer copies to offset 0 for at most MAX_KEY_VALUE_PAIRS
bytes, so the buffer is always terminated. |
| In the Linux kernel, the following vulnerability has been resolved:
HID: rmi: fix OOB access with undersized RMI reports
The hid-rmi driver sizes its writeReport/readReport buffer purely from
the report descriptor supplied by the device, with no minimum bound:
data->input_report_size = hid_report_len(input_report);
data->output_report_size = hid_report_len(output_report);
alloc_size = data->output_report_size + data->input_report_size;
data->writeReport = devm_kzalloc(&hdev->dev, alloc_size, GFP_KERNEL);
data->readReport = data->writeReport + data->output_report_size;
but then reads and writes fixed offsets into it. A device declaring a
1-byte output and a 1-byte input report makes hid_report_len() return 2
for each, so alloc_size is 4, while rmi_set_page() -- reached
unconditionally at probe time through rmi_input_configured() -- stores
writeReport[4] and rmi_hid_read_block() stores writeReport[0..5]. Since
readReport lives at writeReport + output_report_size, those stores also
corrupt the window the next reply is parsed out of.
The read path is worse: the copy length comes from readReport[1], which
the device fills in and can be up to 255, and the copy starts at
&readReport[2] with no regard for input_report_size, so it runs past the
end of the allocation into adjacent slab objects. This does not even
need a lying device -- rmi_f01_probe() issues a fixed 21-byte register
read, so any device declaring an input report smaller than 23 bytes
reads out of bounds even when it answers truthfully. Those bytes become
the register values the RMI core acts on: rmi_f01_probe() prints them to
the kernel log as the product id and exports them through the mode 0444
sysfs attribute of the same name, and rmi_driver_set_irq_bits() sends
them back to the device as the interrupt mask, so an undersized report
descriptor leaks heap contents both to unprivileged userspace and to the
device itself.
The write path has no bound either: rmi_hid_write_block() copies an
unbounded len to &writeReport[4], and the largest caller a device can
drive at probe time is rmi_driver_set_irq_bits(), whose length is
derived from the interrupt source counts the device declares in its Page
Description Table.
Finally, the read loop cannot terminate on a zero-length reply: such a
reply copies nothing and advances neither bytes_read nor bytes_needed,
and because a reply did arrive the one second wait_event_timeout() does
not fire either, so a device answering 0 forever keeps the loop running
inside the probe worker with page_mutex held. khungtaskd does not
notice, because every reply wakes the task.
Reject reports too small for what the driver builds -- 6 output bytes
for the write reports and 3 input bytes for the read handshake -- at
probe time, clamp the write and the read copy to the report sizes the
device declared, and treat a zero-length reply as an error. A device
refused this way is started as an ordinary HID device, like one that
does not carry the RMI report ids at all.
RMI_DEVICE must not be left set in device_flags on that path, because
rmi_input_configured() would then run the RMI setup and reach
rmi_set_page(), which writes the writeReport buffer the refusal just
skipped allocating. The bit can arrive set: rmi_probe() copies
id->driver_data into device_flags before the report checks, and a bind
through the new_id sysfs attribute can supply driver_data with
RMI_DEVICE (BIT(0)) set. Strip the bit where driver_data is copied, so
RMI_DEVICE keeps meaning exactly "this probe validated the reports"; the
three jumps to start that predate this patch are covered as well.
The error path also clears RMI_READ_DATA_PENDING on its way out, because
that flag is what the wait at the top of the loop tests: leaving it set
would make every later wait_event_timeout() return immediately on the
stale reply and kill the read path for the rest of the device's life.
Clamping does not regress working hardware: the read loop already
handles
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8723bs: fix OOB read in rtw_action_frame_parse()
rtw_action_frame_parse() takes a frame_len parameter but never
actually checks it before indexing into the frame body:
const u8 *frame_body = frame + sizeof(struct ieee80211_hdr_3addr);
...
c = frame_body[0];
...
a = frame_body[1];
frame_body already points 24 bytes (sizeof(struct
ieee80211_hdr_3addr)) into frame, so reading frame_body[0] and
frame_body[1] requires frame_len >= 26. A management action frame
shorter than that (e.g. exactly 24 bytes, the minimum a malicious
peer can send) causes a 1-2 byte out-of-bounds read.
This is reachable from rtw_cfg80211_monitor_if_xmit_entry() and
cfg80211_rtw_mgmt_tx() in ioctl_cfg80211.c, both of which pass
attacker/user-influenced frame buffers and lengths straight through.
Add the missing length check before frame_body is dereferenced. |
| changedetection.io through 0.60.6 fails to escape the scraped page title in HTML notifications, allowing arbitrary markup injection. Attackers can place malicious markup in monitored page titles that reaches notification channels like email and Telegram as live content when the watch_title token is used in templates. |
| Jenkins Gradle Plugin 2.19.1252.v15196b_5a_6e10 and earlier requests build scan data from the build scan link detected in the build log, even when a Develocity server URL is configured in the global configuration, allowing attackers able to control the build log to capture the Develocity access key configured in the global configuration by having Jenkins connect to an attacker-specified URL. |
| Jenkins Gitee Plugin 1301.v8957053c7902 and earlier does not escape the sender name from Gitee push webhook payloads in build causes, resulting in a stored cross-site scripting (XSS) vulnerability exploitable by attackers able to trigger builds via the Jenkins Gitee Plugin webhook endpoint. |
| SSH.NET is a Secure Shell (SSH) library for .NET. Prior to 2026.0.0, ScpClient places caller-supplied remote paths into the command used to run scp on the server, and the default RemotePathTransformation.DoubleQuote transformation cannot safely quote every remote command interpreter. When an application passes an attacker-controlled path to a shell-based server, shell metacharacters not neutralized by the active IRemotePathTransformation can execute commands as the authenticated SSH user. Exploitation requires a shell-based server and a path crafted for that shell's parsing rules; non-shell servers and paths fully neutralized by the selected transformation are not affected. RemotePathTransformation.ShellQuote is available for POSIX shells, while SftpClient avoids a remote shell entirely. This issue is fixed in version 2026.0.0. |
| Jenkins Warnings Plugin 13.10258.va_17d49a_78c3b_ and earlier does not validate the analysis results ID when a job configuration is submitted through the REST API, allowing attackers with Item/Configure permission to use a javascript: scheme URL as identifier, resulting in a stored cross-site scripting (XSS) vulnerability. |
| Jenkins Coverage Plugin 3.3358.v9487dde48783 and earlier does not validate the coverage results ID when a job configuration is submitted through the REST API, allowing attackers with Item/Configure permission to use a javascript: scheme URL as identifier, resulting in a stored cross-site scripting (XSS) vulnerability. |
| Jenkins OWASP Dependency-Check Plugin 5.6.4 and earlier does not escape CWE values from Dependency-Check reports on the Jenkins UI, resulting in a stored cross-site scripting (XSS) vulnerability exploitable by attackers with Item/Configure permission. |
| RabbitMQ amqp091-go is a Go AMQP 0.9.1 client. Prior to 1.13.0, readLongstr in read.go returns an empty string and a nil error when a declared AMQP longstr length exceeds 0x7FFFFFFF instead of returning ErrSyntax. The function leaves the declared field bytes unread, while readTable treats the operation as successful and continues parsing from the wrong offset. A malicious or compromised broker can provide an oversized longstr in a table field and desynchronize subsequent AMQP parsing, causing attacker-controlled trailing bytes to be interpreted as later fields or frames and disrupting connection integrity and availability. This issue is fixed in version 1.13.0. |
| RMCP is an official Rust SDK for the Model Context Protocol. Prior to 2.0.0, the rmcp crate's stateful Streamable HTTP server in crates/rmcp/src/transport/streamable_http_server/tower.rs allows an unauthenticated client to send a well-formed JSON-RPC POST that is not an initialization request, or an initialization request with a mismatched protocol header, causing StreamableHttpService::handle_post to call LocalSessionManager.create_session before validating the message. An early validation failure returns without removing the inserted LocalSessionHandle from LocalSessionManager.sessions, permanently retaining session and channel state for the server process lifetime. Repeated requests can grow the shared session table without bound, degrade legitimate-client latency through lock contention, exhaust memory, and terminate the server. This issue is fixed in version 2.0.0. |
| Nozomi Networks Labs identified a CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') vulnerability in the web management interface of Advantech EKI-1242IEIMS in firmware version V1.06.01 that allows a remote authenticated attacker to execute arbitrary OS commands as root via crafted request parameters. |
| In the Linux kernel, the following vulnerability has been resolved:
mm/mempolicy: fix sleeping allocation in alloc_pages_bulk_weighted_interleave()
syzbot reported a sleeping function called from invalid context splat in
bucket_table_alloc().
When rhashtable_insert_slow() rehashes the table under rcu_read_lock(), it
calls bucket_table_alloc(..., GFP_ATOMIC | __GFP_NOWARN). If the bucket
table allocation uses vmalloc, __vmalloc_node_range_noprof() invokes
vm_area_alloc_pages() -> alloc_pages_bulk_mempolicy_noprof() with the
passed GFP_ATOMIC flags.
If the current task has an MPOL_WEIGHTED_INTERLEAVE mempolicy,
alloc_pages_bulk_weighted_interleave() is called and currently hardcodes
GFP_KERNEL when allocating the temporary weights array, triggering a
might_alloc() splat in atomic/RCU contexts.
Pass the gfp flags (masked with GFP_RECLAIM_MASK to strip page-allocator
zone modifiers like __GFP_HIGHMEM) received by
alloc_pages_bulk_weighted_interleave() to kmalloc() instead of hardcoding
GFP_KERNEL. Since the weights buffer is immediately initialized in full,
kmalloc() is sufficient. |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: Fix memory leak in guest debug handling
bp_data is freed only for the error case by kfree(bp_data).
Every successful KVM_SET_GUEST_DEBUG will leak bp_data. |
| Nozomi Networks Labs identified a CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') vulnerability in the web management interface of Advantech EKI-1242IEIMS in firmware version V1.06.01 that allows a remote authenticated attacker to execute arbitrary OS commands as root via crafted request parameters. |
| Nozomi Networks Labs identified a CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') vulnerability in the web management interface of Advantech EKI-1242IEIMS in firmware version V1.06.01 that allows a remote authenticated attacker to execute arbitrary OS commands as root via crafted request parameters. |
| Nozomi Networks Labs identified a CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') vulnerability in the web management interface of Advantech EKI-1242IEIMS in firmware version V1.06.01 that allows a remote authenticated attacker to execute arbitrary OS commands as root via crafted request parameters. |
| Nozomi Networks Labs identified a CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') vulnerability in the web management interface of Advantech EKI-1242IEIMS in firmware version V1.06.01 that allows a remote authenticated attacker to execute arbitrary OS commands as root via crafted request parameters. |
| Nozomi Networks Labs identified a CWE-73: External Control of File Name or Path vulnerability in the backup-restore workflow of Advantech EKI-1242EIMS in firmware version V1.06.01 that allows a remote authenticated attacker to overwrite arbitrary files on the device filesystem by uploading a crafted backup archive through the web management interface. |
