| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Citizen is a MediaWiki skin that makes extensions part of the cohesive experience. Citizen from 3.3.0 to 3.9.0 are vulnerable to stored cross-site scripting in the sticky header button message handling. In stickyHeader.js the copyButtonAttributes function assigns innerHTML from a source element’s textContent when copying button labels. This causes escaped HTML in system message content (such as citizen-share, citizen-view-history, citizen-view-edit, and nstab-talk) to be interpreted as HTML in the sticky header, allowing injection of arbitrary script by a user with the ability to edit interface messages. The vulnerability allows a user with the editinterface right but without the editsitejs right (by default the sysop group has editinterface but may not have editsitejs) to execute arbitrary JavaScript in other users’ sessions, enabling unauthorized access to sensitive data or actions. The issue is fixed in 3.9.0. |
| In the Linux kernel, the following vulnerability has been resolved:
net: mscc: ocelot: Fix use-after-free caused by cyclic delayed work
The origin code calls cancel_delayed_work() in ocelot_stats_deinit()
to cancel the cyclic delayed work item ocelot->stats_work. However,
cancel_delayed_work() may fail to cancel the work item if it is already
executing. While destroy_workqueue() does wait for all pending work items
in the work queue to complete before destroying the work queue, it cannot
prevent the delayed work item from being rescheduled within the
ocelot_check_stats_work() function. This limitation exists because the
delayed work item is only enqueued into the work queue after its timer
expires. Before the timer expiration, destroy_workqueue() has no visibility
of this pending work item. Once the work queue appears empty,
destroy_workqueue() proceeds with destruction. When the timer eventually
expires, the delayed work item gets queued again, leading to the following
warning:
workqueue: cannot queue ocelot_check_stats_work on wq ocelot-switch-stats
WARNING: CPU: 2 PID: 0 at kernel/workqueue.c:2255 __queue_work+0x875/0xaf0
...
RIP: 0010:__queue_work+0x875/0xaf0
...
RSP: 0018:ffff88806d108b10 EFLAGS: 00010086
RAX: 0000000000000000 RBX: 0000000000000101 RCX: 0000000000000027
RDX: 0000000000000027 RSI: 0000000000000004 RDI: ffff88806d123e88
RBP: ffffffff813c3170 R08: 0000000000000000 R09: ffffed100da247d2
R10: ffffed100da247d1 R11: ffff88806d123e8b R12: ffff88800c00f000
R13: ffff88800d7285c0 R14: ffff88806d0a5580 R15: ffff88800d7285a0
FS: 0000000000000000(0000) GS:ffff8880e5725000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fe18e45ea10 CR3: 0000000005e6c000 CR4: 00000000000006f0
Call Trace:
<IRQ>
? kasan_report+0xc6/0xf0
? __pfx_delayed_work_timer_fn+0x10/0x10
? __pfx_delayed_work_timer_fn+0x10/0x10
call_timer_fn+0x25/0x1c0
__run_timer_base.part.0+0x3be/0x8c0
? __pfx_delayed_work_timer_fn+0x10/0x10
? rcu_sched_clock_irq+0xb06/0x27d0
? __pfx___run_timer_base.part.0+0x10/0x10
? try_to_wake_up+0xb15/0x1960
? _raw_spin_lock_irq+0x80/0xe0
? __pfx__raw_spin_lock_irq+0x10/0x10
tmigr_handle_remote_up+0x603/0x7e0
? __pfx_tmigr_handle_remote_up+0x10/0x10
? sched_balance_trigger+0x1c0/0x9f0
? sched_tick+0x221/0x5a0
? _raw_spin_lock_irq+0x80/0xe0
? __pfx__raw_spin_lock_irq+0x10/0x10
? tick_nohz_handler+0x339/0x440
? __pfx_tmigr_handle_remote_up+0x10/0x10
__walk_groups.isra.0+0x42/0x150
tmigr_handle_remote+0x1f4/0x2e0
? __pfx_tmigr_handle_remote+0x10/0x10
? ktime_get+0x60/0x140
? lapic_next_event+0x11/0x20
? clockevents_program_event+0x1d4/0x2a0
? hrtimer_interrupt+0x322/0x780
handle_softirqs+0x16a/0x550
irq_exit_rcu+0xaf/0xe0
sysvec_apic_timer_interrupt+0x70/0x80
</IRQ>
...
The following diagram reveals the cause of the above warning:
CPU 0 (remove) | CPU 1 (delayed work callback)
mscc_ocelot_remove() |
ocelot_deinit() | ocelot_check_stats_work()
ocelot_stats_deinit() |
cancel_delayed_work()| ...
| queue_delayed_work()
destroy_workqueue() | (wait a time)
| __queue_work() //UAF
The above scenario actually constitutes a UAF vulnerability.
The ocelot_stats_deinit() is only invoked when initialization
failure or resource destruction, so we must ensure that any
delayed work items cannot be rescheduled.
Replace cancel_delayed_work() with disable_delayed_work_sync()
to guarantee proper cancellation of the delayed work item and
ensure completion of any currently executing work before the
workqueue is deallocated.
A deadlock concern was considered: ocelot_stats_deinit() is called
in a process context and is not holding any locks that the delayed
work item might also need. Therefore, the use of the _sync() variant
is safe here.
This bug was identified through static analysis. To reproduce the
issue and validate the fix, I simulated ocelot-swit
---truncated--- |
| The Redirection for Contact Form 7 plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin's qs_date shortcode in all versions up to, and including, 3.2.6 due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: mvsas: Fix use-after-free bugs in mvs_work_queue
During the detaching of Marvell's SAS/SATA controller, the original code
calls cancel_delayed_work() in mvs_free() to cancel the delayed work
item mwq->work_q. However, if mwq->work_q is already running, the
cancel_delayed_work() may fail to cancel it. This can lead to
use-after-free scenarios where mvs_free() frees the mvs_info while
mvs_work_queue() is still executing and attempts to access the
already-freed mvs_info.
A typical race condition is illustrated below:
CPU 0 (remove) | CPU 1 (delayed work callback)
mvs_pci_remove() |
mvs_free() | mvs_work_queue()
cancel_delayed_work() |
kfree(mvi) |
| mvi-> // UAF
Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure
that the delayed work item is properly canceled and any executing
delayed work item completes before the mvs_info is deallocated.
This bug was found by static analysis. |
| In the Linux kernel, the following vulnerability has been resolved:
thunderbolt: Fix use-after-free in tb_dp_dprx_work
The original code relies on cancel_delayed_work() in tb_dp_dprx_stop(),
which does not ensure that the delayed work item tunnel->dprx_work has
fully completed if it was already running. This leads to use-after-free
scenarios where tb_tunnel is deallocated by tb_tunnel_put(), while
tunnel->dprx_work remains active and attempts to dereference tb_tunnel
in tb_dp_dprx_work().
A typical race condition is illustrated below:
CPU 0 | CPU 1
tb_dp_tunnel_active() |
tb_deactivate_and_free_tunnel()| tb_dp_dprx_start()
tb_tunnel_deactivate() | queue_delayed_work()
tb_dp_activate() |
tb_dp_dprx_stop() | tb_dp_dprx_work() //delayed worker
cancel_delayed_work() |
tb_tunnel_put(tunnel); |
| tunnel = container_of(...); //UAF
| tunnel-> //UAF
Replacing cancel_delayed_work() with cancel_delayed_work_sync() is
not feasible as it would introduce a deadlock: both tb_dp_dprx_work()
and the cleanup path acquire tb->lock, and cancel_delayed_work_sync()
would wait indefinitely for the work item that cannot proceed.
Instead, implement proper reference counting:
- If cancel_delayed_work() returns true (work is pending), we release
the reference in the stop function.
- If it returns false (work is executing or already completed), the
reference is released in delayed work function itself.
This ensures the tb_tunnel remains valid during work item execution
while preventing memory leaks.
This bug was found by static analysis. |
| A vulnerability was identified in toeverything AFFiNE up to 0.24.1. This vulnerability affects unknown code of the component Avatar Upload Image Endpoint. Such manipulation leads to cross site scripting. The attack may be launched remotely. The exploit is publicly available and might be used. The vendor was contacted early about this disclosure but did not respond in any way. |
| Photo module is affected by information leak vulnerability, successful exploitation of this vulnerability may affect service confidentiality. |
| In the Linux kernel, the following vulnerability has been resolved:
net/9p: Fix buffer overflow in USB transport layer
A buffer overflow vulnerability exists in the USB 9pfs transport layer
where inconsistent size validation between packet header parsing and
actual data copying allows a malicious USB host to overflow heap buffers.
The issue occurs because:
- usb9pfs_rx_header() validates only the declared size in packet header
- usb9pfs_rx_complete() uses req->actual (actual received bytes) for
memcpy
This allows an attacker to craft packets with small declared size
(bypassing validation) but large actual payload (triggering overflow
in memcpy).
Add validation in usb9pfs_rx_complete() to ensure req->actual does not
exceed the buffer capacity before copying data. |
| A vulnerability was identified in thinkgem JeeSite up to 5.12.0. This vulnerability affects unknown code of the file modules/core/src/main/java/com/jeesite/common/ueditor/ActionEnter.java of the component UEditor Image Grabber. Such manipulation of the argument Source leads to server-side request forgery. The attack may be performed from remote. The exploit is publicly available and might be used. The name of the patch is 1c5e49b0818037452148e0f8ff69ed04cb8fefdc. It is advisable to implement a patch to correct this issue. |
| A flaw was found in the libssh library in versions less than 0.11.2. An out-of-bounds read can be triggered in the sftp_handle function due to an incorrect comparison check that permits the function to access memory beyond the valid handle list and to return an invalid pointer, which is used in further processing. This vulnerability allows an authenticated remote attacker to potentially read unintended memory regions, exposing sensitive information or affect service behavior. |
| A vulnerability has been found in Tomofun Furbo 360 and Furbo Mini. Impacted is an unknown function of the file TF_FQDN.json of the component GATT Interface URL Handler. Such manipulation leads to server-side request forgery. The attack may be performed from remote. Attacks of this nature are highly complex. The exploitability is considered difficult. The firmware versions determined to be affected are Furbo 360 up to FB0035_FW_036 and Furbo Mini up to MC0020_FW_074. The vendor was contacted early about this disclosure but did not respond in any way. |
| A security flaw has been discovered in Mangati NovoSGA up to 2.2.9. The impacted element is an unknown function of the file /admin of the component SVG File Handler. Performing manipulation of the argument logoNavbar/logoLogin results in cross site scripting. Remote exploitation of the attack is possible. The exploit has been released to the public and may be exploited. |
| A vulnerability was identified in Portabilis i-Educar up to 2.10. Impacted is an unknown function of the file /intranet/educar_calendario_anotacao_cad.php. Such manipulation of the argument nm_anotacao/descricao leads to cross site scripting. It is possible to launch the attack remotely. The exploit is publicly available and might be used. |
| A security vulnerability has been detected in Portabilis i-Educar up to 2.10. The affected element is an unknown function of the file /intranet/educar_turma_tipo_cad.php. Such manipulation of the argument nm_tipo leads to cross site scripting. It is possible to launch the attack remotely. The exploit has been disclosed publicly and may be used. |
| A weakness has been identified in Portabilis i-Educar up to 2.10. Impacted is an unknown function of the file /intranet/educar_modulo_cad.php. This manipulation of the argument nm_tipo/descricao causes cross site scripting. It is possible to initiate the attack remotely. The exploit has been made available to the public and could be exploited. |
| A vulnerability was determined in Tomofun Furbo 360 and Furbo Mini. The impacted element is an unknown function of the file /etc/shadow of the component Password Handler. Executing manipulation can lead to use of weak hash. The physical device can be targeted for the attack. The attack requires a high level of complexity. The exploitability is regarded as difficult. The exploit has been publicly disclosed and may be utilized. The firmware versions determined to be affected are Furbo 360 up to FB0035_FW_036 and Furbo Mini up to MC0020_FW_074. The vendor was contacted early about this disclosure but did not respond in any way. |
| A vulnerability was found in Tomofun Furbo 360 and Furbo Mini. The affected element is an unknown function of the component Root Account Handler. Performing manipulation results in use of hard-coded password. The attack must be initiated from a local position. The attack is considered to have high complexity. The exploitability is described as difficult. The exploit has been made public and could be used. The firmware versions determined to be affected are Furbo 360 up to FB0035_FW_036 and Furbo Mini up to MC0020_FW_074. The vendor was contacted early about this disclosure but did not respond in any way. |
| It is possible to cause an use-after-free write in SANM decoding with a carefully crafted animation using subversion <2.
When a STOR chunk is present, a subsequent FOBJ chunk will be saved in ctx->stored_frame. Stored frames can later be referenced by FTCH chunks. For files using subversion < 2, the undecoded frame is stored, and decoded again when the FTCH chunks are parsed. However, in process_frame_obj if the frame has an invalid size, there’s an early return, with a value of 0.
This causes the code in decode_frame to still store the raw frame buffer into ctx->stored_frame. Leaving ctx->has_dimensions set to false.
A subsequent chunk with type FTCH would call process_ftch and decode that frame obj again, adding to the top/left values and calling process_frame_obj again.
Given that we never set ctx->have_dimensions before, this time we set the dimensions, calling init_buffers, which can reallocate the buffer in ctx->stored_frame, freeing the previous one. However, the GetByteContext object gb still holds a reference to the old buffer.
Finally, when the code tries to decode the frame, codecs that accept a GetByteContext as a parameter will trigger a use-after-free read when using gb.
GetByteContext is only used for reading bytes, so at most one could read invalid data. There are no heap allocations between the free and when the object is accessed. However, upon returning to process_ftch, the code restores the original values for top/left in stored_frame, writing 4 bytes to the freed data at offset 6, potentially corrupting the allocator’s metadata.
This issue can be triggered just by probing whether a file has the sanm format.
We recommend upgrading to version 8.0 or beyond. |
| When decoding an OpenEXR file that uses DWAA or DWAB compression, there's an implicit assumption that all image channels have the same pixel type (and size), and that if there are four channels, the first four are "B", "G", "R" and "A". The channel parsing code can be found in decode_header. The buffer td->uncompressed_data is allocated in decode_block based on the xsize, ysize and computed current_channel_offset.
The function dwa_uncompress then assumes at [5] that if there are 4 channels, these are "B", "G", "R" and "A", and in the calculations at [6] and [7] that all channels are of the same type, which matches the type of the main color channels.
If we set the main color channels to a 4-byte type and add duplicate or unknown channels of the 2-byte EXR_HALF type, then the addition at [7] will increment the pointer by 4-bytes * xsize * nb_channels, which will exceed the allocated buffer.
We recommend upgrading to version 8.0 or beyond. |
| When decoding an OpenEXR file that uses DWAA or DWAB compression, there's an implicit assumption that the height and width are divisible by 8.
If the height or width of the image is not divisible by 8, the copy loops at [0] and [1] will continue to write until the next multiple of 8.
The buffer td->uncompressed_data is allocated in decode_block based on the precise height and width of the image, so the "rounded-up" multiple of 8 in the copy loop can exceed the buffer bounds, and the write block starting at [2] can corrupt following heap memory.
We recommend upgrading to version 8.0 or beyond. |
