Vulnerabilities

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 /> mm/memory-failure: fix VM_BUG_ON_PAGE(PagePoisoned(page)) when unpoison memory<br /> <br /> When I did memory failure tests, below panic occurs:<br /> <br /> page dumped because: VM_BUG_ON_PAGE(PagePoisoned(page))<br /> kernel BUG at include/linux/page-flags.h:616!<br /> Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 3 PID: 720 Comm: bash Not tainted 6.10.0-rc1-00195-g148743902568 #40<br /> RIP: 0010:unpoison_memory+0x2f3/0x590<br /> RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246<br /> RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8<br /> RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0<br /> RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb<br /> R10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000<br /> R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe<br /> FS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> unpoison_memory+0x2f3/0x590<br /> simple_attr_write_xsigned.constprop.0.isra.0+0xb3/0x110<br /> debugfs_attr_write+0x42/0x60<br /> full_proxy_write+0x5b/0x80<br /> vfs_write+0xd5/0x540<br /> ksys_write+0x64/0xe0<br /> do_syscall_64+0xb9/0x1d0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f08f0314887<br /> RSP: 002b:00007ffece710078 EFLAGS: 00000246 ORIG_RAX: 0000000000000001<br /> RAX: ffffffffffffffda RBX: 0000000000000009 RCX: 00007f08f0314887<br /> RDX: 0000000000000009 RSI: 0000564787a30410 RDI: 0000000000000001<br /> RBP: 0000564787a30410 R08: 000000000000fefe R09: 000000007fffffff<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000009<br /> R13: 00007f08f041b780 R14: 00007f08f0417600 R15: 00007f08f0416a00<br /> <br /> Modules linked in: hwpoison_inject<br /> ---[ end trace 0000000000000000 ]---<br /> RIP: 0010:unpoison_memory+0x2f3/0x590<br /> RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246<br /> RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8<br /> RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0<br /> RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb<br /> R10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000<br /> R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe<br /> FS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0<br /> Kernel panic - not syncing: Fatal exception<br /> Kernel Offset: 0x31c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)<br /> ---[ end Kernel panic - not syncing: Fatal exception ]---<br /> <br /> The root cause is that unpoison_memory() tries to check the PG_HWPoison<br /> flags of an uninitialized page. So VM_BUG_ON_PAGE(PagePoisoned(page)) is<br /> triggered. This can be reproduced by below steps:<br /> <br /> 1.Offline memory block:<br /> <br /> echo offline &gt; /sys/devices/system/memory/memory12/state<br /> <br /> 2.Get offlined memory pfn:<br /> <br /> page-types -b n -rlN<br /> <br /> 3.Write pfn to unpoison-pfn<br /> <br /> echo &gt; /sys/kernel/debug/hwpoison/unpoison-pfn<br /> <br /> This scenario can be identified by pfn_to_online_page() returning NULL. <br /> And ZONE_DEVICE pages are never expected, so we can simply fail if<br /> pfn_to_online_page() == NULL to fix the bug.

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 /> ocfs2: fix recursive semaphore deadlock in fiemap call<br /> <br /> syzbot detected a OCFS2 hang due to a recursive semaphore on a<br /> FS_IOC_FIEMAP of the extent list on a specially crafted mmap file.<br /> <br /> context_switch kernel/sched/core.c:5357 [inline]<br /> __schedule+0x1798/0x4cc0 kernel/sched/core.c:6961<br /> __schedule_loop kernel/sched/core.c:7043 [inline]<br /> schedule+0x165/0x360 kernel/sched/core.c:7058<br /> schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7115<br /> rwsem_down_write_slowpath+0x872/0xfe0 kernel/locking/rwsem.c:1185<br /> __down_write_common kernel/locking/rwsem.c:1317 [inline]<br /> __down_write kernel/locking/rwsem.c:1326 [inline]<br /> down_write+0x1ab/0x1f0 kernel/locking/rwsem.c:1591<br /> ocfs2_page_mkwrite+0x2ff/0xc40 fs/ocfs2/mmap.c:142<br /> do_page_mkwrite+0x14d/0x310 mm/memory.c:3361<br /> wp_page_shared mm/memory.c:3762 [inline]<br /> do_wp_page+0x268d/0x5800 mm/memory.c:3981<br /> handle_pte_fault mm/memory.c:6068 [inline]<br /> __handle_mm_fault+0x1033/0x5440 mm/memory.c:6195<br /> handle_mm_fault+0x40a/0x8e0 mm/memory.c:6364<br /> do_user_addr_fault+0x764/0x1390 arch/x86/mm/fault.c:1387<br /> handle_page_fault arch/x86/mm/fault.c:1476 [inline]<br /> exc_page_fault+0x76/0xf0 arch/x86/mm/fault.c:1532<br /> asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:623<br /> RIP: 0010:copy_user_generic arch/x86/include/asm/uaccess_64.h:126 [inline]<br /> RIP: 0010:raw_copy_to_user arch/x86/include/asm/uaccess_64.h:147 [inline]<br /> RIP: 0010:_inline_copy_to_user include/linux/uaccess.h:197 [inline]<br /> RIP: 0010:_copy_to_user+0x85/0xb0 lib/usercopy.c:26<br /> Code: e8 00 bc f7 fc 4d 39 fc 72 3d 4d 39 ec 77 38 e8 91 b9 f7 fc 4c 89<br /> f7 89 de e8 47 25 5b fd 0f 01 cb 4c 89 ff 48 89 d9 4c 89 f6 a4 0f<br /> 1f 00 48 89 cb 0f 01 ca 48 89 d8 5b 41 5c 41 5d 41 5e 41<br /> RSP: 0018:ffffc9000403f950 EFLAGS: 00050256<br /> RAX: ffffffff84c7f101 RBX: 0000000000000038 RCX: 0000000000000038<br /> RDX: 0000000000000000 RSI: ffffc9000403f9e0 RDI: 0000200000000060<br /> RBP: ffffc9000403fa90 R08: ffffc9000403fa17 R09: 1ffff92000807f42<br /> R10: dffffc0000000000 R11: fffff52000807f43 R12: 0000200000000098<br /> R13: 00007ffffffff000 R14: ffffc9000403f9e0 R15: 0000200000000060<br /> copy_to_user include/linux/uaccess.h:225 [inline]<br /> fiemap_fill_next_extent+0x1c0/0x390 fs/ioctl.c:145<br /> ocfs2_fiemap+0x888/0xc90 fs/ocfs2/extent_map.c:806<br /> ioctl_fiemap fs/ioctl.c:220 [inline]<br /> do_vfs_ioctl+0x1173/0x1430 fs/ioctl.c:532<br /> __do_sys_ioctl fs/ioctl.c:596 [inline]<br /> __se_sys_ioctl+0x82/0x170 fs/ioctl.c:584<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f5f13850fd9<br /> RSP: 002b:00007ffe3b3518b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 0000200000000000 RCX: 00007f5f13850fd9<br /> RDX: 0000200000000040 RSI: 00000000c020660b RDI: 0000000000000004<br /> RBP: 6165627472616568 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe3b3518f0<br /> R13: 00007ffe3b351b18 R14: 431bde82d7b634db R15: 00007f5f1389a03b<br /> <br /> ocfs2_fiemap() takes a read lock of the ip_alloc_sem semaphore (since<br /> v2.6.22-527-g7307de80510a) and calls fiemap_fill_next_extent() to read the<br /> extent list of this running mmap executable. The user supplied buffer to<br /> hold the fiemap information page faults calling ocfs2_page_mkwrite() which<br /> will take a write lock (since v2.6.27-38-g00dc417fa3e7) of the same<br /> semaphore. This recursive semaphore will hold filesystem locks and causes<br /> a hang of the fileystem.<br /> <br /> The ip_alloc_sem protects the inode extent list and size. Release the<br /> read semphore before calling fiemap_fill_next_extent() in ocfs2_fiemap()<br /> and ocfs2_fiemap_inline(). This does an unnecessary semaphore lock/unlock<br /> on the last extent but simplifies the error path.

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: fec: Fix possible NPD in fec_enet_phy_reset_after_clk_enable()<br /> <br /> The function of_phy_find_device may return NULL, so we need to take<br /> care before dereferencing phy_dev.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/sysfs: fix use-after-free in state_show()<br /> <br /> state_show() reads kdamond-&gt;damon_ctx without holding damon_sysfs_lock. <br /> This allows a use-after-free race:<br /> <br /> CPU 0 CPU 1<br /> ----- -----<br /> state_show() damon_sysfs_turn_damon_on()<br /> ctx = kdamond-&gt;damon_ctx; mutex_lock(&amp;damon_sysfs_lock);<br /> damon_destroy_ctx(kdamond-&gt;damon_ctx);<br /> kdamond-&gt;damon_ctx = NULL;<br /> mutex_unlock(&amp;damon_sysfs_lock);<br /> damon_is_running(ctx); /* ctx is freed */<br /> mutex_lock(&amp;ctx-&gt;kdamond_lock); /* UAF */<br /> <br /> (The race can also occur with damon_sysfs_kdamonds_rm_dirs() and<br /> damon_sysfs_kdamond_release(), which free or replace the context under<br /> damon_sysfs_lock.)<br /> <br /> Fix by taking damon_sysfs_lock before dereferencing the context, mirroring<br /> the locking used in pid_show().<br /> <br /> The bug has existed since state_show() first accessed kdamond-&gt;damon_ctx.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: fix crash after fscrypt_encrypt_pagecache_blocks() error<br /> <br /> The function move_dirty_folio_in_page_array() was created by commit<br /> ce80b76dd327 ("ceph: introduce ceph_process_folio_batch() method") by<br /> moving code from ceph_writepages_start() to this function.<br /> <br /> This new function is supposed to return an error code which is checked<br /> by the caller (now ceph_process_folio_batch()), and on error, the<br /> caller invokes redirty_page_for_writepage() and then breaks from the<br /> loop.<br /> <br /> However, the refactoring commit has gone wrong, and it by accident, it<br /> always returns 0 (= success) because it first NULLs the pointer and<br /> then returns PTR_ERR(NULL) which is always 0. This means errors are<br /> silently ignored, leaving NULL entries in the page array, which may<br /> later crash the kernel.<br /> <br /> The simple solution is to call PTR_ERR() before clearing the pointer.