Vulnerabilities

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in Brainstorm Force Ultimate Addons for WPBakery Page Builder allows DOM-Based XSS.This issue affects Ultimate Addons for WPBakery Page Builder: from n/a before 3.21.4.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> apparmor: fix race between freeing data and fs accessing it<br /> <br /> AppArmor was putting the reference to i_private data on its end after<br /> removing the original entry from the file system. However the inode<br /> can aand does live beyond that point and it is possible that some of<br /> the fs call back functions will be invoked after the reference has<br /> been put, which results in a race between freeing the data and<br /> accessing it through the fs.<br /> <br /> While the rawdata/loaddata is the most likely candidate to fail the<br /> race, as it has the fewest references. If properly crafted it might be<br /> possible to trigger a race for the other types stored in i_private.<br /> <br /> Fix this by moving the put of i_private referenced data to the correct<br /> place which is during inode eviction.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> apparmor: fix race on rawdata dereference<br /> <br /> There is a race condition that leads to a use-after-free situation:<br /> because the rawdata inodes are not refcounted, an attacker can start<br /> open()ing one of the rawdata files, and at the same time remove the<br /> last reference to this rawdata (by removing the corresponding profile,<br /> for example), which frees its struct aa_loaddata; as a result, when<br /> seq_rawdata_open() is reached, i_private is a dangling pointer and<br /> freed memory is accessed.<br /> <br /> The rawdata inodes weren&amp;#39;t refcounted to avoid a circular refcount and<br /> were supposed to be held by the profile rawdata reference. However<br /> during profile removal there is a window where the vfs and profile<br /> destruction race, resulting in the use after free.<br /> <br /> Fix this by moving to a double refcount scheme. Where the profile<br /> refcount on rawdata is used to break the circular dependency. Allowing<br /> for freeing of the rawdata once all inode references to the rawdata<br /> are put.

