Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: mts64: fix possible null-ptr-defer in snd_mts64_interrupt<br /> <br /> I got a null-ptr-defer error report when I do the following tests<br /> on the qemu platform:<br /> <br /> make defconfig and CONFIG_PARPORT=m, CONFIG_PARPORT_PC=m,<br /> CONFIG_SND_MTS64=m<br /> <br /> Then making test scripts:<br /> cat&gt;test_mod1.sh

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: qat - fix DMA transfer direction<br /> <br /> When CONFIG_DMA_API_DEBUG is selected, while running the crypto self<br /> test on the QAT crypto algorithms, the function add_dma_entry() reports<br /> a warning similar to the one below, saying that overlapping mappings<br /> are not supported. This occurs in tests where the input and the output<br /> scatter list point to the same buffers (i.e. two different scatter lists<br /> which point to the same chunks of memory).<br /> <br /> The logic that implements the mapping uses the flag DMA_BIDIRECTIONAL<br /> for both the input and the output scatter lists which leads to<br /> overlapped write mappings. These are not supported by the DMA layer.<br /> <br /> Fix by specifying the correct DMA transfer directions when mapping<br /> buffers. For in-place operations where the input scatter list<br /> matches the output scatter list, buffers are mapped once with<br /> DMA_BIDIRECTIONAL, otherwise input buffers are mapped using the flag<br /> DMA_TO_DEVICE and output buffers are mapped with DMA_FROM_DEVICE.<br /> Overlapping a read mapping with a write mapping is a valid case in<br /> dma-coherent devices like QAT.<br /> The function that frees and unmaps the buffers, qat_alg_free_bufl()<br /> has been changed accordingly to the changes to the mapping function.<br /> <br /> DMA-API: 4xxx 0000:06:00.0: cacheline tracking EEXIST, overlapping mappings aren&amp;#39;t supported<br /> WARNING: CPU: 53 PID: 4362 at kernel/dma/debug.c:570 add_dma_entry+0x1e9/0x270<br /> ...<br /> Call Trace:<br /> dma_map_page_attrs+0x82/0x2d0<br /> ? preempt_count_add+0x6a/0xa0<br /> qat_alg_sgl_to_bufl+0x45b/0x990 [intel_qat]<br /> qat_alg_aead_dec+0x71/0x250 [intel_qat]<br /> crypto_aead_decrypt+0x3d/0x70<br /> test_aead_vec_cfg+0x649/0x810<br /> ? number+0x310/0x3a0<br /> ? vsnprintf+0x2a3/0x550<br /> ? scnprintf+0x42/0x70<br /> ? valid_sg_divisions.constprop.0+0x86/0xa0<br /> ? test_aead_vec+0xdf/0x120<br /> test_aead_vec+0xdf/0x120<br /> alg_test_aead+0x185/0x400<br /> alg_test+0x3d8/0x500<br /> ? crypto_acomp_scomp_free_ctx+0x30/0x30<br /> ? __schedule+0x32a/0x12a0<br /> ? ttwu_queue_wakelist+0xbf/0x110<br /> ? _raw_spin_unlock_irqrestore+0x23/0x40<br /> ? try_to_wake_up+0x83/0x570<br /> ? _raw_spin_unlock_irqrestore+0x23/0x40<br /> ? __set_cpus_allowed_ptr_locked+0xea/0x1b0<br /> ? crypto_acomp_scomp_free_ctx+0x30/0x30<br /> cryptomgr_test+0x27/0x50<br /> kthread+0xe6/0x110<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork+0x1f/0x30

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/hns: Fix refcount leak in hns_roce_mmap<br /> <br /> rdma_user_mmap_entry_get_pgoff() takes the reference.<br /> Add missing rdma_user_mmap_entry_put() to release the reference.<br /> <br /> Acked-by Haoyue Xu

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: st: Fix memory leak in st_of_quadfs_setup()<br /> <br /> If st_clk_register_quadfs_pll() fails, @lock should be freed before goto<br /> @err_exit, otherwise will cause meory leak issue, fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: phy: xgmiitorgmii: Fix refcount leak in xgmiitorgmii_probe<br /> <br /> of_phy_find_device() return device node with refcount incremented.<br /> Call put_device() to relese it when not needed anymore.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fortify: Fix __compiletime_strlen() under UBSAN_BOUNDS_LOCAL<br /> <br /> With CONFIG_FORTIFY=y and CONFIG_UBSAN_LOCAL_BOUNDS=y enabled, we observe<br /> a runtime panic while running Android&amp;#39;s Compatibility Test Suite&amp;#39;s (CTS)<br /> android.hardware.input.cts.tests. This is stemming from a strlen()<br /> call in hidinput_allocate().<br /> <br /> __compiletime_strlen() is implemented in terms of __builtin_object_size(),<br /> then does an array access to check for NUL-termination. A quirk of<br /> __builtin_object_size() is that for strings whose values are runtime<br /> dependent, __builtin_object_size(str, 1 or 0) returns the maximum size<br /> of possible values when those sizes are determinable at compile time.<br /> Example:<br /> <br /> static const char *v = "FOO BAR";<br /> static const char *y = "FOO BA";<br /> unsigned long x (int z) {<br /> // Returns 8, which is:<br /> // max(__builtin_object_size(v, 1), __builtin_object_size(y, 1))<br /> return __builtin_object_size(z ? v : y, 1);<br /> }<br /> <br /> So when FORTIFY_SOURCE is enabled, the current implementation of<br /> __compiletime_strlen() will try to access beyond the end of y at runtime<br /> using the size of v. Mixed with UBSAN_LOCAL_BOUNDS we get a fault.<br /> <br /> hidinput_allocate() has a local C string whose value is control flow<br /> dependent on a switch statement, so __builtin_object_size(str, 1)<br /> evaluates to the maximum string length, making all other cases fault on<br /> the last character check. hidinput_allocate() could be cleaned up to<br /> avoid runtime calls to strlen() since the local variable can only have<br /> literal values, so there&amp;#39;s no benefit to trying to fortify the strlen<br /> call site there.<br /> <br /> Perform a __builtin_constant_p() check against index 0 earlier in the<br /> macro to filter out the control-flow-dependant case. Add a KUnit test<br /> for checking the expected behavioral characteristics of FORTIFY_SOURCE<br /> internals.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> orangefs: Fix kmemleak in orangefs_prepare_debugfs_help_string()<br /> <br /> When insert and remove the orangefs module, then debug_help_string will<br /> be leaked:<br /> <br /> unreferenced object 0xffff8881652ba000 (size 4096):<br /> comm "insmod", pid 1701, jiffies 4294893639 (age 13218.530s)<br /> hex dump (first 32 bytes):<br /> 43 6c 69 65 6e 74 20 44 65 62 75 67 20 4b 65 79 Client Debug Key<br /> 77 6f 72 64 73 20 61 72 65 20 75 6e 6b 6e 6f 77 words are unknow<br /> backtrace:<br /> [] kmalloc_trace+0x27/0xa0<br /> [] orangefs_prepare_debugfs_help_string+0x5e/0x480 [orangefs]<br /> [] _sub_I_65535_1+0x57/0xf70 [crc_itu_t]<br /> [] do_one_initcall+0x87/0x2a0<br /> [] do_init_module+0xdf/0x320<br /> [] load_module+0x2f98/0x3330<br /> [] __do_sys_finit_module+0x113/0x1b0<br /> [] do_syscall_64+0x35/0x80<br /> [] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> When remove the module, should always free debug_help_string. Should<br /> always free the allocated buffer when change the free_debug_help_string.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: fix UAF issue in nfqnl_nf_hook_drop() when ops_init() failed<br /> <br /> When the ops_init() interface is invoked to initialize the net, but<br /> ops-&gt;init() fails, data is released. However, the ptr pointer in<br /> net-&gt;gen is invalid. In this case, when nfqnl_nf_hook_drop() is invoked<br /> to release the net, invalid address access occurs.<br /> <br /> The process is as follows:<br /> setup_net()<br /> ops_init()<br /> data = kzalloc(...) ---&gt; alloc "data"<br /> net_assign_generic() ---&gt; assign "date" to ptr in net-&gt;gen<br /> ...<br /> ops-&gt;init() ---&gt; failed<br /> ...<br /> kfree(data); ---&gt; ptr in net-&gt;gen is invalid<br /> ...<br /> ops_exit_list()<br /> ...<br /> nfqnl_nf_hook_drop()<br /> *q = nfnl_queue_pernet(net) ---&gt; q is invalid<br /> <br /> The following is the Call Trace information:<br /> BUG: KASAN: use-after-free in nfqnl_nf_hook_drop+0x264/0x280<br /> Read of size 8 at addr ffff88810396b240 by task ip/15855<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x8e/0xd1<br /> print_report+0x155/0x454<br /> kasan_report+0xba/0x1f0<br /> nfqnl_nf_hook_drop+0x264/0x280<br /> nf_queue_nf_hook_drop+0x8b/0x1b0<br /> __nf_unregister_net_hook+0x1ae/0x5a0<br /> nf_unregister_net_hooks+0xde/0x130<br /> ops_exit_list+0xb0/0x170<br /> setup_net+0x7ac/0xbd0<br /> copy_net_ns+0x2e6/0x6b0<br /> create_new_namespaces+0x382/0xa50<br /> unshare_nsproxy_namespaces+0xa6/0x1c0<br /> ksys_unshare+0x3a4/0x7e0<br /> __x64_sys_unshare+0x2d/0x40<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> <br /> Allocated by task 15855:<br /> kasan_save_stack+0x1e/0x40<br /> kasan_set_track+0x21/0x30<br /> __kasan_kmalloc+0xa1/0xb0<br /> __kmalloc+0x49/0xb0<br /> ops_init+0xe7/0x410<br /> setup_net+0x5aa/0xbd0<br /> copy_net_ns+0x2e6/0x6b0<br /> create_new_namespaces+0x382/0xa50<br /> unshare_nsproxy_namespaces+0xa6/0x1c0<br /> ksys_unshare+0x3a4/0x7e0<br /> __x64_sys_unshare+0x2d/0x40<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> Freed by task 15855:<br /> kasan_save_stack+0x1e/0x40<br /> kasan_set_track+0x21/0x30<br /> kasan_save_free_info+0x2a/0x40<br /> ____kasan_slab_free+0x155/0x1b0<br /> slab_free_freelist_hook+0x11b/0x220<br /> __kmem_cache_free+0xa4/0x360<br /> ops_init+0xb9/0x410<br /> setup_net+0x5aa/0xbd0<br /> copy_net_ns+0x2e6/0x6b0<br /> create_new_namespaces+0x382/0xa50<br /> unshare_nsproxy_namespaces+0xa6/0x1c0<br /> ksys_unshare+0x3a4/0x7e0<br /> __x64_sys_unshare+0x2d/0x40<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> amdgpu/pm: prevent array underflow in vega20_odn_edit_dpm_table()<br /> <br /> In the PP_OD_EDIT_VDDC_CURVE case the "input_index" variable is capped at<br /> 2 but not checked for negative values so it results in an out of bounds<br /> read. This value comes from the user via sysfs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: marvell/octeontx - prevent integer overflows<br /> <br /> The "code_length" value comes from the firmware file. If your firmware<br /> is untrusted realistically there is probably very little you can do to<br /> protect yourself. Still we try to limit the damage as much as possible.<br /> Also Smatch marks any data read from the filesystem as untrusted and<br /> prints warnings if it not capped correctly.<br /> <br /> The "code_length * 2" can overflow. The round_up(ucode_size, 16) +<br /> sizeof() expression can overflow too. Prevent these overflows.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6/sit: use DEV_STATS_INC() to avoid data-races<br /> <br /> syzbot/KCSAN reported that multiple cpus are updating dev-&gt;stats.tx_error<br /> concurrently.<br /> <br /> This is because sit tunnels are NETIF_F_LLTX, meaning their ndo_start_xmit()<br /> is not protected by a spinlock.<br /> <br /> While original KCSAN report was about tx path, rx path has the same issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RISC-V: kexec: Fix memory leak of elf header buffer<br /> <br /> This is reported by kmemleak detector:<br /> <br /> unreferenced object 0xff2000000403d000 (size 4096):<br /> comm "kexec", pid 146, jiffies 4294900633 (age 64.792s)<br /> hex dump (first 32 bytes):<br /> 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 .ELF............<br /> 04 00 f3 00 01 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] kmemleak_vmalloc+0x3c/0xbe<br /> [] __vmalloc_node_range+0x3ac/0x560<br /> [] __vmalloc_node+0x56/0x62<br /> [] vzalloc+0x2c/0x34<br /> [] crash_prepare_elf64_headers+0x80/0x30c<br /> [] elf_kexec_load+0x3e8/0x4ec<br /> [] kexec_image_load_default+0x40/0x4c<br /> [] sys_kexec_file_load+0x1c4/0x322<br /> [] ret_from_syscall+0x0/0x2<br /> <br /> In elf_kexec_load(), a buffer is allocated via vzalloc() to store elf<br /> headers. While it&amp;#39;s not freed back to system when kdump kernel is<br /> reloaded or unloaded, or when image-&gt;elf_header is successfully set and<br /> then fails to load kdump kernel for some reason. Fix it by freeing the<br /> buffer in arch_kimage_file_post_load_cleanup().