Vulnerabilities

Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') vulnerability in Iron Mountain Archiving Services Inc. EnVision allows Command Injection.This issue affects enVision: before 250563.

A vulnerability was identified in Campcodes Society Membership Information System 1.0. This issue affects some unknown processing of the file /check_student.php. Such manipulation of the argument student_id leads to sql injection. The attack may be performed from remote. The exploit is publicly available and might be used.

A security flaw has been discovered in Campcodes Gym Management System 1.0. Impacted is an unknown function of the file /ajax.php?action=login. Performing manipulation of the argument Username results in sql injection. It is possible to initiate the attack remotely. The exploit has been released to the public and may be exploited.

A vulnerability has been found in Portabilis i-Educar up to 2.10. Affected by this issue is some unknown functionality of the file /module/Cadastro/aluno. The manipulation of the argument is leads to sql injection. Remote exploitation of the attack is possible. The exploit has been disclosed to the public and may be used.

A vulnerability was found in Portabilis i-Educar up to 2.10. This affects an unknown part of the file /module/ComponenteCurricular/view. The manipulation of the argument ID results in sql injection. The attack can be executed remotely. The exploit has been made public and could be used.

A vulnerability was determined in Portabilis i-Educar up to 2.10. This vulnerability affects unknown code of the file /module/ComponenteCurricular/edit. This manipulation of the argument ID causes sql injection. The attack is possible to be carried out remotely. The exploit has been publicly disclosed and may be utilized.

The CleverControl employee monitoring software (v11.5.1041.6) fails to validate TLS server certificates during the installation process. The installer downloads and executes external components using curl.exe --insecure, enabling a man-in-the-middle attacker to deliver malicious files that are executed with SYSTEM privileges. This can lead to full remote code execution with administrative rights. No patch is available as the vendor has been unresponsive. It is assumed that previous versions are also affected, but this is not confirmed.

