| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Mealie before 3.21.0 fails to validate user ownership in the ratings and favorites endpoints, allowing authenticated attackers to read any user's recipe ratings and favorites by specifying arbitrary user IDs in the URL path. Attackers can access private recipe identifiers, rating values, and favorite flags belonging to other users across different groups or households. |
| In the Linux kernel, the following vulnerability has been resolved:
net/smc: free pending qentry in smc_llc_flow_stop() before memset
smc_llc_flow_stop() resets a flow struct with a blind memset:
spin_lock_bh(&lgr->llc_flow_lock);
memset(flow, 0, sizeof(*flow));
flow->type = SMC_LLC_FLOW_NONE;
spin_unlock_bh(&lgr->llc_flow_lock);
If flow->qentry is non-NULL at this point the pointer is overwritten without the
allocation being freed, leaking one kmalloc object.
A late-arriving duplicate CONFIRM_LINK or ADD_LINK_CONT message can set
flow->qentry after the legitimate message has been consumed by the waiter via
smc_llc_flow_qentry_clr() (which NULLs the pointer but leaves flow->type
non-zero) but before the flow completes and smc_llc_flow_stop() runs. In that
window the duplicate is stashed into flow->qentry, and then lost when
smc_llc_flow_stop() zeros the struct.
Call smc_llc_flow_qentry_del() inside the lock before the memset.
smc_llc_flow_qentry_del() already checks flow->qentry before freeing, so the
normal case where no entry is pending is a no-op. |
| In the Linux kernel, the following vulnerability has been resolved:
net: sched: fix 32-bit backlog wrap in gred, bfifo and plug enqueue
gred_enqueue(), bfifo_enqueue() and plug_enqueue() admit a packet when the
current backlog plus the packet length fits within the queue limit:
sch->qstats.backlog + qdisc_pkt_len(skb) <= sch->limit (gred default VQ)
gred_backlog+qdisc_pkt_len(skb) <= q->limit (gred configured VQ)
sch->qstats.backlog + qdisc_pkt_len(skb) <= sch->limit (bfifo)
sch->qstats.backlog + skb->len <= q->limit (plug)
sch->qstats.backlog and q->backlog are u32, and qdisc_pkt_len()/skb->len
are unsigned int, so all sums are computed in 32 bits and wrap at 2^32.
Once the true backlog exceeds 4 GiB the wrapped sum becomes small and
admission keeps succeeding, so the queue grows without bound and the kernel
can be driven to OOM.
Promote the sums to u64 so admission stops once the true backlog exceeds
the limit. The limit is u32, so the bounded queue stays below 2^32 and
the stored u32 backlog never wraps.
The bug can only be reproduced as root (albeit with ridiculous setup):
attach a gred (or bfifo/plug) qdisc with a limit near 4 GiB,
leaving the default VQ unconfigured (for gred), and drive >4 GiB of
queued traffic (e.g. via a size table / stab to inflate qdisc_pkt_len,
or sustained high-rate traffic). The u32 backlog+len sum wraps at 2^32,
admission keeps succeeding, and the queue grows unboundedly to OOM. |
| In the Linux kernel, the following vulnerability has been resolved:
xsk: fix NULL pointer dereference in __xsk_rcv()
In the __xsk_rcv() multi-buffer path, xsk_buff_alloc() is called in a
loop without checking its return value. xsk_buff_can_alloc() only
counts fill queue entries without validating their addresses, so it
can succeed while xsk_buff_alloc() rejects all remaining entries and
returns NULL.
Oops: general protection fault, probably for non-canonical address
0xdffffc0000000000
KASAN: null-ptr-deref in range
[0x0000000000000000-0x0000000000000007]
RIP: 0010:__xsk_rcv+0x426/0xc20 (net/xdp/xsk.c:350)
Call Trace:
xsk_generic_rcv+0x26d/0x5f0
xdp_do_generic_redirect+0x3c5/0xcf0
do_xdp_generic+0x92f/0xe70
__netif_receive_skb_core.constprop.0+0xf7e/0x2b30
Fix this with a two-stage transaction. First allocate and stage all
buffers required for the packet, recycling all staged buffers with
xsk_buff_free() if any allocation fails. Only after this stage
succeeds, copy the data, reserve the RX descriptors, and release the
buffers in an error-free loop. |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: mtpav: shut down output timer before card teardown
snd_mtpav_output_timer() rearms chip->timer while holding
chip->spinlock and accesses the card-private mtpav state.
snd_mtpav_free() currently takes the same lock and calls
timer_delete() when the timer is active. This only removes a
pending timer; it does not wait for a callback that is already
running and does not prevent the callback from rearming the timer.
A callback running on another CPU can therefore continue after
snd_mtpav_free() releases the lock and access the card-private
state while the card is being torn down. It can also rearm the
timer after timer_delete() has returned.
Call timer_shutdown_sync() without holding chip->spinlock. This
waits for any running callback to finish and prevents further
rearming before the card-private mtpav state is released. |
| In the Linux kernel, the following vulnerability has been resolved:
virtio_balloon: quiesce balloon work before device shutdown
Commit 8bd2fa086a04 ("virtio: break and reset virtio devices on
device_shutdown()") added a generic virtio bus .shutdown handler that
breaks and resets every virtio device during device_shutdown(), i.e. on
reboot and kexec.
virtio_balloon provides no .shutdown of its own, so that generic path
runs while the balloon's asynchronous work is still armed. Once the
device has been broken, virtqueue_add_inbuf() in
virtballoon_free_page_report() returns -EIO and trips its
WARN_ON_ONCE(). On a kernel booted with panic_on_warn that turns an
ordinary reboot, for example a kexec based upgrade, into a fatal panic
in the middle of device_shutdown(), so the machine never reaches the
new kernel.
Relaxing that single WARN_ON_ONCE() would only hide the symptom: the
inflate/deflate and OOM paths do not warn, they call
wait_event(vb->acked, ...) and would instead block forever on a broken
queue that can no longer complete. The device has to be quiesced, not
just kept quiet.
Add a .shutdown handler that quiesces the balloon via the shared
virtballoon_quiesce() helper while the device is still alive, and only
then breaks and resets it via virtio_device_shutdown(). Unlike
virtballoon_remove() the balloon workqueue is not destroyed, as shutdown
does not free the device and cancel_work_sync() together with stop_update
already prevent any further work from being queued. |
| In the Linux kernel, the following vulnerability has been resolved:
vdpa_sim: fix cleanup after worker creation failure
vdpasim_create() leaves vdpasim->worker as an ERR_PTR when
kthread_run_worker() fails. The error path then drops the device
reference, which releases the partially initialized simulator.
vdpasim_free() unconditionally passes the worker pointer to
kthread_destroy_worker(), so the ERR_PTR is dereferenced and can trigger
a general protection fault.
Store the worker error, clear the pointer, and only clean up the worker
when it was successfully initialized. Also make the release path tolerate
partially initialized objects by guarding virtqueue and IOTLB cleanup,
since the same release path can be reached from other initialization
failures.
I found this bug myself, though the patch was written with AI assistance. |
| In the Linux kernel, the following vulnerability has been resolved:
net: add missing ref_tracker_dir_exit() to alloc_netdev_mqs()
sashiko is reporting that trying to read /sys/kernel/debug/ref_tracker/*
causes use-afer-free crash when either alloc_percpu() or dev_addr_init()
in alloc_netdev_mqs() failed, for commit 4d92b95ff2f9 ("net: add net device
refcount tracker infrastructure") added ref_tracker_dir_exit() to only
free_netdev() path. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/x86/amd/hsmp: Reject negative power cap writes in hwmon
hsmp_hwmon_write() takes the user-supplied hwmon value as a signed long
and assigns "val / MICROWATT_PER_MILLIWATT" to msg.args[0], which is a
__u32. MICROWATT_PER_MILLIWATT is an unsigned long, so a negative write
to power1_cap (e.g. "echo -1 > power1_cap") is first converted to a huge
unsigned value by the division and then stored into the u32 argument.
As a result a nonsensical, multi-gigawatt socket power limit is sent to
the SMU via HSMP_SET_SOCKET_POWER_LIMIT instead of the write being
rejected.
Reject negative values with -EINVAL before the conversion.
Tested with HSMP enabled:
CAP=$(dirname $(grep -l amd_hsmp_hwmon \
/sys/class/hwmon/hwmon*/name | head -1))/power1_cap
# negative write
echo -1000000 > $CAP ; echo "ret=$?"
# valid positive write must still work
echo 400000000 > $CAP ; echo "ret=$?"
Before:
# echo -1000000 > $CAP ; echo "ret=$?"
ret=0 <- accepted; bogus limit sent to SMU
# echo 400000000 > $CAP ; echo "ret=$?"
ret=0
After:
# echo -1000000 > $CAP ; echo "ret=$?"
bash: echo: write error: Invalid argument
ret=1 <- rejected with -EINVAL
# echo 400000000 > $CAP ; echo "ret=$?"
ret=0 <- valid write still works |
| In the Linux kernel, the following vulnerability has been resolved:
platform/x86: hp-bioscfg: fix password encoding bounds check
The password PSWD_ENCODINGS parser reads password_obj[elem + pos_values]
while copying the supported password encodings from the ACPI package.
The outer loop only guarantees that elem is within password_obj_count.
The encoding count is bounded by MAX_ENCODINGS_SIZE, but that does not
guarantee that the ACPI package contains enough entries for all
elem + pos_values accesses.
A malformed package can therefore declare a non-zero encoding count
without providing enough string objects, causing the parser to read past
the ACPI package array and pass an out-of-bounds string pointer and
length to hp_convert_hexstr_to_str().
Add the same computed-index bounds check used by the other offset-based
package parsing loops before reading password_obj[elem + pos_values]. |
| In the Linux kernel, the following vulnerability has been resolved:
vsock: don't check the listener's sk_err in vsock_accept()
Syzbot reported an issue which can be reproduced with these steps:
r0 = socket(AF_VSOCK, SOCK_STREAM, 0)
bind(r0, {VMADDR_CID_ANY, PORT})
connect(r0, {VMADDR_CID_LOCAL, PORT}) -> -1, EPROTO (self-connect)
listen(r0, backlog) -> 0
r1 = socket(AF_VSOCK, SOCK_STREAM, 0)
connect(r1, {VMADDR_CID_LOCAL, PORT}) -> 0
accept(r0) -> -1, EPROTO (stale sk_err)
Basically, it creates a socket (r0) and triggers a self-connect after
binding it. This self-connect fails with EPROTO because it loops back
to r0 while the socket is still in the TCP_SYN_SENT state, causing it
to be incorrectly dispatched to the connecting-client path. The
unexpected packet type encountered there sets sk_err to EPROTO.
After that, it invokes a listen() call on the same socket. This
listen() call succeeds because the kernel's listening path never
inspects or clears sk_err. Then, a new socket (r1) is created as a
normal client and connects to r0. However, vsock_accept() rejects this
incoming connection because the listener's sk_err still holds the
EPROTO error from the earlier failed self-connect.
This rejection causes the child socket created for r1's connection to
never be freed on virtio or hyperv transports; only the VMCI transport
implements pending_work to revisit and clean up a rejected socket.
For a non-blocking connect(), vsock_connect() may return -EINPROGRESS
immediately, and vsock_connect_timeout() can later set sk->sk_err
asynchronously.
Since no vsock transport ever sets sk_err on a socket while it is in
TCP_LISTEN state, checking it in vsock_accept() serves no purpose and
only carries forward errors left behind by earlier, unrelated
connection attempts on the same socket. Remove the checks so accept()
no longer rejects valid incoming connections because of a stale
error, which also avoids the resource leak described above. |
| A cross-site scripting (XSS) vulnerability has been reported to affect QcalAgent. The local attackers can then exploit the vulnerability to bypass security mechanisms or read application data.
We have already fixed the vulnerability in the following version:
QcalAgent 1.1.9 and later |
| Improper handling of length parameter inconsistency vulnerability in ABB Freelance Controller DCP, ABB Freelance Controller AC700, ABB Freelance Controller AC800, and ABB Freelance Controller AC900.
This issue affects Freelance Controller DCP: through 2013, 2013 SP1, 2016, 2016 SP1, 2019, and 2019 SP1; Freelance Controller AC700: through 2013, 2013 SP1, 2016, 2016 SP1, 2019, and 2019 SP1; Freelance Controller AC800: through 2013, 2013 SP1, 2016, 2016 SP1, 2019, and 2019 SP1; Freelance Controller AC900: through 2013, 2013 SP1, 2016, 2016 SP1, 2019, and 2019 SP1. |
| OpenImageIO is a toolset for reading, writing, and manipulating image files of any image file format relevant to VFX / animation. Prior to 3.0.20.0, 3.1.15.0, and 3.2.0.3-beta1, A crafted cineon file can supply a numberofelements value greater than the format maximum of eight. cineoninput::open() uses that unchecked value as the loop bound while filling the fixed strings[8] array, writing pointers beyond the stack buffer and into adjacent state, resulting in memory corruption and denial of service. The affected implementation is identified by src/cineon.imageio/cineoninput.cpp, CineonInput::open(), numberOfElements, and strings[8], which define the relevant source path, functions, state, and trigger. This issue is fixed in versions 3.0.20.0, 3.1.15.0, and 3.2.0.3-beta1. |
| NanoMQ is an MQTT broker. Prior to 0.24.14, NanoMQ's broker-side MQTT v5 nmq_subinfo_decode() function in nng/src/sp/protocol/mqtt/mqtt_parser.c reuses len_of_varint from the outer Properties Length while parsing each SUBSCRIPTION_IDENTIFIER. A remote client can send a SUBSCRIBE packet with a multi-byte Properties Length and repeated subscription identifiers, causing get_var_integer() to begin at an incorrect offset and read beyond the heap message buffer. The flaw is reachable through the broker receive path and can crash the broker, while the separately reported topic-option off-by-one occurs later and is not this vulnerability. This issue is fixed in version 0.24.14. |
| A vulnerability was identified in Totolink A3002MU Hh-B20211125.1046. Affected is the function formWlEncrypt of the file /boafrm/formWlEncrypt. The manipulation of the argument submit-url leads to buffer overflow. It is possible to initiate the attack remotely. The exploit is publicly available and might be used. |
| A flaw was found in the OpenShift console. Unauthenticated access to the `/api/devfile/` and `/api/devfile/samples/` endpoints allows a remote attacker to send crafted devfile payloads. This can lead to Server-Side Request Forgery (SSRF), where the console pod makes requests to internal services and reflects partial responses to the attacker. Additionally, by sending repeated large requests without a specified content length, an attacker can cause unbounded memory growth, leading to a Denial of Service (DoS). |
| Cross Site Scripting vulnerability in Moonshot AI Kimi version as of 2026-07-18 allows a remote attacker to execute arbitrary code via the HTML artifact Preview rendering; public Share view component |
| A flaw was found in RESTEasy's IIOImageProvider, which decodes attacker-supplied image request bodies without enforcing any limit on the declared image dimensions or pixel count. A remote, unauthenticated attacker can send a small crafted image declaring enormous dimensions to trigger a very large memory allocation, exhausting the JVM heap and resulting in a denial of service. |
| A denial of service flaw was found in Poppler's Splash backend. A crafted PDF with tiling-pattern geometry approaching the int32 boundary can cause SplashOutputDev::tilingPatternFill to compute an attacker-controlled repeat count that drives an excessively long loop in the pattern-fill scanline routine, without a corresponding memory allocation. An attacker could exploit this by supplying a malicious PDF to an application that renders it via Poppler's Splash backend, causing the rendering process to consume 100% CPU for an attacker-controlled, extended duration. |
