Vulnerabilities

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 /> gfs2: Fix use-after-free in gfs2_glock_shrink_scan<br /> <br /> The GLF_LRU flag is checked under lru_lock in gfs2_glock_remove_from_lru() to<br /> remove the glock from the lru list in __gfs2_glock_put().<br /> <br /> On the shrink scan path, the same flag is cleared under lru_lock but because<br /> of cond_resched_lock(&amp;lru_lock) in gfs2_dispose_glock_lru(), progress on the<br /> put side can be made without deleting the glock from the lru list.<br /> <br /> Keep GLF_LRU across the race window opened by cond_resched_lock(&amp;lru_lock) to<br /> ensure correct behavior on both sides - clear GLF_LRU after list_del under<br /> lru_lock.

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

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.