🚨 CVE-2024-39538
A Buffer Copy without Checking Size of Input vulnerability in the PFE management daemon (evo-pfemand) of Juniper Networks Junos OS Evolved on ACX7000 Series allows an unauthenticated, adjacent attacker to cause a 

Denial-of-Service (DoS).When multicast traffic with a specific, valid (S,G) is received, evo-pfemand crashes which leads to an outage of the affected FPC until it is manually recovered.


This issue affects Junos OS Evolved on ACX7000 Series:


* All versions before 21.2R3-S8-EVO,
* 21.4-EVO versions before 21.4R3-S7-EVO,
* 22.2-EVO versions before 22.2R3-S4-EVO,
* 22.3-EVO versions before 22.3R3-S3-EVO, 
* 22.4-EVO versions before 22.4R3-S2-EVO, 
* 23.2-EVO versions before 23.2R2-EVO, 
* 23.4-EVO versions before 23.4R1-S2-EVO, 23.4R2-EVO.

🎖@cveNotify

🚨 CVE-2022-49509
In the Linux kernel, the following vulnerability has been resolved:

media: i2c: max9286: fix kernel oops when removing module

When removing the max9286 module we get a kernel oops:

Unable to handle kernel paging request at virtual address 000000aa00000094
Mem abort info:
ESR = 0x96000004
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x04: level 0 translation fault
Data abort info:
ISV = 0, ISS = 0x00000004
CM = 0, WnR = 0
user pgtable: 4k pages, 48-bit VAs, pgdp=0000000880d85000
[000000aa00000094] pgd=0000000000000000, p4d=0000000000000000
Internal error: Oops: 96000004 [#1] PREEMPT SMP
Modules linked in: fsl_jr_uio caam_jr rng_core libdes caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine max9271 authenc crct10dif_ce mxc_jpeg_encdec
CPU: 2 PID: 713 Comm: rmmod Tainted: G C 5.15.5-00057-gaebcd29c8ed7-dirty #5
Hardware name: Freescale i.MX8QXP MEK (DT)
pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : i2c_mux_del_adapters+0x24/0xf0
lr : max9286_remove+0x28/0xd0 [max9286]
sp : ffff800013a9bbf0
x29: ffff800013a9bbf0 x28: ffff00080b6da940 x27: 0000000000000000
x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
x23: ffff000801a5b970 x22: ffff0008048b0890 x21: ffff800009297000
x20: ffff0008048b0f70 x19: 000000aa00000064 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
x14: 0000000000000014 x13: 0000000000000000 x12: ffff000802da49e8
x11: ffff000802051918 x10: ffff000802da4920 x9 : ffff000800030098
x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d
x5 : 8080808000000000 x4 : 0000000000000000 x3 : 0000000000000000
x2 : ffffffffffffffff x1 : ffff00080b6da940 x0 : 0000000000000000
Call trace:
i2c_mux_del_adapters+0x24/0xf0
max9286_remove+0x28/0xd0 [max9286]
i2c_device_remove+0x40/0x110
__device_release_driver+0x188/0x234
driver_detach+0xc4/0x150
bus_remove_driver+0x60/0xe0
driver_unregister+0x34/0x64
i2c_del_driver+0x58/0xa0
max9286_i2c_driver_exit+0x1c/0x490 [max9286]
__arm64_sys_delete_module+0x194/0x260
invoke_syscall+0x48/0x114
el0_svc_common.constprop.0+0xd4/0xfc
do_el0_svc+0x2c/0x94
el0_svc+0x28/0x80
el0t_64_sync_handler+0xa8/0x130
el0t_64_sync+0x1a0/0x1a4

The Oops happens because the I2C client data does not point to
max9286_priv anymore but to v4l2_subdev. The change happened in
max9286_init() which calls v4l2_i2c_subdev_init() later on...

Besides fixing the max9286_remove() function, remove the call to
i2c_set_clientdata() in max9286_probe(), to avoid confusion, and make
the necessary changes to max9286_init() so that it doesn't have to use
i2c_get_clientdata() in order to fetch the pointer to priv.

🎖@cveNotify

🚨 CVE-2024-50394
An improper certificate validation vulnerability has been reported to affect Helpdesk. If exploited, the vulnerability could allow remote attackers to compromise the security of the system.

We have already fixed the vulnerability in the following version:
Helpdesk 3.3.3 and later

🎖@cveNotify

🚨 CVE-2025-38503
In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix assertion when building free space tree

When building the free space tree with the block group tree feature
enabled, we can hit an assertion failure like this:

BTRFS info (device loop0 state M): rebuilding free space tree
assertion failed: ret == 0, in fs/btrfs/free-space-tree.c:1102
------------[ cut here ]------------
kernel BUG at fs/btrfs/free-space-tree.c:1102!
Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
Modules linked in:
CPU: 1 UID: 0 PID: 6592 Comm: syz-executor322 Not tainted 6.15.0-rc7-syzkaller-gd7fa1af5b33e #0 PREEMPT
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102
lr : populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102
sp : ffff8000a4ce7600
x29: ffff8000a4ce76e0 x28: ffff0000c9bc6000 x27: ffff0000ddfff3d8
x26: ffff0000ddfff378 x25: dfff800000000000 x24: 0000000000000001
x23: ffff8000a4ce7660 x22: ffff70001499cecc x21: ffff0000e1d8c160
x20: ffff0000e1cb7800 x19: ffff0000e1d8c0b0 x18: 00000000ffffffff
x17: ffff800092f39000 x16: ffff80008ad27e48 x15: ffff700011e740c0
x14: 1ffff00011e740c0 x13: 0000000000000004 x12: ffffffffffffffff
x11: ffff700011e740c0 x10: 0000000000ff0100 x9 : 94ef24f55d2dbc00
x8 : 94ef24f55d2dbc00 x7 : 0000000000000001 x6 : 0000000000000001
x5 : ffff8000a4ce6f98 x4 : ffff80008f415ba0 x3 : ffff800080548ef0
x2 : 0000000000000000 x1 : 0000000100000000 x0 : 000000000000003e
Call trace:
populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102 (P)
btrfs_rebuild_free_space_tree+0x14c/0x54c fs/btrfs/free-space-tree.c:1337
btrfs_start_pre_rw_mount+0xa78/0xe10 fs/btrfs/disk-io.c:3074
btrfs_remount_rw fs/btrfs/super.c:1319 [inline]
btrfs_reconfigure+0x828/0x2418 fs/btrfs/super.c:1543
reconfigure_super+0x1d4/0x6f0 fs/super.c:1083
do_remount fs/namespace.c:3365 [inline]
path_mount+0xb34/0xde0 fs/namespace.c:4200
do_mount fs/namespace.c:4221 [inline]
__do_sys_mount fs/namespace.c:4432 [inline]
__se_sys_mount fs/namespace.c:4409 [inline]
__arm64_sys_mount+0x3e8/0x468 fs/namespace.c:4409
__invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49
el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132
do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151
el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767
el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786
el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600
Code: f0047182 91178042 528089c3 9771d47b (d4210000)
---[ end trace 0000000000000000 ]---

This happens because we are processing an empty block group, which has
no extents allocated from it, there are no items for this block group,
including the block group item since block group items are stored in a
dedicated tree when using the block group tree feature. It also means
this is the block group with the highest start offset, so there are no
higher keys in the extent root, hence btrfs_search_slot_for_read()
returns 1 (no higher key found).

Fix this by asserting 'ret' is 0 only if the block group tree feature
is not enabled, in which case we should find a block group item for
the block group since it's stored in the extent root and block group
item keys are greater than extent item keys (the value for
BTRFS_BLOCK_GROUP_ITEM_KEY is 192 and for BTRFS_EXTENT_ITEM_KEY and
BTRFS_METADATA_ITEM_KEY the values are 168 and 169 respectively).
In case 'ret' is 1, we just need to add a record to the free space
tree which spans the whole block group, and we can achieve this by
making 'ret == 0' as the while loop's condition.

🎖@cveNotify

🚨 CVE-2025-38514
In the Linux kernel, the following vulnerability has been resolved:

rxrpc: Fix oops due to non-existence of prealloc backlog struct

If an AF_RXRPC service socket is opened and bound, but calls are
preallocated, then rxrpc_alloc_incoming_call() will oops because the
rxrpc_backlog struct doesn't get allocated until the first preallocation is
made.

Fix this by returning NULL from rxrpc_alloc_incoming_call() if there is no
backlog struct. This will cause the incoming call to be aborted.

🎖@cveNotify

🚨 CVE-2024-32706
Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in Repute info systems ARForms.This issue affects ARForms: from n/a through 6.4.

🎖@cveNotify

🚨 CVE-2024-32702
Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in Repute info systems ARForms allows Reflected XSS.This issue affects ARForms: from n/a through 6.4.

🎖@cveNotify

🚨 CVE-2024-54216
Path Traversal: '.../...//' vulnerability in Repute InfoSystems ARForms allows Path Traversal.This issue affects ARForms: from n/a through 6.4.1.

🎖@cveNotify

🚨 CVE-2024-54217
Missing Authorization vulnerability in Repute info systems ARForms.This issue affects ARForms: from n/a through 6.4.1.

🎖@cveNotify

🚨 CVE-2025-31125
Vite is a frontend tooling framework for javascript. Vite exposes content of non-allowed files using ?inline&import or ?raw?import. Only apps explicitly exposing the Vite dev server to the network (using --host or server.host config option) are affected. This vulnerability is fixed in 6.2.4, 6.1.3, 6.0.13, 5.4.16, and 4.5.11.

🎖@cveNotify

🚨 CVE-2025-34026
The Versa Concerto SD-WAN orchestration platform is vulnerable to an authentication bypass in the Traefik reverse proxy configuration, allowing at attacker to access administrative endpoints. The internal Actuator endpoint can be leveraged for access to heap dumps and trace logs.This issue is known to affect Concerto from 12.1.2 through 12.2.0. Additional versions may be vulnerable.

🎖@cveNotify

🚨 CVE-2024-32107
Cross-Site Request Forgery (CSRF) vulnerability in XLPlugins Finale Lite.This issue affects Finale Lite: from n/a through 2.18.0.

🎖@cveNotify

🚨 CVE-2024-32104
Cross-Site Request Forgery (CSRF) vulnerability in XLPlugins NextMove Lite.This issue affects NextMove Lite: from n/a through 2.18.1.

🎖@cveNotify

🚨 CVE-2023-47180
Missing Authorization vulnerability in XLPlugins Finale Lite allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Finale Lite: from n/a through 2.16.0.

🎖@cveNotify

🚨 CVE-2023-51409
Unrestricted Upload of File with Dangerous Type vulnerability in Jordy Meow AI Engine: ChatGPT Chatbot.This issue affects AI Engine: ChatGPT Chatbot: from n/a through 1.9.98.

🎖@cveNotify

🚨 CVE-2024-35871
In the Linux kernel, the following vulnerability has been resolved:

riscv: process: Fix kernel gp leakage

childregs represents the registers which are active for the new thread
in user context. For a kernel thread, childregs->gp is never used since
the kernel gp is not touched by switch_to. For a user mode helper, the
gp value can be observed in user space after execve or possibly by other
means.

[From the email thread]

The /* Kernel thread */ comment is somewhat inaccurate in that it is also used
for user_mode_helper threads, which exec a user process, e.g. /sbin/init or
when /proc/sys/kernel/core_pattern is a pipe. Such threads do not have
PF_KTHREAD set and are valid targets for ptrace etc. even before they exec.

childregs is the *user* context during syscall execution and it is observable
from userspace in at least five ways:

1. kernel_execve does not currently clear integer registers, so the starting
register state for PID 1 and other user processes started by the kernel has
sp = user stack, gp = kernel __global_pointer$, all other integer registers
zeroed by the memset in the patch comment.

This is a bug in its own right, but I'm unwilling to bet that it is the only
way to exploit the issue addressed by this patch.

2. ptrace(PTRACE_GETREGSET): you can PTRACE_ATTACH to a user_mode_helper thread
before it execs, but ptrace requires SIGSTOP to be delivered which can only
happen at user/kernel boundaries.

3. /proc/*/task/*/syscall: this is perfectly happy to read pt_regs for
user_mode_helpers before the exec completes, but gp is not one of the
registers it returns.

4. PERF_SAMPLE_REGS_USER: LOCKDOWN_PERF normally prevents access to kernel
addresses via PERF_SAMPLE_REGS_INTR, but due to this bug kernel addresses
are also exposed via PERF_SAMPLE_REGS_USER which is permitted under
LOCKDOWN_PERF. I have not attempted to write exploit code.

5. Much of the tracing infrastructure allows access to user registers. I have
not attempted to determine which forms of tracing allow access to user
registers without already allowing access to kernel registers.

🎖@cveNotify

🚨 CVE-2023-52882
In the Linux kernel, the following vulnerability has been resolved:

clk: sunxi-ng: h6: Reparent CPUX during PLL CPUX rate change

While PLL CPUX clock rate change when CPU is running from it works in
vast majority of cases, now and then it causes instability. This leads
to system crashes and other undefined behaviour. After a lot of testing
(30+ hours) while also doing a lot of frequency switches, we can't
observe any instability issues anymore when doing reparenting to stable
clock like 24 MHz oscillator.

🎖@cveNotify

🚨 CVE-2024-36883
In the Linux kernel, the following vulnerability has been resolved:

net: fix out-of-bounds access in ops_init

net_alloc_generic is called by net_alloc, which is called without any
locking. It reads max_gen_ptrs, which is changed under pernet_ops_rwsem. It
is read twice, first to allocate an array, then to set s.len, which is
later used to limit the bounds of the array access.

It is possible that the array is allocated and another thread is
registering a new pernet ops, increments max_gen_ptrs, which is then used
to set s.len with a larger than allocated length for the variable array.

Fix it by reading max_gen_ptrs only once in net_alloc_generic. If
max_gen_ptrs is later incremented, it will be caught in net_assign_generic.

🎖@cveNotify

🚨 CVE-2024-36600
Buffer Overflow Vulnerability in libcdio 2.2.0 (fixed in 2.3.0) allows an attacker to execute arbitrary code via a crafted ISO 9660 image file.

🎖@cveNotify

🚨 CVE-2024-21586
An Improper Check for Unusual or Exceptional Conditions vulnerability in the Packet Forwarding Engine (PFE) of Juniper Networks Junos OS on SRX Series and NFX Series allows an unauthenticated, network-based attacker to cause a Denial-of-Service (DoS).

If an affected device receives specific valid traffic destined to the device, it will cause the PFE to crash and restart. Continued receipt and processing of this traffic will create a sustained DoS condition.

This issue affects Junos OS on SRX Series:

* 21.4 versions before 21.4R3-S7.9,
* 22.1 versions before 22.1R3-S5.3,
* 22.2 versions before 22.2R3-S4.11,
* 22.3 versions before 22.3R3,
* 22.4 versions before 22.4R3.






This issue affects Junos OS on NFX Series:

* 21.4 versions before 21.4R3-S8,
* 22.1 versions after 22.1R1,
* 22.2 versions before 22.2R3-S5,
* 22.3 versions before 22.3R3,
* 22.4 versions before 22.4R3.






Junos OS versions prior to 21.4R1 are not affected by this issue.

🎖@cveNotify

🚨 CVE-2024-39560
An Improper Handling of Exceptional Conditions vulnerability in the routing protocol daemon (rpd) of Juniper Networks Junos OS and Junos OS Evolved allows a logically adjacent downstream RSVP neighbor to cause kernel memory exhaustion, leading to a kernel crash, resulting in a Denial of Service (DoS).

The kernel memory leak and eventual crash will be seen when the downstream RSVP neighbor has a persistent error which will not be corrected.

System kernel memory can be monitored through the use of the 'show system kernel memory' command as shown below:

user@router> show system kernel memory  
Real memory total/reserved: 4130268/ 133344 Kbytes
kmem map free: 18014398509110220 Kbytes

This issue affects:
Junos OS:


* All versions before 20.4R3-S9,
* All versions of 21.2,
* from 21.4 before 21.4R3-S5,
* from 22.1 before 22.1R3-S5,
* from 22.2 before 22.2R3-S3,
* from 22.3 before 22.3R3-S2,
* from 22.4 before 22.4R3,
* from 23.2 before 23.2R2;


Junos OS Evolved:


* All versions before 21.4R3-S5-EVO,
* from 22.1-EVO before 22.1R3-S5-EVO,
* from 22.2-EVO before 22.2R3-S3-EVO,
* from 22.3-EVO before 22.3R3-S2-EVO,
* from 22.4-EVO before 22.4R3-EVO,
* from 23.2-EVO before 23.2R2-EVO.

🎖@cveNotify