Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFS: Fix use-after-free in nfs4_init_client()<br /> <br /> KASAN reports a use-after-free when attempting to mount two different<br /> exports through two different NICs that belong to the same server.<br /> <br /> Olga was able to hit this with kernels starting somewhere between 5.7<br /> and 5.10, but I traced the patch that introduced the clear_bit() call to<br /> 4.13. So something must have changed in the refcounting of the clp<br /> pointer to make this call to nfs_put_client() the very last one.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFS: Fix a potential NULL dereference in nfs_get_client()<br /> <br /> None of the callers are expecting NULL returns from nfs_get_client() so<br /> this code will lead to an Oops. It&amp;#39;s better to return an error<br /> pointer. I expect that this is dead code so hopefully no one is<br /> affected.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> IB/mlx5: Fix initializing CQ fragments buffer<br /> <br /> The function init_cq_frag_buf() can be called to initialize the current CQ<br /> fragments buffer cq-&gt;buf, or the temporary cq-&gt;resize_buf that is filled<br /> during CQ resize operation.<br /> <br /> However, the offending commit started to use function get_cqe() for<br /> getting the CQEs, the issue with this change is that get_cqe() always<br /> returns CQEs from cq-&gt;buf, which leads us to initialize the wrong buffer,<br /> and in case of enlarging the CQ we try to access elements beyond the size<br /> of the current cq-&gt;buf and eventually hit a kernel panic.<br /> <br /> [exception RIP: init_cq_frag_buf+103]<br /> [ffff9f799ddcbcd8] mlx5_ib_resize_cq at ffffffffc0835d60 [mlx5_ib]<br /> [ffff9f799ddcbdb0] ib_resize_cq at ffffffffc05270df [ib_core]<br /> [ffff9f799ddcbdc0] llt_rdma_setup_qp at ffffffffc0a6a712 [llt]<br /> [ffff9f799ddcbe10] llt_rdma_cc_event_action at ffffffffc0a6b411 [llt]<br /> [ffff9f799ddcbe98] llt_rdma_client_conn_thread at ffffffffc0a6bb75 [llt]<br /> [ffff9f799ddcbec8] kthread at ffffffffa66c5da1<br /> [ffff9f799ddcbf50] ret_from_fork_nospec_begin at ffffffffa6d95ddd<br /> <br /> Fix it by getting the needed CQE by calling mlx5_frag_buf_get_wqe() that<br /> takes the correct source buffer as a parameter.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: Ensure liveliness of nested VM-Enter fail tracepoint message<br /> <br /> Use the __string() machinery provided by the tracing subystem to make a<br /> copy of the string literals consumed by the "nested VM-Enter failed"<br /> tracepoint. A complete copy is necessary to ensure that the tracepoint<br /> can&amp;#39;t outlive the data/memory it consumes and deference stale memory.<br /> <br /> Because the tracepoint itself is defined by kvm, if kvm-intel and/or<br /> kvm-amd are built as modules, the memory holding the string literals<br /> defined by the vendor modules will be freed when the module is unloaded,<br /> whereas the tracepoint and its data in the ring buffer will live until<br /> kvm is unloaded (or "indefinitely" if kvm is built-in).<br /> <br /> This bug has existed since the tracepoint was added, but was recently<br /> exposed by a new check in tracing to detect exactly this type of bug.<br /> <br /> fmt: &amp;#39;%s%s<br /> &amp;#39; current_buffer: &amp;#39; vmx_dirty_log_t-140127 [003] .... kvm_nested_vmenter_failed: &amp;#39;<br /> WARNING: CPU: 3 PID: 140134 at kernel/trace/trace.c:3759 trace_check_vprintf+0x3be/0x3e0<br /> CPU: 3 PID: 140134 Comm: less Not tainted 5.13.0-rc1-ce2e73ce600a-req #184<br /> Hardware name: ASUS Q87M-E/Q87M-E, BIOS 1102 03/03/2014<br /> RIP: 0010:trace_check_vprintf+0x3be/0x3e0<br /> Code: 0b 44 8b 4c 24 1c e9 a9 fe ff ff c6 44 02 ff 00 49 8b 97 b0 20<br /> RSP: 0018:ffffa895cc37bcb0 EFLAGS: 00010282<br /> RAX: 0000000000000000 RBX: ffffa895cc37bd08 RCX: 0000000000000027<br /> RDX: 0000000000000027 RSI: 00000000ffffdfff RDI: ffff9766cfad74f8<br /> RBP: ffffffffc0a041d4 R08: ffff9766cfad74f0 R09: ffffa895cc37bad8<br /> R10: 0000000000000001 R11: 0000000000000001 R12: ffffffffc0a041d4<br /> R13: ffffffffc0f4dba8 R14: 0000000000000000 R15: ffff976409f2c000<br /> FS: 00007f92fa200740(0000) GS:ffff9766cfac0000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000559bd11b0000 CR3: 000000019fbaa002 CR4: 00000000001726e0<br /> Call Trace:<br /> trace_event_printf+0x5e/0x80<br /> trace_raw_output_kvm_nested_vmenter_failed+0x3a/0x60 [kvm]<br /> print_trace_line+0x1dd/0x4e0<br /> s_show+0x45/0x150<br /> seq_read_iter+0x2d5/0x4c0<br /> seq_read+0x106/0x150<br /> vfs_read+0x98/0x180<br /> ksys_read+0x5f/0xe0<br /> do_syscall_64+0x40/0xb0<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ipv4: fix memory leak in ip_mc_add1_src<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff888101bc4c00 (size 32):<br /> comm "syz-executor527", pid 360, jiffies 4294807421 (age 19.329s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 01 00 00 00 00 00 00 00 ac 14 14 bb 00 00 02 00 ................<br /> backtrace:<br /> [] kmalloc include/linux/slab.h:558 [inline]<br /> [] kzalloc include/linux/slab.h:688 [inline]<br /> [] ip_mc_add1_src net/ipv4/igmp.c:1971 [inline]<br /> [] ip_mc_add_src+0x95f/0xdb0 net/ipv4/igmp.c:2095<br /> [] ip_mc_source+0x84c/0xea0 net/ipv4/igmp.c:2416<br /> [] do_ip_setsockopt net/ipv4/ip_sockglue.c:1294 [inline]<br /> [] ip_setsockopt+0x114b/0x30c0 net/ipv4/ip_sockglue.c:1423<br /> [] raw_setsockopt+0x13d/0x170 net/ipv4/raw.c:857<br /> [] __sys_setsockopt+0x158/0x270 net/socket.c:2117<br /> [] __do_sys_setsockopt net/socket.c:2128 [inline]<br /> [] __se_sys_setsockopt net/socket.c:2125 [inline]<br /> [] __x64_sys_setsockopt+0xba/0x150 net/socket.c:2125<br /> [] do_syscall_64+0x40/0x80 arch/x86/entry/common.c:47<br /> [] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> In commit 24803f38a5c0 ("igmp: do not remove igmp souce list info when set<br /> link down"), the ip_mc_clear_src() in ip_mc_destroy_dev() was removed,<br /> because it was also called in igmpv3_clear_delrec().<br /> <br /> Rough callgraph:<br /> <br /> inetdev_destroy<br /> -&gt; ip_mc_destroy_dev<br /> -&gt; igmpv3_clear_delrec<br /> -&gt; ip_mc_clear_src<br /> -&gt; RCU_INIT_POINTER(dev-&gt;ip_ptr, NULL)<br /> <br /> However, ip_mc_clear_src() called in igmpv3_clear_delrec() doesn&amp;#39;t<br /> release in_dev-&gt;mc_list-&gt;sources. And RCU_INIT_POINTER() assigns the<br /> NULL to dev-&gt;ip_ptr. As a result, in_dev cannot be obtained through<br /> inetdev_by_index() and then in_dev-&gt;mc_list-&gt;sources cannot be released<br /> by ip_mc_del1_src() in the sock_close. Rough call sequence goes like:<br /> <br /> sock_close<br /> -&gt; __sock_release<br /> -&gt; inet_release<br /> -&gt; ip_mc_drop_socket<br /> -&gt; inetdev_by_index<br /> -&gt; ip_mc_leave_src<br /> -&gt; ip_mc_del_src<br /> -&gt; ip_mc_del1_src<br /> <br /> So we still need to call ip_mc_clear_src() in ip_mc_destroy_dev() to free<br /> in_dev-&gt;mc_list-&gt;sources.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: fix possible use-after-free in smsc75xx_bind<br /> <br /> The commit 46a8b29c6306 ("net: usb: fix memory leak in smsc75xx_bind")<br /> fails to clean up the work scheduled in smsc75xx_reset-&gt;<br /> smsc75xx_set_multicast, which leads to use-after-free if the work is<br /> scheduled to start after the deallocation. In addition, this patch<br /> also removes a dangling pointer - dev-&gt;data[0].<br /> <br /> This patch calls cancel_work_sync to cancel the scheduled work and set<br /> the dangling pointer to NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: qrtr: fix OOB Read in qrtr_endpoint_post<br /> <br /> Syzbot reported slab-out-of-bounds Read in<br /> qrtr_endpoint_post. The problem was in wrong<br /> _size_ type:<br /> <br /> if (len != ALIGN(size, 4) + hdrlen)<br /> goto err;<br /> <br /> If size from qrtr_hdr is 4294967293 (0xfffffffd), the result of<br /> ALIGN(size, 4) will be 0. In case of len == hdrlen and size == 4294967293<br /> in header this check won&amp;#39;t fail and<br /> <br /> skb_put_data(skb, data + hdrlen, size);<br /> <br /> will read out of bound from data, which is hdrlen allocated block.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ethtool: strset: fix message length calculation<br /> <br /> Outer nest for ETHTOOL_A_STRSET_STRINGSETS is not accounted for.<br /> This may result in ETHTOOL_MSG_STRSET_GET producing a warning like:<br /> <br /> calculated message payload length (684) not sufficient<br /> WARNING: CPU: 0 PID: 30967 at net/ethtool/netlink.c:369 ethnl_default_doit+0x87a/0xa20<br /> <br /> and a splat.<br /> <br /> As usually with such warnings three conditions must be met for the warning<br /> to trigger:<br /> - there must be no skb size rounding up (e.g. reply_size of 684);<br /> - string set must be per-device (so that the header gets populated);<br /> - the device name must be at least 12 characters long.<br /> <br /> all in all with current user space it looks like reading priv flags<br /> is the only place this could potentially happen. Or with syzbot :)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: fix soft lookup in subflow_error_report()<br /> <br /> Maxim reported a soft lookup in subflow_error_report():<br /> <br /> watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0]<br /> RIP: 0010:native_queued_spin_lock_slowpath<br /> RSP: 0018:ffffa859c0003bc0 EFLAGS: 00000202<br /> RAX: 0000000000000101 RBX: 0000000000000001 RCX: 0000000000000000<br /> RDX: ffff9195c2772d88 RSI: 0000000000000000 RDI: ffff9195c2772d88<br /> RBP: ffff9195c2772d00 R08: 00000000000067b0 R09: c6e31da9eb1e44f4<br /> R10: ffff9195ef379700 R11: ffff9195edb50710 R12: ffff9195c2772d88<br /> R13: ffff9195f500e3d0 R14: ffff9195ef379700 R15: ffff9195ef379700<br /> FS: 0000000000000000(0000) GS:ffff91961f400000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000000c000407000 CR3: 0000000002988000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> _raw_spin_lock_bh<br /> subflow_error_report<br /> mptcp_subflow_data_available<br /> __mptcp_move_skbs_from_subflow<br /> mptcp_data_ready<br /> tcp_data_queue<br /> tcp_rcv_established<br /> tcp_v4_do_rcv<br /> tcp_v4_rcv<br /> ip_protocol_deliver_rcu<br /> ip_local_deliver_finish<br /> __netif_receive_skb_one_core<br /> netif_receive_skb<br /> rtl8139_poll 8139too<br /> __napi_poll<br /> net_rx_action<br /> __do_softirq<br /> __irq_exit_rcu<br /> common_interrupt<br /> <br /> <br /> The calling function - mptcp_subflow_data_available() - can be invoked<br /> from different contexts:<br /> - plain ssk socket lock<br /> - ssk socket lock + mptcp_data_lock<br /> - ssk socket lock + mptcp_data_lock + msk socket lock.<br /> <br /> Since subflow_error_report() tries to acquire the mptcp_data_lock, the<br /> latter two call chains will cause soft lookup.<br /> <br /> This change addresses the issue moving the error reporting call to<br /> outer functions, where the held locks list is known and the we can<br /> acquire only the needed one.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sch_cake: Fix out of bounds when parsing TCP options and header<br /> <br /> The TCP option parser in cake qdisc (cake_get_tcpopt and<br /> cake_tcph_may_drop) could read one byte out of bounds. When the length<br /> is 1, the execution flow gets into the loop, reads one byte of the<br /> opcode, and if the opcode is neither TCPOPT_EOL nor TCPOPT_NOP, it reads<br /> one more byte, which exceeds the length of 1.<br /> <br /> This fix is inspired by commit 9609dad263f8 ("ipv4: tcp_input: fix stack<br /> out of bounds when parsing TCP options.").<br /> <br /> v2 changes:<br /> <br /> Added doff validation in cake_get_tcphdr to avoid parsing garbage as TCP<br /> header. Although it wasn&amp;#39;t strictly an out-of-bounds access (memory was<br /> allocated), garbage values could be read where CAKE expected the TCP<br /> header if doff was smaller than 5.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: Fix out of bounds when parsing TCP options<br /> <br /> The TCP option parser in mptcp (mptcp_get_options) could read one byte<br /> out of bounds. When the length is 1, the execution flow gets into the<br /> loop, reads one byte of the opcode, and if the opcode is neither<br /> TCPOPT_EOL nor TCPOPT_NOP, it reads one more byte, which exceeds the<br /> length of 1.<br /> <br /> This fix is inspired by commit 9609dad263f8 ("ipv4: tcp_input: fix stack<br /> out of bounds when parsing TCP options.").

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: synproxy: Fix out of bounds when parsing TCP options<br /> <br /> The TCP option parser in synproxy (synproxy_parse_options) could read<br /> one byte out of bounds. When the length is 1, the execution flow gets<br /> into the loop, reads one byte of the opcode, and if the opcode is<br /> neither TCPOPT_EOL nor TCPOPT_NOP, it reads one more byte, which exceeds<br /> the length of 1.<br /> <br /> This fix is inspired by commit 9609dad263f8 ("ipv4: tcp_input: fix stack<br /> out of bounds when parsing TCP options.").<br /> <br /> v2 changes:<br /> <br /> Added an early return when length