The SureForms WordPress plugin before 1.9.1 does not sanitise and escape some parameters when outputing them in the page, which could allow admin and above users to perform Cross-Site Scripting attacks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix subvolume deletion lockup caused by inodes xarray race<br /> <br /> There is a race condition between inode eviction and inode caching that<br /> can cause a live struct btrfs_inode to be missing from the root-&gt;inodes<br /> xarray. Specifically, there is a window during evict() between the inode<br /> being unhashed and deleted from the xarray. If btrfs_iget() is called<br /> for the same inode in that window, it will be recreated and inserted<br /> into the xarray, but then eviction will delete the new entry, leaving<br /> nothing in the xarray:<br /> <br /> Thread 1 Thread 2<br /> ---------------------------------------------------------------<br /> evict()<br /> remove_inode_hash()<br /> btrfs_iget_path()<br /> btrfs_iget_locked()<br /> btrfs_read_locked_inode()<br /> btrfs_add_inode_to_root()<br /> destroy_inode()<br /> btrfs_destroy_inode()<br /> btrfs_del_inode_from_root()<br /> __xa_erase<br /> <br /> In turn, this can cause issues for subvolume deletion. Specifically, if<br /> an inode is in this lost state, and all other inodes are evicted, then<br /> btrfs_del_inode_from_root() will call btrfs_add_dead_root() prematurely.<br /> If the lost inode has a delayed_node attached to it, then when<br /> btrfs_clean_one_deleted_snapshot() calls btrfs_kill_all_delayed_nodes(),<br /> it will loop forever because the delayed_nodes xarray will never become<br /> empty (unless memory pressure forces the inode out). We saw this<br /> manifest as soft lockups in production.<br /> <br /> Fix it by only deleting the xarray entry if it matches the given inode<br /> (using __xa_cmpxchg()).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Tell memcg to use allow_spinning=false path in bpf_timer_init()<br /> <br /> Currently, calling bpf_map_kmalloc_node() from __bpf_async_init() can<br /> cause various locking issues; see the following stack trace (edited for<br /> style) as one example:<br /> <br /> ...<br /> [10.011566] do_raw_spin_lock.cold<br /> [10.011570] try_to_wake_up (5) double-acquiring the same<br /> [10.011575] kick_pool rq_lock, causing a hardlockup<br /> [10.011579] __queue_work<br /> [10.011582] queue_work_on<br /> [10.011585] kernfs_notify<br /> [10.011589] cgroup_file_notify<br /> [10.011593] try_charge_memcg (4) memcg accounting raises an<br /> [10.011597] obj_cgroup_charge_pages MEMCG_MAX event<br /> [10.011599] obj_cgroup_charge_account<br /> [10.011600] __memcg_slab_post_alloc_hook<br /> [10.011603] __kmalloc_node_noprof<br /> ...<br /> [10.011611] bpf_map_kmalloc_node<br /> [10.011612] __bpf_async_init<br /> [10.011615] bpf_timer_init (3) BPF calls bpf_timer_init()<br /> [10.011617] bpf_prog_xxxxxxxxxxxxxxxx_fcg_runnable<br /> [10.011619] bpf__sched_ext_ops_runnable<br /> [10.011620] enqueue_task_scx (2) BPF runs with rq_lock held<br /> [10.011622] enqueue_task<br /> [10.011626] ttwu_do_activate<br /> [10.011629] sched_ttwu_pending (1) grabs rq_lock<br /> ...<br /> <br /> The above was reproduced on bpf-next (b338cf849ec8) by modifying<br /> ./tools/sched_ext/scx_flatcg.bpf.c to call bpf_timer_init() during<br /> ops.runnable(), and hacking the memcg accounting code a bit to make<br /> a bpf_timer_init() call more likely to raise an MEMCG_MAX event.<br /> <br /> We have also run into other similar variants (both internally and on<br /> bpf-next), including double-acquiring cgroup_file_kn_lock, the same<br /> worker_pool::lock, etc.<br /> <br /> As suggested by Shakeel, fix this by using __GFP_HIGH instead of<br /> GFP_ATOMIC in __bpf_async_init(), so that e.g. if try_charge_memcg()<br /> raises an MEMCG_MAX event, we call __memcg_memory_event() with<br /> @allow_spinning=false and avoid calling cgroup_file_notify() there.<br /> <br /> Depends on mm patch<br /> "memcg: skip cgroup_file_notify if spinning is not allowed":<br /> https://lore.kernel.org/bpf/20250905201606.66198-1-shakeel.butt@linux.dev/<br /> <br /> v0 approach s/bpf_map_kmalloc_node/bpf_mem_alloc/<br /> https://lore.kernel.org/bpf/20250905061919.439648-1-yepeilin@google.com/<br /> v1 approach:<br /> https://lore.kernel.org/bpf/20250905234547.862249-1-yepeilin@google.com/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing/osnoise: Fix null-ptr-deref in bitmap_parselist()<br /> <br /> A crash was observed with the following output:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000010<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> CPU: 2 UID: 0 PID: 92 Comm: osnoise_cpus Not tainted 6.17.0-rc4-00201-gd69eb204c255 #138 PREEMPT(voluntary)<br /> RIP: 0010:bitmap_parselist+0x53/0x3e0<br /> Call Trace:<br /> <br /> osnoise_cpus_write+0x7a/0x190<br /> vfs_write+0xf8/0x410<br /> ? do_sys_openat2+0x88/0xd0<br /> ksys_write+0x60/0xd0<br /> do_syscall_64+0xa4/0x260<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> <br /> This issue can be reproduced by below code:<br /> <br /> fd=open("/sys/kernel/debug/tracing/osnoise/cpus", O_WRONLY);<br /> write(fd, "0-2", 0);<br /> <br /> When user pass &amp;#39;count=0&amp;#39; to osnoise_cpus_write(), kmalloc() will return<br /> ZERO_SIZE_PTR (16) and cpulist_parse() treat it as a normal value, which<br /> trigger the null pointer dereference. Add check for the parameter &amp;#39;count&amp;#39;.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fuse: Block access to folio overlimit<br /> <br /> syz reported a slab-out-of-bounds Write in fuse_dev_do_write.<br /> <br /> When the number of bytes to be retrieved is truncated to the upper limit<br /> by fc-&gt;max_pages and there is an offset, the oob is triggered.<br /> <br /> Add a loop termination condition to prevent overruns.