Vulnerabilities

A vulnerability in the web conferencing component of Mitel MiCollab through 9.7.1.110 could allow an authenticated attacker with administrative privileges to conduct a Stored Cross-Site Scripting (XSS) attack due to insufficient validation of user input. A successful exploit could allow an attacker to execute arbitrary scripts.

A Buffer Overflow vulnerabilty in the local_app_set_router_token function of Vilo 5 Mesh WiFi System

A Buffer Overflow vulnerability in the local_app_set_router_wan function of Vilo 5 Mesh WiFi System

A Buffer Overflow vulnerability in the local_app_set_router_wifi_SSID_PWD function of Vilo 5 Mesh WiFi System

A vulnerability in the Suite Applications Services component of Mitel MiCollab through 9.7.1.110 could allow an authenticated attacker with administrative privileges to conduct a SQL Injection attack due to insufficient validation of user input. A successful exploit could allow an attacker to execute arbitrary database and management operations.

A vulnerability in the web conferencing component of Mitel MiCollab through 9.7.1.110 could allow an authenticated attacker with administrative privileges to conduct a SQL Injection attack due to insufficient validation of user input. A successful exploit could allow an attacker to execute arbitrary database and management operations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> zram: free secondary algorithms names<br /> <br /> We need to kfree() secondary algorithms names when reset zram device that<br /> had multi-streams, otherwise we leak memory.<br /> <br /> [senozhatsky@chromium.org: kfree(NULL) is legal]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ntfs3: Change to non-blocking allocation in ntfs_d_hash<br /> <br /> d_hash is done while under "rcu-walk" and should not sleep.<br /> __get_name() allocates using GFP_KERNEL, having the possibility<br /> to sleep when under memory pressure. Change the allocation to<br /> GFP_NOWAIT.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master Driver Due to Race Condition<br /> <br /> In the cdns_i3c_master_probe function, &amp;master-&gt;hj_work is bound with<br /> cdns_i3c_master_hj. And cdns_i3c_master_interrupt can call<br /> cnds_i3c_master_demux_ibis function to start the work.<br /> <br /> If we remove the module which will call cdns_i3c_master_remove to<br /> make cleanup, it will free master-&gt;base through i3c_master_unregister<br /> while the work mentioned above will be used. The sequence of operations<br /> that may lead to a UAF bug is as follows:<br /> <br /> CPU0 CPU1<br /> <br /> | cdns_i3c_master_hj<br /> cdns_i3c_master_remove |<br /> i3c_master_unregister(&amp;master-&gt;base) |<br /> device_unregister(&amp;master-&gt;dev) |<br /> device_release |<br /> //free master-&gt;base |<br /> | i3c_master_do_daa(&amp;master-&gt;base)<br /> | //use master-&gt;base<br /> <br /> Fix it by ensuring that the work is canceled before proceeding with<br /> the cleanup in cdns_i3c_master_remove.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Prevent tail call between progs attached to different hooks<br /> <br /> bpf progs can be attached to kernel functions, and the attached functions<br /> can take different parameters or return different return values. If<br /> prog attached to one kernel function tail calls prog attached to another<br /> kernel function, the ctx access or return value verification could be<br /> bypassed.<br /> <br /> For example, if prog1 is attached to func1 which takes only 1 parameter<br /> and prog2 is attached to func2 which takes two parameters. Since verifier<br /> assumes the bpf ctx passed to prog2 is constructed based on func2&amp;#39;s<br /> prototype, verifier allows prog2 to access the second parameter from<br /> the bpf ctx passed to it. The problem is that verifier does not prevent<br /> prog1 from passing its bpf ctx to prog2 via tail call. In this case,<br /> the bpf ctx passed to prog2 is constructed from func1 instead of func2,<br /> that is, the assumption for ctx access verification is bypassed.<br /> <br /> Another example, if BPF LSM prog1 is attached to hook file_alloc_security,<br /> and BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier<br /> knows the return value rules for these two hooks, e.g. it is legal for<br /> bpf_lsm_audit_rule_known to return positive number 1, and it is illegal<br /> for file_alloc_security to return positive number. So verifier allows<br /> prog2 to return positive number 1, but does not allow prog1 to return<br /> positive number. The problem is that verifier does not prevent prog1<br /> from calling prog2 via tail call. In this case, prog2&amp;#39;s return value 1<br /> will be used as the return value for prog1&amp;#39;s hook file_alloc_security.<br /> That is, the return value rule is bypassed.<br /> <br /> This patch adds restriction for tail call to prevent such bypasses.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ntb: ntb_hw_switchtec: Fix use after free vulnerability in switchtec_ntb_remove due to race condition<br /> <br /> In the switchtec_ntb_add function, it can call switchtec_ntb_init_sndev<br /> function, then &amp;sndev-&gt;check_link_status_work is bound with<br /> check_link_status_work. switchtec_ntb_link_notification may be called<br /> to start the work.<br /> <br /> If we remove the module which will call switchtec_ntb_remove to make<br /> cleanup, it will free sndev through kfree(sndev), while the work<br /> mentioned above will be used. The sequence of operations that may lead<br /> to a UAF bug is as follows:<br /> <br /> CPU0 CPU1<br /> <br /> | check_link_status_work<br /> switchtec_ntb_remove |<br /> kfree(sndev); |<br /> | if (sndev-&gt;link_force_down)<br /> | // use sndev<br /> <br /> Fix it by ensuring that the work is canceled before proceeding with<br /> the cleanup in switchtec_ntb_remove.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring: check if we need to reschedule during overflow flush<br /> <br /> In terms of normal application usage, this list will always be empty.<br /> And if an application does overflow a bit, it&amp;#39;ll have a few entries.<br /> However, nothing obviously prevents syzbot from running a test case<br /> that generates a ton of overflow entries, and then flushing them can<br /> take quite a while.<br /> <br /> Check for needing to reschedule while flushing, and drop our locks and<br /> do so if necessary. There&amp;#39;s no state to maintain here as overflows<br /> always prune from head-of-list, hence it&amp;#39;s fine to drop and reacquire<br /> the locks at the end of the loop.