| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| BentoML is a Python library for building online serving systems optimized for AI apps and model inference. Prior to 1.4.39, src/bentoml/_internal/container/frontend/dockerfile/templates/base_v2.j2 interpolates docker.base_image raw with no escaping, newline filtering, or validation. A malicious bento.yaml with a multi-line docker.base_image value smuggles arbitrary Dockerfile directives into the generated Dockerfile, and bentoml containerize then runs docker build which executes the injected RUN directives on the victim host. This vulnerability is fixed in 1.4.39. |
| Cinny is a Matrix client. Prior to 4.10.3, A remote authenticated attacker who shares a room with a victim and has permissions to create room emotes (for example in a DM) can cause the victim's client to send their Matrix access token to an attacker-controlled server. This occurs when the victim opens the emoji or sticker picker for the room containing a malicious emote pack. This is caused by an incorrect fallback in EmojiBoard that uses untrusted pack.meta.avatar (user-controlled) without converting/validating it as an MXC URL, allowing arbitrary HTTP(S) URLs to be used. Also, the service worker attaching the user's Authorization bearer token to all outbound GET requests whose URL contains /_matrix/client/v1/media/download or /_matrix/client/v1/media/thumbnail without verifying the request host matches the configured homeserver origin. An attacker-controlled URL containing those path fragments and permissive CORS will receive the victim's Authorization header (access token). This vulnerability is fixed in 4.10.3. |
| Unspecified vulnerability in IBM Java 8 before SR1 allows remote attackers to cause a denial of service via unknown vectors related to SSL/TLS and the Secure Socket Extension provider. |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: atmel-tdes - fix DMA sync direction
Before DMA output is consumed by the CPU, ->dma_addr_out must be synced
with dma_sync_single_for_cpu() instead of dma_sync_single_for_device().
Using the wrong direction can return stale cache data on non-coherent
platforms. |
| In the Linux kernel, the following vulnerability has been resolved:
erofs: fix the out-of-bounds nameoff handling for trailing dirents
Currently we already have boundary-checks for nameoffs, but the trailing
dirents are special since the namelens are calculated with strnlen()
with unchecked nameoffs.
If a crafted EROFS has a trailing dirent with nameoff >= maxsize,
maxsize - nameoff can underflow, causing strnlen() to read past the
directory block.
nameoff0 should also be verified to be a multiple of
`sizeof(struct erofs_dirent)` as well [1].
[1] https://sashiko.dev/#/patchset/20260416063511.3173774-1-hsiangkao%40linux.alibaba.com |
| IBM App Connect Enterprise 13.0.1.0 through 13.0.7.0 stores potentially sensitive information in log files that could be read by a local user. |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: acomp - fix wrong pointer stored by acomp_save_req()
acomp_save_req() stores &req->chain in req->base.data. When
acomp_reqchain_done() is invoked on asynchronous completion, it receives
&req->chain as the data argument but casts it directly to struct
acomp_req. Since data points to the chain member, all subsequent field
accesses are at a wrong offset, resulting in memory corruption.
The issue occurs when an asynchronous hardware implementation, such as
the QAT driver, completes a request that uses the DMA virtual address
interface (e.g. acomp_request_set_src_dma()). This combination causes
crypto_acomp_compress() to enter the acomp_do_req_chain() path, which
sets acomp_reqchain_done() as the completion callback via
acomp_save_req().
With KASAN enabled, this manifests as a general protection fault in
acomp_reqchain_done():
general protection fault, probably for non-canonical address 0xe000040000000000
KASAN: probably user-memory-access in range [0x0000400000000000-0x0000400000000007]
RIP: 0010:acomp_reqchain_done+0x15b/0x4e0
Call Trace:
<IRQ>
qat_comp_alg_callback+0x5d/0xa0 [intel_qat]
adf_ring_response_handler+0x376/0x8b0 [intel_qat]
adf_response_handler+0x60/0x170 [intel_qat]
tasklet_action_common+0x223/0x820
handle_softirqs+0x1ab/0x640
</IRQ>
Fix this by storing the request itself in req->base.data instead of
&req->chain, so that acomp_reqchain_done() receives the correct pointer.
Simplify acomp_restore_req() accordingly to access req->chain directly. |
| IBM Web Server Plug-ins for WebSphere Application Server and WebSphere Liberty 8.5, 9.0 IBM WebSphere Application Server and WebSphere Application Server Liberty are vulnerable to remote code execution in the Web Server Plug-ins, through a specially crafted request. |
| Privilege escalation via background service of OpenVPN Connect 3.5.1 through 3.8.1 on macOS allows attackers to execute arbitrary commands with elevated privileges via local IPC channel |
| An insecure password scheme refers to vulnerabilities arising from improper selection of encryption algorithms, inadequate key management, or flawed code implementation, which may lead to data leakage or tampering, such as hard-coded keys or the use of weak encryption algorithms. |
| Hitachi Vantara Pentaho Data Integration & Analytics versions before 10.2.0.7 and 11.0.0.0, including 9.3.x and 8.3.x, does not prevent certain XML parsers from resolving external entities. |
| Hitachi Vantara Pentaho Data Integration & Analytics versions before 10.2.0.6 and 11.0.0.0, including 9.3.x and 8.3.x, expose Hadoop cluster credentials in plain text through the Cluster Test API. Although the user should not see those explicitly, the defect is mitigated by the fact the user can already leverage those credentials to submit jobs under the same account through the backend API. |
| In the Linux kernel, the following vulnerability has been resolved:
spi: fix resource leaks on device setup failure
Make sure to call controller cleanup() if spi_setup() fails while
registering a device to avoid leaking any resources allocated by
setup(). |
| In the Linux kernel, the following vulnerability has been resolved:
net: bridge: use a stable FDB dst snapshot in RCU readers
Local FDB entries can be rewritten in place by `fdb_delete_local()`, which
updates `f->dst` to another port or to `NULL` while keeping the entry
alive. Several bridge RCU readers inspect `f->dst`, including
`br_fdb_fillbuf()` through the `brforward_read()` sysfs path.
These readers currently load `f->dst` multiple times and can therefore
observe inconsistent values across the check and later dereference.
In `br_fdb_fillbuf()`, this means a concurrent local-FDB update can change
`f->dst` after the NULL check and before the `port_no` dereference,
leading to a NULL-ptr-deref.
Fix this by taking a single `READ_ONCE()` snapshot of `f->dst` in each
affected RCU reader and using that snapshot for the rest of the access
sequence. Also publish the in-place `f->dst` updates in `fdb_delete_local()`
with `WRITE_ONCE()` so the readers and writer use matching access patterns. |
| In the Linux kernel, the following vulnerability has been resolved:
mm/damon/stat: fix memory leak on damon_start() failure in damon_stat_start()
Destroy the DAMON context and reset the global pointer when damon_start()
fails. Otherwise, the context allocated by damon_stat_build_ctx() is
leaked, and the stale damon_stat_context pointer will be overwritten on
the next enable attempt, making the old allocation permanently
unreachable. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw88: check for PCI upstream bridge existence
pci_upstream_bridge() returns NULL if the device is on a root bus. If
8821CE is installed in the system with such a PCI topology, the probing
routine will crash. This has probably been unnoticed as 8821CE is mostly
supplied in laptops where there is a PCI-to-PCI bridge located upstream
from the device. However the card might be installed on a system with
different configuration.
Check if the bridge does exist for the specific workaround to be applied.
Found by Linux Verification Center (linuxtesting.org) with Svace static
analysis tool. |
| In the Linux kernel, the following vulnerability has been resolved:
tpm2-sessions: Fix missing tpm_buf_destroy() in tpm2_read_public()
tpm2_read_public() calls tpm_buf_init() but fails to call
tpm_buf_destroy() on two exit paths, leaking a page allocation:
1. When name_size() returns an error (unrecognized hash algorithm),
the function returns directly without destroying the buffer.
2. On the success path, the buffer is never destroyed before
returning.
All other error paths in the function correctly call
tpm_buf_destroy() before returning.
Fix both by adding the missing tpm_buf_destroy() calls. |
| In the Linux kernel, the following vulnerability has been resolved:
Input: edt-ft5x06 - fix use-after-free in debugfs teardown
The commit 68743c500c6e ("Input: edt-ft5x06 - use per-client debugfs
directory") removed the manual debugfs teardown, relying on the I2C core
to handle it. However, this creates a window where debugfs files are
still accessible after edt_ft5x06_ts_teardown_debugfs() frees
tsdata->raw_buffer.
To prevent a use-after-free, protect the freeing of raw_buffer with the
device mutex and set raw_buffer to NULL. The debugfs read function
already checks if raw_buffer is NULL under the same mutex, so this
safely avoids the use-after-free. |
| In the Linux kernel, the following vulnerability has been resolved:
net: ipv6: fix NOREF dst use in seg6 and rpl lwtunnels
seg6_input_core() and rpl_input() call ip6_route_input() which sets a
NOREF dst on the skb, then pass it to dst_cache_set_ip6() invoking
dst_hold() unconditionally.
On PREEMPT_RT, ksoftirqd is preemptible and a higher-priority task can
release the underlying pcpu_rt between the lookup and the caching
through a concurrent FIB lookup on a shared nexthop.
Simplified race sequence:
ksoftirqd/X higher-prio task (same CPU X)
----------- --------------------------------
seg6_input_core(,skb)/rpl_input(skb)
dst_cache_get()
-> miss
ip6_route_input(skb)
-> ip6_pol_route(,skb,flags)
[RT6_LOOKUP_F_DST_NOREF in flags]
-> FIB lookup resolves fib6_nh
[nhid=N route]
-> rt6_make_pcpu_route()
[creates pcpu_rt, refcount=1]
pcpu_rt->sernum = fib6_sernum
[fib6_sernum=W]
-> cmpxchg(fib6_nh.rt6i_pcpu,
NULL, pcpu_rt)
[slot was empty, store succeeds]
-> skb_dst_set_noref(skb, dst)
[dst is pcpu_rt, refcount still 1]
rt_genid_bump_ipv6()
-> bumps fib6_sernum
[fib6_sernum from W to Z]
ip6_route_output()
-> ip6_pol_route()
-> FIB lookup resolves fib6_nh
[nhid=N]
-> rt6_get_pcpu_route()
pcpu_rt->sernum != fib6_sernum
[W <> Z, stale]
-> prev = xchg(rt6i_pcpu, NULL)
-> dst_release(prev)
[prev is pcpu_rt,
refcount 1->0, dead]
dst = skb_dst(skb)
[dst is the dead pcpu_rt]
dst_cache_set_ip6(dst)
-> dst_hold() on dead dst
-> WARN / use-after-free
For the race to occur, ksoftirqd must be preemptible (PREEMPT_RT without
PREEMPT_RT_NEEDS_BH_LOCK) and a concurrent task must be able to release
the pcpu_rt. Shared nexthop objects provide such a path, as two routes
pointing to the same nhid share the same fib6_nh and its rt6i_pcpu
entry.
Fix seg6_input_core() and rpl_input() by calling skb_dst_force() after
ip6_route_input() to force the NOREF dst into a refcounted one before
caching.
The output path is not affected as ip6_route_output() already returns a
refcounted dst. |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: reject zero shift in nft_bitwise
Reject zero shift operands for nft_bitwise left and right shift
expressions during initialization.
The carry propagation logic computes the carry from the adjacent 32-bit
word using BITS_PER_TYPE(u32) - shift. A zero shift operand turns this
into a 32-bit shift, which is undefined behaviour.
Reject zero shift operands in the control plane, alongside the existing
check for values greater than or equal to 32, so malformed rules never
reach the packet path. |
