Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix use-after-free in bpf_uprobe_multi_link_attach()<br /> <br /> If bpf_link_prime() fails, bpf_uprobe_multi_link_attach() goes to the<br /> error_free label and frees the array of bpf_uprobe&amp;#39;s without calling<br /> bpf_uprobe_unregister().<br /> <br /> This leaks bpf_uprobe-&gt;uprobe and worse, this frees bpf_uprobe-&gt;consumer<br /> without removing it from the uprobe-&gt;consumers list.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/hugetlb.c: fix UAF of vma in hugetlb fault pathway<br /> <br /> Syzbot reports a UAF in hugetlb_fault(). This happens because<br /> vmf_anon_prepare() could drop the per-VMA lock and allow the current VMA<br /> to be freed before hugetlb_vma_unlock_read() is called.<br /> <br /> We can fix this by using a modified version of vmf_anon_prepare() that<br /> doesn&amp;#39;t release the VMA lock on failure, and then release it ourselves<br /> after hugetlb_vma_unlock_read().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> exfat: resolve memory leak from exfat_create_upcase_table()<br /> <br /> If exfat_load_upcase_table reaches end and returns -EINVAL,<br /> allocated memory doesn&amp;#39;t get freed and while<br /> exfat_load_default_upcase_table allocates more memory, leading to a<br /> memory leak.<br /> <br /> Here&amp;#39;s link to syzkaller crash report illustrating this issue:<br /> https://syzkaller.appspot.com/text?tag=CrashReport&amp;x=1406c201980000

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> icmp: change the order of rate limits<br /> <br /> ICMP messages are ratelimited :<br /> <br /> After the blamed commits, the two rate limiters are applied in this order:<br /> <br /> 1) host wide ratelimit (icmp_global_allow())<br /> <br /> 2) Per destination ratelimit (inetpeer based)<br /> <br /> In order to avoid side-channels attacks, we need to apply<br /> the per destination check first.<br /> <br /> This patch makes the following change :<br /> <br /> 1) icmp_global_allow() checks if the host wide limit is reached.<br /> But credits are not yet consumed. This is deferred to 3)<br /> <br /> 2) The per destination limit is checked/updated.<br /> This might add a new node in inetpeer tree.<br /> <br /> 3) icmp_global_consume() consumes tokens if prior operations succeeded.<br /> <br /> This means that host wide ratelimit is still effective<br /> in keeping inetpeer tree small even under DDOS.<br /> <br /> As a bonus, I removed icmp_global.lock as the fast path<br /> can use a lock-free operation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfs: fix race between evice_inodes() and find_inode()&amp;iput()<br /> <br /> Hi, all<br /> <br /> Recently I noticed a bug[1] in btrfs, after digged it into<br /> and I believe it&amp;#39;a race in vfs.<br /> <br /> Let&amp;#39;s assume there&amp;#39;s a inode (ie ino 261) with i_count 1 is<br /> called by iput(), and there&amp;#39;s a concurrent thread calling<br /> generic_shutdown_super().<br /> <br /> cpu0: cpu1:<br /> iput() // i_count is 1<br /> -&gt;spin_lock(inode)<br /> -&gt;dec i_count to 0<br /> -&gt;iput_final() generic_shutdown_super()<br /> -&gt;__inode_add_lru() -&gt;evict_inodes()<br /> // cause some reason[2] -&gt;if (atomic_read(inode-&gt;i_count)) continue;<br /> // return before // inode 261 passed the above check<br /> // list_lru_add_obj() // and then schedule out<br /> -&gt;spin_unlock()<br /> // note here: the inode 261<br /> // was still at sb list and hash list,<br /> // and I_FREEING|I_WILL_FREE was not been set<br /> <br /> btrfs_iget()<br /> // after some function calls<br /> -&gt;find_inode()<br /> // found the above inode 261<br /> -&gt;spin_lock(inode)<br /> // check I_FREEING|I_WILL_FREE<br /> // and passed<br /> -&gt;__iget()<br /> -&gt;spin_unlock(inode) // schedule back<br /> -&gt;spin_lock(inode)<br /> // check (I_NEW|I_FREEING|I_WILL_FREE) flags,<br /> // passed and set I_FREEING<br /> iput() -&gt;spin_unlock(inode)<br /> -&gt;spin_lock(inode) -&gt;evict()<br /> // dec i_count to 0<br /> -&gt;iput_final()<br /> -&gt;spin_unlock()<br /> -&gt;evict()<br /> <br /> Now, we have two threads simultaneously evicting<br /> the same inode, which may trigger the BUG(inode-&gt;i_state &amp; I_CLEAR)<br /> statement both within clear_inode() and iput().<br /> <br /> To fix the bug, recheck the inode-&gt;i_count after holding i_lock.<br /> Because in the most scenarios, the first check is valid, and<br /> the overhead of spin_lock() can be reduced.<br /> <br /> If there is any misunderstanding, please let me know, thanks.<br /> <br /> [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/<br /> [2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable()<br /> return false when I reproduced the bug.

Improper Neutralization of Special Elements used in an SQL Command (&amp;#39;SQL Injection&amp;#39;) vulnerability in FunnelKit Automation By Autonami allows SQL Injection.This issue affects Automation By Autonami: from n/a through 3.1.2.

Cross-Site Request Forgery (CSRF) vulnerability in Latepoint LatePoint allows Cross Site Request Forgery.This issue affects LatePoint: from n/a through 4.9.91.

The TS Poll WordPress plugin before 2.4.0 does not sanitize and escape a parameter before using it in a SQL statement, allowing admins to perform SQL injection attacks

Administrative Management System from Wellchoose has an OS Command Injection vulnerability, allowing remote attackers with regular privileges to inject and execute arbitrary OS commands.

Administrative Management System from Wellchoose has a Path Traversal vulnerability, allowing unauthenticated remote attackers to exploit this vulnerability to download arbitrary files on the server.

Administrative Management System from Wellchoose does not properly validate uploaded file types, allowing remote attackers with regular privileges to upload and execute webshells.

A vulnerability was found in code-projects Pharmacy Management System 1.0. It has been declared as problematic. Affected by this vulnerability is an unknown functionality of the file /manage_customer.php of the component Manage Customer Page. The manipulation of the argument suppliers_name/address leads to cross site scripting. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. The initial researcher advisory mentions contradicting files to be affected. Other parameters might be affected as well.