A vulnerability was identified in Shandong Hoteam InforCenter PLM up to 8.3.8. The impacted element is the function uploadFileToIIS of the file /Base/BaseHandler.ashx. The manipulation of the argument File leads to unrestricted upload. It is possible to initiate the attack 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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> apparmor: fix: limit the number of levels of policy namespaces<br /> <br /> Currently the number of policy namespaces is not bounded relying on<br /> the user namespace limit. However policy namespaces aren&amp;#39;t strictly<br /> tied to user namespaces and it is possible to create them and nest<br /> them arbitrarily deep which can be used to exhaust system resource.<br /> <br /> Hard cap policy namespaces to the same depth as user namespaces.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> apparmor: fix side-effect bug in match_char() macro usage<br /> <br /> The match_char() macro evaluates its character parameter multiple<br /> times when traversing differential encoding chains. When invoked<br /> with *str++, the string pointer advances on each iteration of the<br /> inner do-while loop, causing the DFA to check different characters<br /> at each iteration and therefore skip input characters.<br /> This results in out-of-bounds reads when the pointer advances past<br /> the input buffer boundary.<br /> <br /> [ 94.984676] ==================================================================<br /> [ 94.985301] BUG: KASAN: slab-out-of-bounds in aa_dfa_match+0x5ae/0x760<br /> [ 94.985655] Read of size 1 at addr ffff888100342000 by task file/976<br /> <br /> [ 94.986319] CPU: 7 UID: 1000 PID: 976 Comm: file Not tainted 6.19.0-rc7-next-20260127 #1 PREEMPT(lazy)<br /> [ 94.986322] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [ 94.986329] Call Trace:<br /> [ 94.986341] <br /> [ 94.986347] dump_stack_lvl+0x5e/0x80<br /> [ 94.986374] print_report+0xc8/0x270<br /> [ 94.986384] ? aa_dfa_match+0x5ae/0x760<br /> [ 94.986388] kasan_report+0x118/0x150<br /> [ 94.986401] ? aa_dfa_match+0x5ae/0x760<br /> [ 94.986405] aa_dfa_match+0x5ae/0x760<br /> [ 94.986408] __aa_path_perm+0x131/0x400<br /> [ 94.986418] aa_path_perm+0x219/0x2f0<br /> [ 94.986424] apparmor_file_open+0x345/0x570<br /> [ 94.986431] security_file_open+0x5c/0x140<br /> [ 94.986442] do_dentry_open+0x2f6/0x1120<br /> [ 94.986450] vfs_open+0x38/0x2b0<br /> [ 94.986453] ? may_open+0x1e2/0x2b0<br /> [ 94.986466] path_openat+0x231b/0x2b30<br /> [ 94.986469] ? __x64_sys_openat+0xf8/0x130<br /> [ 94.986477] do_file_open+0x19d/0x360<br /> [ 94.986487] do_sys_openat2+0x98/0x100<br /> [ 94.986491] __x64_sys_openat+0xf8/0x130<br /> [ 94.986499] do_syscall_64+0x8e/0x660<br /> [ 94.986515] ? count_memcg_events+0x15f/0x3c0<br /> [ 94.986526] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 94.986540] ? handle_mm_fault+0x1639/0x1ef0<br /> [ 94.986551] ? vma_start_read+0xf0/0x320<br /> [ 94.986558] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 94.986561] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 94.986563] ? fpregs_assert_state_consistent+0x50/0xe0<br /> [ 94.986572] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 94.986574] ? arch_exit_to_user_mode_prepare+0x9/0xb0<br /> [ 94.986587] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 94.986588] ? irqentry_exit+0x3c/0x590<br /> [ 94.986595] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [ 94.986597] RIP: 0033:0x7fda4a79c3ea<br /> <br /> Fix by extracting the character value before invoking match_char,<br /> ensuring single evaluation per outer loop.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> apparmor: fix missing bounds check on DEFAULT table in verify_dfa()<br /> <br /> The verify_dfa() function only checks DEFAULT_TABLE bounds when the state<br /> is not differentially encoded.<br /> <br /> When the verification loop traverses the differential encoding chain,<br /> it reads k = DEFAULT_TABLE[j] and uses k as an array index without<br /> validation. A malformed DFA with DEFAULT_TABLE[j] &gt;= state_count,<br /> therefore, causes both out-of-bounds reads and writes.<br /> <br /> [ 57.179855] ==================================================================<br /> [ 57.180549] BUG: KASAN: slab-out-of-bounds in verify_dfa+0x59a/0x660<br /> [ 57.180904] Read of size 4 at addr ffff888100eadec4 by task su/993<br /> <br /> [ 57.181554] CPU: 1 UID: 0 PID: 993 Comm: su Not tainted 6.19.0-rc7-next-20260127 #1 PREEMPT(lazy)<br /> [ 57.181558] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [ 57.181563] Call Trace:<br /> [ 57.181572] <br /> [ 57.181577] dump_stack_lvl+0x5e/0x80<br /> [ 57.181596] print_report+0xc8/0x270<br /> [ 57.181605] ? verify_dfa+0x59a/0x660<br /> [ 57.181608] kasan_report+0x118/0x150<br /> [ 57.181620] ? verify_dfa+0x59a/0x660<br /> [ 57.181623] verify_dfa+0x59a/0x660<br /> [ 57.181627] aa_dfa_unpack+0x1610/0x1740<br /> [ 57.181629] ? __kmalloc_cache_noprof+0x1d0/0x470<br /> [ 57.181640] unpack_pdb+0x86d/0x46b0<br /> [ 57.181647] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 57.181653] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 57.181656] ? aa_unpack_nameX+0x1a8/0x300<br /> [ 57.181659] aa_unpack+0x20b0/0x4c30<br /> [ 57.181662] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 57.181664] ? stack_depot_save_flags+0x33/0x700<br /> [ 57.181681] ? kasan_save_track+0x4f/0x80<br /> [ 57.181683] ? kasan_save_track+0x3e/0x80<br /> [ 57.181686] ? __kasan_kmalloc+0x93/0xb0<br /> [ 57.181688] ? __kvmalloc_node_noprof+0x44a/0x780<br /> [ 57.181693] ? aa_simple_write_to_buffer+0x54/0x130<br /> [ 57.181697] ? policy_update+0x154/0x330<br /> [ 57.181704] aa_replace_profiles+0x15a/0x1dd0<br /> [ 57.181707] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 57.181710] ? __kvmalloc_node_noprof+0x44a/0x780<br /> [ 57.181712] ? aa_loaddata_alloc+0x77/0x140<br /> [ 57.181715] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 57.181717] ? _copy_from_user+0x2a/0x70<br /> [ 57.181730] policy_update+0x17a/0x330<br /> [ 57.181733] profile_replace+0x153/0x1a0<br /> [ 57.181735] ? rw_verify_area+0x93/0x2d0<br /> [ 57.181740] vfs_write+0x235/0xab0<br /> [ 57.181745] ksys_write+0xb0/0x170<br /> [ 57.181748] do_syscall_64+0x8e/0x660<br /> [ 57.181762] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [ 57.181765] RIP: 0033:0x7f6192792eb2<br /> <br /> Remove the MATCH_FLAG_DIFF_ENCODE condition to validate all DEFAULT_TABLE<br /> entries unconditionally.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> apparmor: fix differential encoding verification<br /> <br /> Differential encoding allows loops to be created if it is abused. To<br /> prevent this the unpack should verify that a diff-encode chain<br /> terminates.<br /> <br /> Unfortunately the differential encode verification had two bugs.<br /> <br /> 1. it conflated states that had gone through check and already been<br /> marked, with states that were currently being checked and marked.<br /> This means that loops in the current chain being verified are treated<br /> as a chain that has already been verified.<br /> <br /> 2. the order bailout on already checked states compared current chain<br /> check iterators j,k instead of using the outer loop iterator i.<br /> Meaning a step backwards in states in the current chain verification<br /> was being mistaken for moving to an already verified state.<br /> <br /> Move to a double mark scheme where already verified states get a<br /> different mark, than the current chain being kept. This enables us<br /> to also drop the backwards verification check that was the cause of<br /> the second error as any already verified state is already marked.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> apparmor: Fix double free of ns_name in aa_replace_profiles()<br /> <br /> if ns_name is NULL after<br /> 1071 error = aa_unpack(udata, &amp;lh, &amp;ns_name);<br /> <br /> and if ent-&gt;ns_name contains an ns_name in<br /> 1089 } else if (ent-&gt;ns_name) {<br /> <br /> then ns_name is assigned the ent-&gt;ns_name<br /> 1095 ns_name = ent-&gt;ns_name;<br /> <br /> however ent-&gt;ns_name is freed at<br /> 1262 aa_load_ent_free(ent);<br /> <br /> and then again when freeing ns_name at<br /> 1270 kfree(ns_name);<br /> <br /> Fix this by NULLing out ent-&gt;ns_name after it is transferred to ns_name<br /> <br /> ")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> apparmor: fix memory leak in verify_header<br /> <br /> The function sets `*ns = NULL` on every call, leaking the namespace<br /> string allocated in previous iterations when multiple profiles are<br /> unpacked. This also breaks namespace consistency checking since *ns<br /> is always NULL when the comparison is made.<br /> <br /> Remove the incorrect assignment.<br /> The caller (aa_unpack) initializes *ns to NULL once before the loop,<br /> which is sufficient.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> apparmor: replace recursive profile removal with iterative approach<br /> <br /> The profile removal code uses recursion when removing nested profiles,<br /> which can lead to kernel stack exhaustion and system crashes.<br /> <br /> Reproducer:<br /> $ pf=&amp;#39;a&amp;#39;; for ((i=0; i /sys/kernel/security/apparmor/.remove<br /> <br /> Replace the recursive __aa_profile_list_release() approach with an<br /> iterative approach in __remove_profile(). The function repeatedly<br /> finds and removes leaf profiles until the entire subtree is removed,<br /> maintaining the same removal semantic without recursion.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86/mmu: Only WARN in direct MMUs when overwriting shadow-present SPTE<br /> <br /> Adjust KVM&amp;#39;s sanity check against overwriting a shadow-present SPTE with a<br /> another SPTE with a different target PFN to only apply to direct MMUs,<br /> i.e. only to MMUs without shadowed gPTEs. While it&amp;#39;s impossible for KVM<br /> to overwrite a shadow-present SPTE in response to a guest write, writes<br /> from outside the scope of KVM, e.g. from host userspace, aren&amp;#39;t detected<br /> by KVM&amp;#39;s write tracking and so can break KVM&amp;#39;s shadow paging rules.<br /> <br /> ------------[ cut here ]------------<br /> pfn != spte_to_pfn(*sptep)<br /> WARNING: arch/x86/kvm/mmu/mmu.c:3069 at mmu_set_spte+0x1e4/0x440 [kvm], CPU#0: vmx_ept_stale_r/872<br /> Modules linked in: kvm_intel kvm irqbypass<br /> CPU: 0 UID: 1000 PID: 872 Comm: vmx_ept_stale_r Not tainted 7.0.0-rc2-eafebd2d2ab0-sink-vm #319 PREEMPT<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015<br /> RIP: 0010:mmu_set_spte+0x1e4/0x440 [kvm]<br /> Call Trace:<br /> <br /> ept_page_fault+0x535/0x7f0 [kvm]<br /> kvm_mmu_do_page_fault+0xee/0x1f0 [kvm]<br /> kvm_mmu_page_fault+0x8d/0x620 [kvm]<br /> vmx_handle_exit+0x18c/0x5a0 [kvm_intel]<br /> kvm_arch_vcpu_ioctl_run+0xc55/0x1c20 [kvm]<br /> kvm_vcpu_ioctl+0x2d5/0x980 [kvm]<br /> __x64_sys_ioctl+0x8a/0xd0<br /> do_syscall_64+0xb5/0x730<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> ---[ end trace 0000000000000000 ]---