The Unify plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the 'init' action in all versions up to, and including, 3.4.9. This makes it possible for unauthenticated attackers to delete specific plugin options via the 'unify_plugin_downgrade' parameter.

A link following vulnerability exists in the UnifyScanner component of Armoury Crate. This vulnerability may be triggered by creating a specially crafted junction, potentially leading to local privilege escalation. For more information, please refer to section 'Security Update for Armoury Crate App' in the ASUS Security Advisory.

The Unify plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin for WordPress's unify_checkout shortcode in all versions up to, and including, 3.4.7 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: erofs: fix invalid algorithm for encoded extents The current algorithm sanity checks do not properly apply to new encoded extents. Unify the algorithm check with Z_EROFS_COMPRESSION(_RUNTIME)_MAX and ensure consistency with sbi->available_compr_algs.

linux

In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: Fix Oops by 9.1 surround channel names get_line_out_pfx() may trigger an Oops by overflowing the static array with more than 8 channels. This was reported for MacBookPro 12,1 with Cirrus codec. As a workaround, extend for the 9.1 channels and also fix the potential Oops by unifying the code paths accessing the same array with the proper size check.

linux

In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: tas2781: Fix wrong reference of tasdevice_priv During the conversion to unify the calibration data management, the reference to tasdevice_priv was wrongly set to h->hda_priv instead of h->priv. This resulted in memory corruption and crashes eventually. Unfortunately it's a void pointer, hence the compiler couldn't know that it's wrong.

linux

In the Linux kernel, the following vulnerability has been resolved: memory: samsung: exynos5422-dmc: Fix refcount leak in of_get_dram_timings of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. This function doesn't call of_node_put() in some error paths. To unify the structure, Add put_node label and goto it on errors.

linux

In the Linux kernel, the following vulnerability has been resolved: blk-iolatency: Fix inflight count imbalances and IO hangs on offline iolatency needs to track the number of inflight IOs per cgroup. As this tracking can be expensive, it is disabled when no cgroup has iolatency configured for the device. To ensure that the inflight counters stay balanced, iolatency_set_limit() freezes the request_queue while manipulating the enabled counter, which ensures that no IO is in flight and thus all counters are zero. Unfortunately, iolatency_set_limit() isn't the only place where the enabled counter is manipulated. iolatency_pd_offline() can also dec the counter and trigger disabling. As this disabling happens without freezing the q, this can easily happen while some IOs are in flight and thus leak the counts. This can be easily demonstrated by turning on iolatency on an one empty cgroup while IOs are in flight in other cgroups and then removing the cgroup. Note that iolatency shouldn't have been enabled elsewhere in the system to ensure that removing the cgroup disables iolatency for the whole device. The following keeps flipping on and off iolatency on sda: echo +io > /sys/fs/cgroup/cgroup.subtree_control while true; do mkdir -p /sys/fs/cgroup/test echo '8:0 target=100000' > /sys/fs/cgroup/test/io.latency sleep 1 rmdir /sys/fs/cgroup/test sleep 1 done and there's concurrent fio generating direct rand reads: fio --name test --filename=/dev/sda --direct=1 --rw=randread \ --runtime=600 --time_based --iodepth=256 --numjobs=4 --bs=4k while monitoring with the following drgn script: while True: for css in css_for_each_descendant_pre(prog['blkcg_root'].css.address_of_()): for pos in hlist_for_each(container_of(css, 'struct blkcg', 'css').blkg_list): blkg = container_of(pos, 'struct blkcg_gq', 'blkcg_node') pd = blkg.pd[prog['blkcg_policy_iolatency'].plid] if pd.value_() == 0: continue iolat = container_of(pd, 'struct iolatency_grp', 'pd') inflight = iolat.rq_wait.inflight.counter.value_() if inflight: print(f'inflight={inflight} {disk_name(blkg.q.disk).decode("utf-8")} ' f'{cgroup_path(css.cgroup).decode("utf-8")}') time.sleep(1) The monitoring output looks like the following: inflight=1 sda /user.slice inflight=1 sda /user.slice ... inflight=14 sda /user.slice inflight=13 sda /user.slice inflight=17 sda /user.slice inflight=15 sda /user.slice inflight=18 sda /user.slice inflight=17 sda /user.slice inflight=20 sda /user.slice inflight=19 sda /user.slice <- fio stopped, inflight stuck at 19 inflight=19 sda /user.slice inflight=19 sda /user.slice If a cgroup with stuck inflight ends up getting throttled, the throttled IOs will never get issued as there's no completion event to wake it up leading to an indefinite hang. This patch fixes the bug by unifying enable handling into a work item which is automatically kicked off from iolatency_set_min_lat_nsec() which is called from both iolatency_set_limit() and iolatency_pd_offline() paths. Punting to a work item is necessary as iolatency_pd_offline() is called under spinlocks while freezing a request_queue requires a sleepable context. This also simplifies the code reducing LOC sans the comments and avoids the unnecessary freezes which were happening whenever a cgroup's latency target is newly set or cleared.

