| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A vulnerability has been found in Dromara lamp-cloud up to 5.6.2. Impacted is the function GroovyClassLoader.parseClass of the component Message Template Handler. Such manipulation of the argument DefMsgTemplate.content leads to improper neutralization of special elements used in a template engine. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way. |
| IBM Db2 12.1.0 through 12.1.4 is vulnerable to authorization bypass when uploading to a remote object storage path with a special query. |
| libusb before version 1.0.30 contains a one-byte out-of-bounds read vulnerability in parse_iad_array() in descriptor.c that allows attackers to trigger a denial of service by supplying a malformed USB descriptor whose bLength equals size minus one, causing the bounds check to use the original buffer size instead of the remaining size. Attackers in virtualized environments with USB passthrough can supply crafted descriptors through libusb_get_active_interface_association_descriptors or libusb_get_interface_association_descriptors to read one byte past the end of the malloc allocation, resulting in a denial of service. |
| When creating an export through the pretix API, API clients are
returned an UUID value for their export job (a long, random string like
35742818-c375-4d15-839f-d49aecce94d6). Using this UUID, the API client
can then request the actual file for download. The same kind of UUID is
used in other places in pretix when temporary files are generated for
internal use or download.
One remaining API endpoint, however, wrongfully did not verify if the
UUID used for download actually belongs to a file that is supposed to
be downloadable and belongs to the correct user. In reality, this is
hard to exploit because an attacker would need to have access to a valid
UUID for the file they desire which is unlikely to happen without a
separate security problem giving them access to logs etc. |
| OpenRapid RapidCMS v1.3.1 was discovered to contain an authentication bypass in the /template/default/menu.php component. This vulnerability is exploited via injecting a crafted SQL payload into the name cookie parameter. |
| Ella Core is a 5G core designed for private networks. Prior to 1.10.0, Ella Core does not verify the UE Security Capabilities received in NGAP PathSwitchRequest messages against its locally stored values. A malicious gNB can overwrite Ella Core's stored UE security capabilities for any UE with arbitrary values by sending a single crafted PathSwitchRequest. This vulnerability is fixed in 1.10.0. |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_set_rbtree: check for partial overlaps in anonymous sets
Userspace provides an optimized representation in case intervals are
adjacent, where the end element is omitted.
The existing partial overlap detection logic skips anonymous set checks
on start elements for this reason.
However, it is possible to add intervals that overlap to this anonymous
where two start elements with the same, eg. A-B, A-C where C < B.
start end
A B
start end
A C
Restore the check on overlapping start elements to report an overlap. |
| In the Linux kernel, the following vulnerability has been resolved:
PCI/P2PDMA: Release per-CPU pgmap ref when vm_insert_page() fails
When vm_insert_page() fails in p2pmem_alloc_mmap(), p2pmem_alloc_mmap()
doesn't invoke percpu_ref_put() to free the per-CPU ref of pgmap acquired
after gen_pool_alloc_owner(), and memunmap_pages() will hang forever when
trying to remove the PCI device.
Fix it by adding the missed percpu_ref_put(). |
| In the Linux kernel, the following vulnerability has been resolved:
octeon_ep_vf: add NULL check for napi_build_skb()
napi_build_skb() can return NULL on allocation failure. In
__octep_vf_oq_process_rx(), the result is used directly without a NULL
check in both the single-buffer and multi-fragment paths, leading to a
NULL pointer dereference.
Add NULL checks after both napi_build_skb() calls, properly advancing
descriptors and consuming remaining fragments on failure. |
| A weakness has been identified in Totolink CA750-PoE 6.2c.510. Impacted is the function setUpgradeUboot of the file /cgi-bin/cstecgi.cgi of the component Setting Handler. This manipulation of the argument FileName causes os command injection. The attack is possible to be carried out remotely. The exploit has been made available to the public and could be used for attacks. |
| In the Linux kernel, the following vulnerability has been resolved:
sched/rt: Skip currently executing CPU in rto_next_cpu()
CPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound
RT task, and a CFS task stuck in kernel space. When other CPUs switch from
RT to non-RT tasks, RT load balancing (LB) is triggered; with
HAVE_RT_PUSH_IPI enabled, they send IPIs to CPU0 to drive the execution
of rto_push_irq_work_func. During push_rt_task on CPU0,
if next_task->prio < rq->donor->prio, resched_curr() sets NEED_RESCHED
and after the push operation completes, CPU0 calls rto_next_cpu().
Since only CPU0 is overloaded in this scenario, rto_next_cpu() should
ideally return -1 (no further IPI needed).
However, multiple CPUs invoking tell_cpu_to_push() during LB increments
rd->rto_loop_next. Even when rd->rto_cpu is set to -1, the mismatch between
rd->rto_loop and rd->rto_loop_next forces rto_next_cpu() to restart its
search from -1. With CPU0 remaining overloaded (satisfying rt_nr_migratory
&& rt_nr_total > 1), it gets reselected, causing CPU0 to queue irq_work to
itself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and
other CPUs run pull_rt_tasks(), it falls into an infinite self-IPI loop,
which triggers a CPU hardlockup due to continuous self-interrupts.
The trigging scenario is as follows:
cpu0 cpu1 cpu2
pull_rt_task
tell_cpu_to_push
<------------irq_work_queue_on
rto_push_irq_work_func
push_rt_task
resched_curr(rq) pull_rt_task
rto_next_cpu tell_cpu_to_push
<-------------------------- atomic_inc(rto_loop_next)
rd->rto_loop != next
rto_next_cpu
irq_work_queue_on
rto_push_irq_work_func
Fix redundant self-IPI by filtering the initiating CPU in rto_next_cpu().
This solution has been verified to effectively eliminate spurious self-IPIs
and prevent CPU hardlockup scenarios. |
| In the Linux kernel, the following vulnerability has been resolved:
ksmbd: call ksmbd_vfs_kern_path_end_removing() on some error paths
There are two places where ksmbd_vfs_kern_path_end_removing() needs to be
called in order to balance what the corresponding successful call to
ksmbd_vfs_kern_path_start_removing() has done, i.e. drop inode locks and
put the taken references. Otherwise there might be potential deadlocks
and unbalanced locks which are caught like:
BUG: workqueue leaked lock or atomic: kworker/5:21/0x00000000/7596
last function: handle_ksmbd_work
2 locks held by kworker/5:21/7596:
#0: ffff8881051ae448 (sb_writers#3){.+.+}-{0:0}, at: ksmbd_vfs_kern_path_locked+0x142/0x660
#1: ffff888130e966c0 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: ksmbd_vfs_kern_path_locked+0x17d/0x660
CPU: 5 PID: 7596 Comm: kworker/5:21 Not tainted 6.1.162-00456-gc29b353f383b #138
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014
Workqueue: ksmbd-io handle_ksmbd_work
Call Trace:
<TASK>
dump_stack_lvl+0x44/0x5b
process_one_work.cold+0x57/0x5c
worker_thread+0x82/0x600
kthread+0x153/0x190
ret_from_fork+0x22/0x30
</TASK>
Found by Linux Verification Center (linuxtesting.org). |
| In the Linux kernel, the following vulnerability has been resolved:
thermal/of: Fix reference leak in thermal_of_cm_lookup()
In thermal_of_cm_lookup(), tr_np is obtained via of_parse_phandle(), but
never released.
Use the __free(device_node) cleanup attribute to automatically release
the node and fix the leak.
[ rjw: Changelog edits ] |
| In the Linux kernel, the following vulnerability has been resolved:
rust: pwm: Fix potential memory leak on init error
When initializing a PWM chip using pwmchip_alloc(), the allocated device
owns an initial reference that must be released on all error paths.
If __pinned_init() were to fail, the allocated pwm_chip would currently
leak because the error path returns without calling pwmchip_put(). |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: inside-secure/eip93 - fix kernel panic in driver detach
During driver detach, the same hash algorithm is unregistered multiple
times due to a wrong iterator. |
| In the Linux kernel, the following vulnerability has been resolved:
power: supply: pm8916_lbc: Fix use-after-free in power_supply_changed()
Using the `devm_` variant for requesting IRQ _before_ the `devm_`
variant for allocating/registering the `power_supply` handle, means that
the `power_supply` handle will be deallocated/unregistered _before_ the
interrupt handler (since `devm_` naturally deallocates in reverse
allocation order). This means that during removal, there is a race
condition where an interrupt can fire just _after_ the `power_supply`
handle has been freed, *but* just _before_ the corresponding
unregistration of the IRQ handler has run.
This will lead to the IRQ handler calling `power_supply_changed()` with
a freed `power_supply` handle. Which usually crashes the system or
otherwise silently corrupts the memory...
Note that there is a similar situation which can also happen during
`probe()`; the possibility of an interrupt firing _before_ registering
the `power_supply` handle. This would then lead to the nasty situation
of using the `power_supply` handle *uninitialized* in
`power_supply_changed()`.
Fix this racy use-after-free by making sure the IRQ is requested _after_
the registration of the `power_supply` handle. |
| In the Linux kernel, the following vulnerability has been resolved:
gpib: Fix memory leak in ni_usb_init()
In ni_usb_init(), if ni_usb_setup_init() fails, the function returns
-EFAULT without freeing the allocated writes buffer, leading to a
memory leak.
Additionally, ni_usb_setup_init() returns 0 on failure, which causes
ni_usb_init() to return -EFAULT, an inappropriate error code for this
situation.
Fix the leak by freeing writes in the error path. Modify
ni_usb_setup_init() to return -EINVAL on failure and propagate this
error code in ni_usb_init(). |
| In the Linux kernel, the following vulnerability has been resolved:
tpm: tpm_i2c_infineon: Fix locality leak on get_burstcount() failure
get_burstcount() can return -EBUSY on timeout. When this happens, the
function returns directly without releasing the locality that was
acquired at the beginning of tpm_tis_i2c_send().
Use goto out_err to ensure proper cleanup when get_burstcount() fails. |
| In the Linux kernel, the following vulnerability has been resolved:
fbdev: pxafb: Fix possible use after free in pxafb_task()
In the pxafb_probe function, it calls the pxafb_init_fbinfo function,
after which &fbi->task is associated with pxafb_task. Moreover,
within this pxafb_init_fbinfo function, the pxafb_blank function
within the &pxafb_ops struct is capable of scheduling work.
If we remove the module which will call pxafb_remove to make cleanup,
it will call unregister_framebuffer function which can call
do_unregister_framebuffer to free fbi->fb through
put_fb_info(fb_info), while the work mentioned above will be used.
The sequence of operations that may lead to a UAF bug is as follows:
CPU0 CPU1
| pxafb_task
pxafb_remove |
unregister_framebuffer(info) |
do_unregister_framebuffer(fb_info) |
put_fb_info(fb_info) |
// free fbi->fb | set_ctrlr_state(fbi, state)
| __pxafb_lcd_power(fbi, 0)
| fbi->lcd_power(on, &fbi->fb.var)
| //use fbi->fb
Fix it by ensuring that the work is canceled before proceeding
with the cleanup in pxafb_remove.
Note that only root user can remove the driver at runtime. |
| Budibase is an open-source low-code platform. Prior to 3.38.1, the row action trigger endpoint (POST /api/tables/:sourceId/actions/:actionId/trigger) fails to validate that the user-supplied rowId is within the scope of the view's row filters. A user with access to a filtered view can trigger row actions on any row in the underlying table, including rows explicitly excluded by the view's security filters. This vulnerability is fixed in 3.38.1. |
