| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| HCL Aftermarket EPC is vulnerable to brute force attacks since application doesn’t have captcha implemented. It can lead to various security issues like brute force , automated attacks & account enumeration |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: target: iscsi: Validate CHAP_R length before base64 decode
chap_server_compute_hash() allocates client_digest as
kzalloc(chap->digest_size) and then, for BASE64-encoded responses,
passes chap_r directly to chap_base64_decode() without checking whether
the input length could produce more than digest_size bytes of output.
chap_base64_decode() writes to the destination unconditionally as long
as there is input to consume. With MAX_RESPONSE_LENGTH set to 128 and
the "0b" prefix stripped by extract_param(), up to 127 base64 characters
can reach the decoder. 127 characters decode to 95 bytes. For SHA-256
(digest_size=32) this overflows client_digest by 63 bytes; for MD5
(digest_size=16) the overflow is 79 bytes.
The length check at line 344 fires after the write has already happened.
The HEX branch in the same switch statement already validates the length
up front. Apply the same approach to the BASE64 branch: strip trailing
base64 padding characters, then reject any input whose data length
exceeds DIV_ROUND_UP(digest_size * 4, 3) before calling the decoder.
Stripping trailing '=' before the comparison handles both padded and
unpadded encodings. chap_base64_decode() already returns early on '=',
so the full original string is still passed to the decoder unchanged.
The mutual CHAP path decodes CHAP_C into initiatorchg_binhex, which is
kzalloc(CHAP_CHALLENGE_STR_LEN). extract_param() caps initiatorchg at
CHAP_CHALLENGE_STR_LEN characters, so at most CHAP_CHALLENGE_STR_LEN-1
base64 characters reach the decoder. The maximum decoded size,
DIV_ROUND_UP((CHAP_CHALLENGE_STR_LEN-1) * 3, 4), is less than
CHAP_CHALLENGE_STR_LEN, so no overflow is possible there. A comment is
added at the call site to document this. |
| In the Linux kernel, the following vulnerability has been resolved:
usb: typec: wcove: don't write past struct pd_message in wcove_read_rx_buffer()
wcove_read_rx_buffer() copies the PD RX FIFO into the caller's
struct pd_message with
for (i = 0; i < USBC_RXINFO_RXBYTES(info); i++)
regmap_read(wcove->regmap, USBC_RX_DATA + i, msg + i);
which has two problems:
USBC_RXINFO_RXBYTES() is a 5-bit field (max 31) while struct pd_message
is 30 bytes (__le16 header + __le32 payload[PD_MAX_PAYLOAD], packed).
The byte count latched in RXINFO is the number of bytes the port partner
put on the wire, so a malicious partner that transmits a 31-byte frame
can drive the loop one byte past the destination if the WCOVE BMC
receiver does not enforce the PD object-count limit in hardware. The
existing FIXME flagged this as unverified.
Independently, regmap_read() takes an unsigned int * and stores a full
unsigned int at the destination. Passing the byte pointer msg + i means
each iteration writes four bytes; the high three are zero (val_bits is
8) and are normally overwritten by the next iteration, but the final
iteration's high bytes are not. With RXBYTES == 30 the i == 29 iteration
already writes three zero bytes past msg, which sits on the IRQ thread's
stack in wcove_typec_irq().
Clamp the loop to sizeof(struct pd_message) and read each register into
a local before storing only its low byte, so the copy can never exceed
the destination regardless of what RXINFO reports. |
| In the Linux kernel, the following vulnerability has been resolved:
usb: typec: altmodes/displayport: validate count before reading Status Update VDO
A broken/malicious device can send the incorrect count for a status
update VDO, which will cause the kernel to read uninitialized stack data
and send it off elsewhere.
Fix this up by correctly verifying the count for the update object. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/msm/snapshot: fix dumping of the unaligned regions
The snapshotting code internally aligns data segment to 16 bytes. This
works fine for DPU code (where most of the regions are aligned), but
fails for snapshotting of the DSI data (because DSI data region is
shifted by 4 bytes). Fix the code by removing length alignment and by
accurately printing last registers in the region. While reworking the
code also fix the 16x memory overallocation in
msm_disp_state_dump_regs().
Patchwork: https://patchwork.freedesktop.org/patch/725449/ |
| In the Linux kernel, the following vulnerability has been resolved:
ipv4: raw: reject IP_HDRINCL packets with ihl < 5
raw_send_hdrinc() validates that the caller-supplied IPv4 header
fits within the message length:
iphlen = iph->ihl * 4;
err = -EINVAL;
if (iphlen > length)
goto error_free;
if (iphlen >= sizeof(*iph)) {
/* fix up saddr, tot_len, id, csum, transport_header */
}
It does not, however, reject ihl < 5. For such a packet the
"if (iphlen >= sizeof(*iph))" branch is skipped, leaving the
crafted iphdr untouched, but the packet is still handed to
__ip_local_out() and onward. Downstream consumers that read
iph->ihl assume a sane value: net/ipv4/ah4.c:ah_output() in
particular subtracts sizeof(struct iphdr) from top_iph->ihl * 4
and passes the (signed-int-negative, then cast to size_t)
result to memcpy(), producing an OOB access of length close to
SIZE_MAX and a host kernel panic.
An IPv4 header with ihl < 5 is malformed by definition (RFC 791:
"Internet Header Length is the length of the internet header in
32 bit words ... Note that the minimum value for a correct header
is 5."). The kernel should not be willing to inject such a
packet into its own output path.
Reject "iphlen < sizeof(*iph)" alongside the existing
"iphlen > length" check. This matches the principle that locally
constructed packets that re-enter the IP stack must pass the same
basic sanity tests that a foreign packet would be subjected to.
Once this lands, the "if (iphlen >= sizeof(*iph))" wrapper around
the fixup branch becomes redundant; left in place to keep the
patch minimal and backport-friendly. A follow-up can unwrap it.
Note that commit 86f4c90a1c5c ("ipv4, ipv6: ensure raw socket
message is big enough to hold an IP header") ensures the message
buffer is large enough to hold an iphdr, but does not constrain
the self-reported iph->ihl.
Reachability: the malformed packet source is any caller with
CAP_NET_RAW, including an unprivileged process in a user+net
namespace on a kernel with CONFIG_USER_NS=y. The reproduced AH
crash also requires a matching xfrm AH policy on the outgoing
route; a container granted CAP_NET_ADMIN can install that state
and policy in its netns. Loopback bypasses xfrm_output, so the
trigger uses a real netdev.
Reproduced on UML + KASAN: kernel-mode fault at addr 0x0 with
memcpy_orig at the crash site. Same shape reproduces inside a
rootless Docker container with --cap-add NET_ADMIN on a stock
distro kernel. |
| In the Linux kernel, the following vulnerability has been resolved:
tunnels: do not assume transport header in iptunnel_pmtud_check_icmp()
In some cases, iptunnel_pmtud_check_icmp() can be called while
skb transport header is not set.
This triggers an out-of-bound access, because
(typeof(skb->transport_header))~0U is 65535.
Access the icmp header based on IPv4 network header,
after making sure icmp->type is present in skb linear part.
Note that iptunnel_pmtud_check_icmpv6()) is fine. |
| In the Linux kernel, the following vulnerability has been resolved:
net: hsr: fix potential OOB access in supervision frame handling
Ensure the entire TLV header is linearized before access by adding
sizeof(struct hsr_sup_tlv) to the pskb_may_pull() calls. Without this,
a truncated frame could cause an out-of-bounds access. |
| Keycloak provides a mechanism called Client Policies to enforce security requirements on clients, such as requiring them to use signed JWTs for authentication. A flaw was discovered where this enforcement can be bypassed. An attacker with valid client credentials can provide a fake, unsigned assertion header that tricks the system into thinking the policy requirements have been met. This allows the attacker to authenticate using simpler methods like a client secret even when the administrator has mandated more secure, signed assertions. |
| dataCycle is a data management system for centrally storing, managing, searching, finding, and distributing data. In dataCycle-CORE, the module handling core processing and framework rules, before and including version 25.07.3, any unauthenticated attacker can place arbitrary HTML into flash notifications on public routes and rely on the frontend toast component to inject that content into the DOM with `innerHTML`. This creates a reflected DOM XSS that can be delivered with a crafted link to a public page such as `/docs`. Because the vulnerable JavaScript is loaded by the normal application layout, the issue is not limited to a special debug page or an isolated admin-only view. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MGMT: validate Add Extended Advertising Data length
MGMT_OP_ADD_EXT_ADV_DATA is registered as a variable-length command,
with MGMT_ADD_EXT_ADV_DATA_SIZE as the fixed header size. The handler
then uses cp->adv_data_len and cp->scan_rsp_len to validate and copy
cp->data, but it never checks that those bytes are part of the mgmt
command payload.
A short command can therefore make add_ext_adv_data() pass an
out-of-bounds pointer into tlv_data_is_valid(). If the bytes beyond
the command buffer are addressable, they can also be copied into the
advertising instance as scan response data, where the caller can read
them back via MGMT_OP_GET_ADV_INSTANCE. The trigger requires
CAP_NET_ADMIN in the initial user namespace; KASAN reports an 8-byte
slab-out-of-bounds read.
Reject commands whose length does not match the fixed header plus both
advertising data lengths before parsing cp->data. |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: vgic-its: Reject restored DTE with out-of-range num_eventid_bits
Userspace can restore an ITS Device Table Entry whose Size field encodes
more EventID bits than the virtual ITS supports. The live MAPD path
rejects that state, but vgic_its_restore_dte() accepts it and stores the
out-of-range value in dev->num_eventid_bits.
Reject restored DTEs with num_eventid_bits > VITS_TYPER_IDBITS before
allocating the device. This mirrors the MAPD check and prevents the
restored state from reaching vgic_its_restore_itt(), where the unchecked
value can be converted into an oversized scan_its_table() range. |
| In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix zeropoint update where i_size > remote_i_size
Fix the update of the zero point[*] by netfs_release_folio() when there is
uncommitted data in the pagecache beyond the folio being released but the
on-server EOF is in this folio (ie. i_size > remote_i_size). The update
needs to limit zero_point to remote_i_size, not i_size as i_size is a local
phenomenon reflecting updates made locally to the pagecache, not stuff
written to the server. remote_i_size tracks the server's i_size.
[*] The zero point is the file position from which we can assume that the
server will just return zeros, so we can avoid generating reads.
Note that netfs_invalidate_folio() probably doesn't need fixing as
zero_point should be updated by setattr after truncation or fallocate.
Found with:
fsx -q -N 1000000 -p 10000 -o 128000 -l 600000 \
/xfstest.test/junk --replay-ops=junk.fsxops
using the following as junk.fsxops:
truncate 0x0 0x1bbae 0x82864
write 0x3ef2e 0xf9c8 0x1bbae
write 0x67e05 0xcb5a 0x4e8f6
mapread 0x57781 0x85b6 0x7495f
copy_range 0x5d3d 0x10329 0x54fac 0x7495f
write 0x64710 0x1c2b 0x7495f
mapread 0x64000 0x1000 0x7495f
on cifs with the default cache option.
It shows read-gaps on folio 0x64 failing with a short read (ie. it hits
EOF) if the FMODE_READ check is commented out in netfs_perform_write():
if (//(file->f_mode & FMODE_READ) ||
netfs_is_cache_enabled(ctx)) {
and no fscache. This was initially found with the generic/522 xfstest. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: ecred_reconfigure: send packed pdu, not stack pointer
Commit 1c08108f3014 ("Bluetooth: L2CAP: Avoid -Wflex-array-member-not-at-end
warnings") converted the on-stack request PDU in l2cap_ecred_reconfigure()
from an explicit packed struct to DEFINE_RAW_FLEX(), but did not adjust the
size and source-pointer arguments to l2cap_send_cmd():
- struct {
- struct l2cap_ecred_reconf_req req;
- __le16 scid;
- } pdu;
+ DEFINE_RAW_FLEX(struct l2cap_ecred_reconf_req, pdu, scid, 1);
...
l2cap_send_cmd(conn, chan->ident, L2CAP_ECRED_RECONF_REQ,
sizeof(pdu), &pdu);
After the conversion, DEFINE_RAW_FLEX() expands to declare an anonymous
union pdu_u plus a local pointer "pdu" pointing at it. Therefore:
- sizeof(pdu) is now sizeof(struct l2cap_ecred_reconf_req *) = 8 on
64-bit (4 on 32-bit), not the 6 bytes of (mtu, mps, scid[1]).
- &pdu is the address of the local pointer's stack storage, not the
address of the request payload.
l2cap_send_cmd() forwards (data, count) to l2cap_build_cmd(), which calls
skb_put_data(skb, data, count). The L2CAP_ECRED_RECONFIGURE_REQ packet
body therefore contains 8 bytes copied from the kernel stack starting at
&pdu -- the 8 bytes overlap the pdu pointer's value, leaking a kernel
stack address to the paired Bluetooth peer. The intended (mtu, mps, scid)
fields are not transmitted at all, so the peer rejects the request as
malformed and the L2CAP_ECRED_RECONFIGURE feature itself has been broken
for the local-side initiator since the introducing commit landed.
The sibling site l2cap_ecred_conn_req() in the same commit was converted
correctly (sizeof(*pdu) + len, pdu); only this site was missed.
Restore the original semantics: pass the full flex-struct size via
struct_size(pdu, scid, 1) and the pdu pointer (the struct address) as
the source.
Validated on a stock 7.0-based host kernel via the real call path:
setsockopt(SOL_BLUETOOTH, BT_RCVMTU, ...) on a BT_CONNECTED
L2CAP_MODE_EXT_FLOWCTL socket emits an L2CAP_ECRED_RECONFIGURE_REQ
whose body is 8 bytes (the on-stack pdu local's value) rather than
the expected 6. Three captures from fresh socket / fresh hciemu peer
on the same host -- low bytes vary per call, high 0xffff confirms a
kernel virtual address (KASLR-randomised stack slot, not a fixed
string):
RECONF_REQ body (ident=0x02 len=8): 42 fb 54 af 0e ca ff ff
RECONF_REQ body (ident=0x02 len=8): 52 3d 2e af 0e ca ff ff
RECONF_REQ body (ident=0x02 len=8): b2 fc 5b af 0e ca ff ff
After this patch the body is 6 bytes carrying the expected
little-endian (mtu, mps, scid). |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Fix page overflow in sev_dbg_crypt() for ENCRYPT path
In sev_dbg_crypt(), the per-iteration transfer length is bounded by
the source page offset (PAGE_SIZE - s_off) but not by the destination
page offset (PAGE_SIZE - d_off). When d_off > s_off, the encrypt
path (__sev_dbg_encrypt_user) performs a read-modify-write using a
single-page intermediate buffer (dst_tpage):
1. __sev_dbg_decrypt() expands the size to round_up(len + (d_off & 15), 16)
before issuing the PSP command. If len + (d_off & 15) > PAGE_SIZE,
the PSP writes beyond the end of the 4096-byte dst_tpage allocation.
2. The subsequent memcpy()/copy_from_user() into
page_address(dst_tpage) + (d_off & 15) of 'len' bytes overflows
by up to 15 bytes under the same condition.
Trigger example: s_off = 0, d_off = 1, debug.len = PAGE_SIZE -
the PSP is instructed to write round_up(4097, 16) = 4112 bytes to
a 4096-byte buffer.
Fix by also bounding len by (PAGE_SIZE - d_off), the same check that
sev_send_update_data() already performs for its single-page guest
region.
==================================================================
BUG: KASAN: slab-use-after-free in sev_dbg_crypt+0x993/0xd10 [kvm_amd]
Write of size 4095 at addr ff110062293bb009 by task sev_dbg_test/228214
CPU: 96 UID: 0 PID: 228214 Comm: sev_dbg_test Tainted: G U W 7.0.0-smp--5ce9b0c48211-dbg #156 PREEMPTLAZY
Tainted: [U]=USER, [W]=WARN
Hardware name: Google Astoria/astoria, BIOS 0.20250817.1-0 08/25/2025
Call Trace:
<TASK>
dump_stack_lvl+0x54/0x70
print_report+0xbc/0x260
kasan_report+0xa2/0xd0
kasan_check_range+0x25f/0x2c0
__asan_memcpy+0x40/0x70
sev_dbg_crypt+0x993/0xd10 [kvm_amd]
sev_mem_enc_ioctl+0x33c/0x450 [kvm_amd]
kvm_vm_ioctl+0x65d/0x6d0 [kvm]
__se_sys_ioctl+0xb2/0x100
do_syscall_64+0xe8/0x870
entry_SYSCALL_64_after_hwframe+0x4b/0x53
</TASK>
The buggy address belongs to the physical page:
page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7fe72b6a0 pfn:0x62293bb
memcg:ff11000112827d82
flags: 0x1400000000000000(node=1|zone=1)
raw: 1400000000000000 0000000000000000 dead000000000122 0000000000000000
raw: 00000007fe72b6a0 0000000000000000 00000001ffffffff ff11000112827d82
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ff110062293bbf00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ff110062293bbf80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ff110062293bc000: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
^
ff110062293bc080: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
ff110062293bc100: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
==================================================================
Disabling lock debugging due to kernel taint
[sean: add sample KASAN splat, Fixes, and stable@] |
| Eclipse Kura versions prior to 5.6.2 trust the client-supplied X-Forwarded-For HTTP header as the authoritative source of the client IP address in audit log entries. The org.eclipse.kura.web2 (Web Console) and org.eclipse.kura.rest.provider (REST API) components use this header as the primary IP source when initializing audit context, and org.eclipse.kura.jetty.customizer unconditionally installs Jetty's ForwardedRequestCustomizer on all HTTP/HTTPS connectors, causing HttpServletRequest.getRemoteAddr() to reflect the attacker-controlled header value. An unauthenticated remote attacker can exploit this vulnerability to bypass IP-based brute-force protections — such as fail2ban — by spoofing the logged IP address to a non-routable value, allowing a brute-force attack to proceed undetected, or to cause a denial of service against a third party by injecting a victim's IP address and triggering a ban on that address. |
| Protection mechanism failure in .NET Framework allows an unauthorized attacker to execute code locally. |
| GD::SecurityImage versions through 1.75 for Perl use rand to generate secrets.
The random method creates the challenge text used for the CAPTCHA by sampling characters from an array using Perl's built-in rand function, and generates a (by default) six-character string.
The built-in rand function is unsuitable for security applications because it is predictable and reversible. |
| HCL Aftermarket EPC is affected by Sensitive Information in GET method & in URL which allows application to pass sensitive data via URL parameters during normal usage. Data passed in this manner can be exposed because it may end up stored in unintended locations, including server logs, local browser history and proxy logs. |
| Dashy is a self-hostable personal dashboard. From 1.9.4 until 3.2.0, the Dashy RSS Widget in src/components/Widgets/RssFeed.vue does not sanitize RSS item link values before rendering feed item titles and Read More links as anchor href attributes, allowing an attacker-controlled feed to provide a javascript: URI that executes when clicked in the Dashy origin. This issue is fixed in version 3.2.0. |