linux

In the Linux kernel, the following vulnerability has been resolved: staging: wfx: fix an error handling in wfx_init_common() One error handler of wfx_init_common() return without calling ieee80211_free_hw(hw), which may result in memory leak. And I add one err label to unify the error handler, which is useful for the subsequent changes.

linux

In the Linux kernel, the following vulnerability has been resolved: x86: stop playing stack games in profile_pc() The 'profile_pc()' function is used for timer-based profiling, which isn't really all that relevant any more to begin with, but it also ends up making assumptions based on the stack layout that aren't necessarily valid. Basically, the code tries to account the time spent in spinlocks to the caller rather than the spinlock, and while I support that as a concept, it's not worth the code complexity or the KASAN warnings when no serious profiling is done using timers anyway these days. And the code really does depend on stack layout that is only true in the simplest of cases. We've lost the comment at some point (I think when the 32-bit and 64-bit code was unified), but it used to say: Assume the lock function has either no stack frame or a copy of eflags from PUSHF. which explains why it just blindly loads a word or two straight off the stack pointer and then takes a minimal look at the values to just check if they might be eflags or the return pc: Eflags always has bits 22 and up cleared unlike kernel addresses but that basic stack layout assumption assumes that there isn't any lock debugging etc going on that would complicate the code and cause a stack frame. It causes KASAN unhappiness reported for years by syzkaller [1] and others [2]. With no real practical reason for this any more, just remove the code. Just for historical interest, here's some background commits relating to this code from 2006: 0cb91a229364 ("i386: Account spinlocks to the caller during profiling for !FP kernels") 31679f38d886 ("Simplify profile_pc on x86-64") and a code unification from 2009: ef4512882dbe ("x86: time_32/64.c unify profile_pc") but the basics of this thing actually goes back to before the git tree.

linux

The CoSoSys Endpoint Protector through 5.9.3 and Unify agent through 7.0.6 is susceptible to an arbitrary code execution vulnerability due to the way an archive obtained from the Endpoint Protector or Unify server is extracted on the endpoint. An attacker who is able to modify the archive on the server could obtain remote code execution as an administrator on an endpoint.

Netwrix CoSoSys Endpoint Protector through 5.9.3 and CoSoSys Unify through 7.0.6 contain a remote code execution vulnerability in the Endpoint Protector and Unify agent in the way that the EasyLock dependency is acquired from the server. An attacker with administrative access to the Endpoint Protector or Unify server can cause a client to acquire and execute a malicious file resulting in remote code execution.

Netwrix CoSoSys Endpoint Protector through 5.9.3 and CoSoSys Unify through 7.0.6 contain a remote code execution vulnerability in the shadowing component of the Endpoint Protector and Unify agent which allows an attacker with administrative access to the Endpoint Protector or Unify server to overwrite sensitive configuration and subsequently execute system commands with SYSTEM/root privileges on a chosen client endpoint.

Netwrix CoSoSys Endpoint Protector through 5.9.3 and CoSoSys Unify through 7.0.6 contain a remote code execution vulnerability in the logging component of the Endpoint Protector and Unify server application which allows an unauthenticated remote attacker to send a malicious request, resulting in the ability to execute system commands with root privileges.

In Unify CP IP Phone firmware 1.10.4.3, Weak Credentials are used (a hardcoded root password).

mitel

In Unify CP IP Phone firmware 1.10.4.3, files are not encrypted and contain sensitive information such as the root password hash.

An issue was discovered in Atos Unify OpenScape Voice Trace Manager V8 before V8 R0.9.11. It allows authenticated path traversal in the user interface.

unify

An issue was discovered in Atos Unify OpenScape Voice Trace Manager V8 before V8 R0.9.11. It allows authenticated command injection via ftp.

unify

An issue was discovered in Atos Unify OpenScape Voice Trace Manager V8 before V8 R0.9.11. It allows unauthenticated Stored Cross-Site Scripting (XSS) in the administration component via Access Request.

unify

An issue was discovered in Atos Unify OpenScape Xpressions WebAssistant V7 before V7R1 FR5 HF42 P911. It allows path traversal.

mitel

An issue was discovered in Atos Unify OpenScape Xpressions WebAssistant V7 before V7R1 FR5 HF42 P911. It allows authenticated remote code execution via file upload.

mitel

A directory traversal vulnerability in the SOAP Server integrated in Atos Unify OpenScape Voice V10 before V10R3.26.1 allows a remote attacker to view the contents of arbitrary files in the local file system. An unauthenticated attacker might obtain sensitive files that allow for the compromise of the underlying system.

unify

An argument injection vulnerability has been identified in the administrative web interface of the Atos Unify OpenScape products "Session Border Controller" (SBC) and "Branch", before version V10 R3.4.0, and OpenScape "BCF" before versions V10R10.12.00 and V10R11.05.02. This allows an unauthenticated attacker to gain root access to the appliance via SSH (scope change) and also bypass authentication for the administrative interface and gain access as an arbitrary (administrative) user.

atos