Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate()<br /> <br /> The psc-&gt;div[] array has psc-&gt;num_div elements. These values come from<br /> when we call clk_hw_register_div(). It&amp;#39;s adc_divisors and<br /> ARRAY_SIZE(adc_divisors)) and so on. So this condition needs to be &gt;=<br /> instead of &gt; to prevent an out of bounds read.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: get rid of online repaire on corrupted directory<br /> <br /> syzbot reports a f2fs bug as below:<br /> <br /> kernel BUG at fs/f2fs/inode.c:896!<br /> RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896<br /> Call Trace:<br /> evict+0x532/0x950 fs/inode.c:704<br /> dispose_list fs/inode.c:747 [inline]<br /> evict_inodes+0x5f9/0x690 fs/inode.c:797<br /> generic_shutdown_super+0x9d/0x2d0 fs/super.c:627<br /> kill_block_super+0x44/0x90 fs/super.c:1696<br /> kill_f2fs_super+0x344/0x690 fs/f2fs/super.c:4898<br /> deactivate_locked_super+0xc4/0x130 fs/super.c:473<br /> cleanup_mnt+0x41f/0x4b0 fs/namespace.c:1373<br /> task_work_run+0x24f/0x310 kernel/task_work.c:228<br /> ptrace_notify+0x2d2/0x380 kernel/signal.c:2402<br /> ptrace_report_syscall include/linux/ptrace.h:415 [inline]<br /> ptrace_report_syscall_exit include/linux/ptrace.h:477 [inline]<br /> syscall_exit_work+0xc6/0x190 kernel/entry/common.c:173<br /> syscall_exit_to_user_mode_prepare kernel/entry/common.c:200 [inline]<br /> __syscall_exit_to_user_mode_work kernel/entry/common.c:205 [inline]<br /> syscall_exit_to_user_mode+0x279/0x370 kernel/entry/common.c:218<br /> do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896<br /> <br /> Online repaire on corrupted directory in f2fs_lookup() can generate<br /> dirty data/meta while racing w/ readonly remount, it may leave dirty<br /> inode after filesystem becomes readonly, however, checkpoint() will<br /> skips flushing dirty inode in a state of readonly mode, result in<br /> above panic.<br /> <br /> Let&amp;#39;s get rid of online repaire in f2fs_lookup(), and leave the work<br /> to fsck.f2fs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: return -EINVAL when namelen is 0<br /> <br /> When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may<br /> result in namelen being 0, which will cause memdup_user() to return<br /> ZERO_SIZE_PTR.<br /> When we access the name.data that has been assigned the value of<br /> ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is<br /> triggered.<br /> <br /> [ T1205] ==================================================================<br /> [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260<br /> [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205<br /> [ T1205]<br /> [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406<br /> [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014<br /> [ T1205] Call Trace:<br /> [ T1205] dump_stack+0x9a/0xd0<br /> [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260<br /> [ T1205] __kasan_report.cold+0x34/0x84<br /> [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260<br /> [ T1205] kasan_report+0x3a/0x50<br /> [ T1205] nfs4_client_to_reclaim+0xe9/0x260<br /> [ T1205] ? nfsd4_release_lockowner+0x410/0x410<br /> [ T1205] cld_pipe_downcall+0x5ca/0x760<br /> [ T1205] ? nfsd4_cld_tracking_exit+0x1d0/0x1d0<br /> [ T1205] ? down_write_killable_nested+0x170/0x170<br /> [ T1205] ? avc_policy_seqno+0x28/0x40<br /> [ T1205] ? selinux_file_permission+0x1b4/0x1e0<br /> [ T1205] rpc_pipe_write+0x84/0xb0<br /> [ T1205] vfs_write+0x143/0x520<br /> [ T1205] ksys_write+0xc9/0x170<br /> [ T1205] ? __ia32_sys_read+0x50/0x50<br /> [ T1205] ? ktime_get_coarse_real_ts64+0xfe/0x110<br /> [ T1205] ? ktime_get_coarse_real_ts64+0xa2/0x110<br /> [ T1205] do_syscall_64+0x33/0x40<br /> [ T1205] entry_SYSCALL_64_after_hwframe+0x67/0xd1<br /> [ T1205] RIP: 0033:0x7fdbdb761bc7<br /> [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 3d 00 f0 ff ff 77 514<br /> [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001<br /> [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7<br /> [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008<br /> [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001<br /> [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b<br /> [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000<br /> [ T1205] ==================================================================<br /> <br /> Fix it by checking namelen.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put()<br /> <br /> syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending<br /> garbage on the four reserved tcp bits (th-&gt;res1)<br /> <br /> Use skb_put_zero() to clear the whole TCP header,<br /> as done in nf_reject_ip_tcphdr_put()<br /> <br /> BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255<br /> nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255<br /> nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344<br /> nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48<br /> expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]<br /> nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288<br /> nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161<br /> nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]<br /> nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626<br /> nf_hook include/linux/netfilter.h:269 [inline]<br /> NF_HOOK include/linux/netfilter.h:312 [inline]<br /> ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310<br /> __netif_receive_skb_one_core net/core/dev.c:5661 [inline]<br /> __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775<br /> process_backlog+0x4ad/0xa50 net/core/dev.c:6108<br /> __napi_poll+0xe7/0x980 net/core/dev.c:6772<br /> napi_poll net/core/dev.c:6841 [inline]<br /> net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963<br /> handle_softirqs+0x1ce/0x800 kernel/softirq.c:554<br /> __do_softirq+0x14/0x1a kernel/softirq.c:588<br /> do_softirq+0x9a/0x100 kernel/softirq.c:455<br /> __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382<br /> local_bh_enable include/linux/bottom_half.h:33 [inline]<br /> rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline]<br /> __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450<br /> dev_queue_xmit include/linux/netdevice.h:3105 [inline]<br /> neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565<br /> neigh_output include/net/neighbour.h:542 [inline]<br /> ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141<br /> __ip6_finish_output net/ipv6/ip6_output.c:215 [inline]<br /> ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226<br /> NF_HOOK_COND include/linux/netfilter.h:303 [inline]<br /> ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247<br /> dst_output include/net/dst.h:450 [inline]<br /> NF_HOOK include/linux/netfilter.h:314 [inline]<br /> ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366<br /> inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135<br /> __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466<br /> tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline]<br /> tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143<br /> tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333<br /> __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679<br /> inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750<br /> __sys_connect_file net/socket.c:2061 [inline]<br /> __sys_connect+0x606/0x690 net/socket.c:2078<br /> __do_sys_connect net/socket.c:2088 [inline]<br /> __se_sys_connect net/socket.c:2085 [inline]<br /> __x64_sys_connect+0x91/0xe0 net/socket.c:2085<br /> x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Uninit was stored to memory at:<br /> nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249<br /> nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344<br /> nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48<br /> expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]<br /> nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288<br /> nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161<br /> nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]<br /> nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626<br /> nf_hook include/linux/netfilter.h:269 [inline]<br /> NF_HOOK include/linux/netfilter.h:312 [inline]<br /> ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310<br /> __netif_receive_skb_one_core<br /> ---truncated---

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 Aman FunnelKit Automations wp-marketing-automations allows SQL Injection.This issue affects FunnelKit Automations: from n/a through

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