Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ftrace: Do not blindly read the ip address in ftrace_bug()<br /> <br /> It was reported that a bug on arm64 caused a bad ip address to be used for<br /> updating into a nop in ftrace_init(), but the error path (rightfully)<br /> returned -EINVAL and not -EFAULT, as the bug caused more than one error to<br /> occur. But because -EINVAL was returned, the ftrace_bug() tried to report<br /> what was at the location of the ip address, and read it directly. This<br /> caused the machine to panic, as the ip was not pointing to a valid memory<br /> address.<br /> <br /> Instead, read the ip address with copy_from_kernel_nofault() to safely<br /> access the memory, and if it faults, report that the address faulted,<br /> otherwise report what was in that location.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mac80211: fix skb length check in ieee80211_scan_rx()<br /> <br /> Replace hard-coded compile-time constants for header length check<br /> with dynamic determination based on the frame type. Otherwise, we<br /> hit a validation WARN_ON in cfg80211 later.<br /> <br /> [style fixes, reword commit message]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: Avoid WARN_ON timing related checks<br /> <br /> The soft/batadv interface for a queued OGM can be changed during the time<br /> the OGM was queued for transmission and when the OGM is actually<br /> transmitted by the worker.<br /> <br /> But WARN_ON must be used to denote kernel bugs and not to print simple<br /> warnings. A warning can simply be printed using pr_warn.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix potential memory leak in DMUB hw_init<br /> <br /> [Why]<br /> On resume we perform DMUB hw_init which allocates memory:<br /> dm_resume-&gt;dm_dmub_hw_init-&gt;dc_dmub_srv_create-&gt;kzalloc<br /> That results in memory leak in suspend/resume scenarios.<br /> <br /> [How]<br /> Allocate memory for the DC wrapper to DMUB only if it was not<br /> allocated before.<br /> No need to reallocate it on suspend/resume.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kvm: LAPIC: Restore guard to prevent illegal APIC register access<br /> <br /> Per the SDM, "any access that touches bytes 4 through 15 of an APIC<br /> register may cause undefined behavior and must not be executed."<br /> Worse, such an access in kvm_lapic_reg_read can result in a leak of<br /> kernel stack contents. Prior to commit 01402cf81051 ("kvm: LAPIC:<br /> write down valid APIC registers"), such an access was explicitly<br /> disallowed. Restore the guard that was removed in that commit.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/memory-failure: make sure wait for page writeback in memory_failure<br /> <br /> Our syzkaller trigger the "BUG_ON(!list_empty(&amp;inode-&gt;i_wb_list))" in<br /> clear_inode:<br /> <br /> kernel BUG at fs/inode.c:519!<br /> Internal error: Oops - BUG: 0 [#1] SMP<br /> Modules linked in:<br /> Process syz-executor.0 (pid: 249, stack limit = 0x00000000a12409d7)<br /> CPU: 1 PID: 249 Comm: syz-executor.0 Not tainted 4.19.95<br /> Hardware name: linux,dummy-virt (DT)<br /> pstate: 80000005 (Nzcv daif -PAN -UAO)<br /> pc : clear_inode+0x280/0x2a8<br /> lr : clear_inode+0x280/0x2a8<br /> Call trace:<br /> clear_inode+0x280/0x2a8<br /> ext4_clear_inode+0x38/0xe8<br /> ext4_free_inode+0x130/0xc68<br /> ext4_evict_inode+0xb20/0xcb8<br /> evict+0x1a8/0x3c0<br /> iput+0x344/0x460<br /> do_unlinkat+0x260/0x410<br /> __arm64_sys_unlinkat+0x6c/0xc0<br /> el0_svc_common+0xdc/0x3b0<br /> el0_svc_handler+0xf8/0x160<br /> el0_svc+0x10/0x218<br /> Kernel panic - not syncing: Fatal exception<br /> <br /> A crash dump of this problem show that someone called __munlock_pagevec<br /> to clear page LRU without lock_page: do_mmap -&gt; mmap_region -&gt; do_munmap<br /> -&gt; munlock_vma_pages_range -&gt; __munlock_pagevec.<br /> <br /> As a result memory_failure will call identify_page_state without<br /> wait_on_page_writeback. And after truncate_error_page clear the mapping<br /> of this page. end_page_writeback won&amp;#39;t call sb_clear_inode_writeback to<br /> clear inode-&gt;i_wb_list. That will trigger BUG_ON in clear_inode!<br /> <br /> Fix it by checking PageWriteback too to help determine should we skip<br /> wait_on_page_writeback.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ieee802154: fix null deref in parse dev addr<br /> <br /> Fix a logic error that could result in a null deref if the user sets<br /> the mode incorrectly for the given addr type.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: core: Fix error handling of scsi_host_alloc()<br /> <br /> After device is initialized via device_initialize(), or its name is set via<br /> dev_set_name(), the device has to be freed via put_device(). Otherwise<br /> device name will be leaked because it is allocated dynamically in<br /> dev_set_name().<br /> <br /> Fix the leak by replacing kfree() with put_device(). Since<br /> scsi_host_dev_release() properly handles IDA and kthread removal, remove<br /> special-casing these from the error handling as well.

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