Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hns3: put off calling register_netdev() until client initialize complete<br /> <br /> Currently, the netdevice is registered before client initializing<br /> complete. So there is a timewindow between netdevice available<br /> and usable. In this case, if user try to change the channel number<br /> or ring param, it may cause the hns3_set_rx_cpu_rmap() being called<br /> twice, and report bug.<br /> <br /> [47199.416502] hns3 0000:35:00.0 eth1: set channels: tqp_num=1, rxfh=0<br /> [47199.430340] hns3 0000:35:00.0 eth1: already uninitialized<br /> [47199.438554] hns3 0000:35:00.0: rss changes from 4 to 1<br /> [47199.511854] hns3 0000:35:00.0: Channels changed, rss_size from 4 to 1, tqps from 4 to 1<br /> [47200.163524] ------------[ cut here ]------------<br /> [47200.171674] kernel BUG at lib/cpu_rmap.c:142!<br /> [47200.177847] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP<br /> [47200.185259] Modules linked in: hclge(+) hns3(-) hns3_cae(O) hns_roce_hw_v2 hnae3 vfio_iommu_type1 vfio_pci vfio_virqfd vfio pv680_mii(O) [last unloaded: hclge]<br /> [47200.205912] CPU: 1 PID: 8260 Comm: ethtool Tainted: G O 5.11.0-rc3+ #1<br /> [47200.215601] Hardware name: , xxxxxx 02/04/2021<br /> [47200.223052] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--)<br /> [47200.230188] pc : cpu_rmap_add+0x38/0x40<br /> [47200.237472] lr : irq_cpu_rmap_add+0x84/0x140<br /> [47200.243291] sp : ffff800010e93a30<br /> [47200.247295] x29: ffff800010e93a30 x28: ffff082100584880<br /> [47200.254155] x27: 0000000000000000 x26: 0000000000000000<br /> [47200.260712] x25: 0000000000000000 x24: 0000000000000004<br /> [47200.267241] x23: ffff08209ba03000 x22: ffff08209ba038c0<br /> [47200.273789] x21: 000000000000003f x20: ffff0820e2bc1680<br /> [47200.280400] x19: ffff0820c970ec80 x18: 00000000000000c0<br /> [47200.286944] x17: 0000000000000000 x16: ffffb43debe4a0d0<br /> [47200.293456] x15: fffffc2082990600 x14: dead000000000122<br /> [47200.300059] x13: ffffffffffffffff x12: 000000000000003e<br /> [47200.306606] x11: ffff0820815b8080 x10: ffff53e411988000<br /> [47200.313171] x9 : 0000000000000000 x8 : ffff0820e2bc1700<br /> [47200.319682] x7 : 0000000000000000 x6 : 000000000000003f<br /> [47200.326170] x5 : 0000000000000040 x4 : ffff800010e93a20<br /> [47200.332656] x3 : 0000000000000004 x2 : ffff0820c970ec80<br /> [47200.339168] x1 : ffff0820e2bc1680 x0 : 0000000000000004<br /> [47200.346058] Call trace:<br /> [47200.349324] cpu_rmap_add+0x38/0x40<br /> [47200.354300] hns3_set_rx_cpu_rmap+0x6c/0xe0 [hns3]<br /> [47200.362294] hns3_reset_notify_init_enet+0x1cc/0x340 [hns3]<br /> [47200.370049] hns3_change_channels+0x40/0xb0 [hns3]<br /> [47200.376770] hns3_set_channels+0x12c/0x2a0 [hns3]<br /> [47200.383353] ethtool_set_channels+0x140/0x250<br /> [47200.389772] dev_ethtool+0x714/0x23d0<br /> [47200.394440] dev_ioctl+0x4cc/0x640<br /> [47200.399277] sock_do_ioctl+0x100/0x2a0<br /> [47200.404574] sock_ioctl+0x28c/0x470<br /> [47200.409079] __arm64_sys_ioctl+0xb4/0x100<br /> [47200.415217] el0_svc_common.constprop.0+0x84/0x210<br /> [47200.422088] do_el0_svc+0x28/0x34<br /> [47200.426387] el0_svc+0x28/0x70<br /> [47200.431308] el0_sync_handler+0x1a4/0x1b0<br /> [47200.436477] el0_sync+0x174/0x180<br /> [47200.441562] Code: 11000405 79000c45 f8247861 d65f03c0 (d4210000)<br /> [47200.448869] ---[ end trace a01efe4ce42e5f34 ]---<br /> <br /> The process is like below:<br /> excuting hns3_client_init<br /> |<br /> register_netdev()<br /> | hns3_set_channels()<br /> | |<br /> hns3_set_rx_cpu_rmap() hns3_reset_notify_uninit_enet()<br /> | |<br /> | quit without calling function<br /> | hns3_free_rx_cpu_rmap for flag<br /> | HNS3_NIC_STATE_INITED is unset.<br /> | |<br /> | hns3_reset_notify_init_enet()<br /> | |<br /> set HNS3_NIC_STATE_INITED call hns3_set_rx_cpu_rmap()-- crash<br /> <br /> Fix it by calling register_netdev() at the end of function<br /> hns3_client_init().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/amd: Clear DMA ops when switching domain<br /> <br /> Since commit 08a27c1c3ecf ("iommu: Add support to change default domain<br /> of an iommu group") a user can switch a device between IOMMU and direct<br /> DMA through sysfs. This doesn&amp;#39;t work for AMD IOMMU at the moment because<br /> dev-&gt;dma_ops is not cleared when switching from a DMA to an identity<br /> IOMMU domain. The DMA layer thus attempts to use the dma-iommu ops on an<br /> identity domain, causing an oops:<br /> <br /> # echo 0000:00:05.0 &gt; /sys/sys/bus/pci/drivers/e1000e/unbind<br /> # echo identity &gt; /sys/bus/pci/devices/0000:00:05.0/iommu_group/type<br /> # echo 0000:00:05.0 &gt; /sys/sys/bus/pci/drivers/e1000e/bind<br /> ...<br /> BUG: kernel NULL pointer dereference, address: 0000000000000028<br /> ...<br /> Call Trace:<br /> iommu_dma_alloc<br /> e1000e_setup_tx_resources<br /> e1000e_open<br /> <br /> Since iommu_change_dev_def_domain() calls probe_finalize() again, clear<br /> the dma_ops there like Vt-d does.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gve: Add NULL pointer checks when freeing irqs.<br /> <br /> When freeing notification blocks, we index priv-&gt;msix_vectors.<br /> If we failed to allocate priv-&gt;msix_vectors (see abort_with_msix_vectors)<br /> this could lead to a NULL pointer dereference if the driver is unloaded.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Fix a use-after-free<br /> <br /> looks like we forget to set ttm-&gt;sg to NULL.<br /> Hit panic below<br /> <br /> [ 1235.844104] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b7b4b: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI<br /> [ 1235.989074] Call Trace:<br /> [ 1235.991751] sg_free_table+0x17/0x20<br /> [ 1235.995667] amdgpu_ttm_backend_unbind.cold+0x4d/0xf7 [amdgpu]<br /> [ 1236.002288] amdgpu_ttm_backend_destroy+0x29/0x130 [amdgpu]<br /> [ 1236.008464] ttm_tt_destroy+0x1e/0x30 [ttm]<br /> [ 1236.013066] ttm_bo_cleanup_memtype_use+0x51/0xa0 [ttm]<br /> [ 1236.018783] ttm_bo_release+0x262/0xa50 [ttm]<br /> [ 1236.023547] ttm_bo_put+0x82/0xd0 [ttm]<br /> [ 1236.027766] amdgpu_bo_unref+0x26/0x50 [amdgpu]<br /> [ 1236.032809] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x7aa/0xd90 [amdgpu]<br /> [ 1236.040400] kfd_ioctl_alloc_memory_of_gpu+0xe2/0x330 [amdgpu]<br /> [ 1236.046912] kfd_ioctl+0x463/0x690 [amdgpu]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: remove device from smcd_dev_list after failed device_add()<br /> <br /> If the device_add() for a smcd_dev fails, there&amp;#39;s no cleanup step that<br /> rolls back the earlier list_add(). The device subsequently gets freed,<br /> and we end up with a corrupted list.<br /> <br /> Add some error handling that removes the device from the list.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: do not BUG_ON in link_to_fixup_dir<br /> <br /> While doing error injection testing I got the following panic<br /> <br /> kernel BUG at fs/btrfs/tree-log.c:1862!<br /> invalid opcode: 0000 [#1] SMP NOPTI<br /> CPU: 1 PID: 7836 Comm: mount Not tainted 5.13.0-rc1+ #305<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014<br /> RIP: 0010:link_to_fixup_dir+0xd5/0xe0<br /> RSP: 0018:ffffb5800180fa30 EFLAGS: 00010216<br /> RAX: fffffffffffffffb RBX: 00000000fffffffb RCX: ffff8f595287faf0<br /> RDX: ffffb5800180fa37 RSI: ffff8f5954978800 RDI: 0000000000000000<br /> RBP: ffff8f5953af9450 R08: 0000000000000019 R09: 0000000000000001<br /> R10: 000151f408682970 R11: 0000000120021001 R12: ffff8f5954978800<br /> R13: ffff8f595287faf0 R14: ffff8f5953c77dd0 R15: 0000000000000065<br /> FS: 00007fc5284c8c40(0000) GS:ffff8f59bbd00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fc5287f47c0 CR3: 000000011275e002 CR4: 0000000000370ee0<br /> Call Trace:<br /> replay_one_buffer+0x409/0x470<br /> ? btree_read_extent_buffer_pages+0xd0/0x110<br /> walk_up_log_tree+0x157/0x1e0<br /> walk_log_tree+0xa6/0x1d0<br /> btrfs_recover_log_trees+0x1da/0x360<br /> ? replay_one_extent+0x7b0/0x7b0<br /> open_ctree+0x1486/0x1720<br /> btrfs_mount_root.cold+0x12/0xea<br /> ? __kmalloc_track_caller+0x12f/0x240<br /> legacy_get_tree+0x24/0x40<br /> vfs_get_tree+0x22/0xb0<br /> vfs_kern_mount.part.0+0x71/0xb0<br /> btrfs_mount+0x10d/0x380<br /> ? vfs_parse_fs_string+0x4d/0x90<br /> legacy_get_tree+0x24/0x40<br /> vfs_get_tree+0x22/0xb0<br /> path_mount+0x433/0xa10<br /> __x64_sys_mount+0xe3/0x120<br /> do_syscall_64+0x3d/0x80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> We can get -EIO or any number of legitimate errors from<br /> btrfs_search_slot(), panicing here is not the appropriate response. The<br /> error path for this code handles errors properly, simply return the<br /> error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: zero-initialize tc skb extension on allocation<br /> <br /> Function skb_ext_add() doesn&amp;#39;t initialize created skb extension with any<br /> value and leaves it up to the user. However, since extension of type<br /> TC_SKB_EXT originally contained only single value tc_skb_ext-&gt;chain its<br /> users used to just assign the chain value without setting whole extension<br /> memory to zero first. This assumption changed when TC_SKB_EXT extension was<br /> extended with additional fields but not all users were updated to<br /> initialize the new fields which leads to use of uninitialized memory<br /> afterwards. UBSAN log:<br /> <br /> [ 778.299821] UBSAN: invalid-load in net/openvswitch/flow.c:899:28<br /> [ 778.301495] load of value 107 is not a valid value for type &amp;#39;_Bool&amp;#39;<br /> [ 778.303215] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.12.0-rc7+ #2<br /> [ 778.304933] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> [ 778.307901] Call Trace:<br /> [ 778.308680] <br /> [ 778.309358] dump_stack+0xbb/0x107<br /> [ 778.310307] ubsan_epilogue+0x5/0x40<br /> [ 778.311167] __ubsan_handle_load_invalid_value.cold+0x43/0x48<br /> [ 778.312454] ? memset+0x20/0x40<br /> [ 778.313230] ovs_flow_key_extract.cold+0xf/0x14 [openvswitch]<br /> [ 778.314532] ovs_vport_receive+0x19e/0x2e0 [openvswitch]<br /> [ 778.315749] ? ovs_vport_find_upcall_portid+0x330/0x330 [openvswitch]<br /> [ 778.317188] ? create_prof_cpu_mask+0x20/0x20<br /> [ 778.318220] ? arch_stack_walk+0x82/0xf0<br /> [ 778.319153] ? secondary_startup_64_no_verify+0xb0/0xbb<br /> [ 778.320399] ? stack_trace_save+0x91/0xc0<br /> [ 778.321362] ? stack_trace_consume_entry+0x160/0x160<br /> [ 778.322517] ? lock_release+0x52e/0x760<br /> [ 778.323444] netdev_frame_hook+0x323/0x610 [openvswitch]<br /> [ 778.324668] ? ovs_netdev_get_vport+0xe0/0xe0 [openvswitch]<br /> [ 778.325950] __netif_receive_skb_core+0x771/0x2db0<br /> [ 778.327067] ? lock_downgrade+0x6e0/0x6f0<br /> [ 778.328021] ? lock_acquire+0x565/0x720<br /> [ 778.328940] ? generic_xdp_tx+0x4f0/0x4f0<br /> [ 778.329902] ? inet_gro_receive+0x2a7/0x10a0<br /> [ 778.330914] ? lock_downgrade+0x6f0/0x6f0<br /> [ 778.331867] ? udp4_gro_receive+0x4c4/0x13e0<br /> [ 778.332876] ? lock_release+0x52e/0x760<br /> [ 778.333808] ? dev_gro_receive+0xcc8/0x2380<br /> [ 778.334810] ? lock_downgrade+0x6f0/0x6f0<br /> [ 778.335769] __netif_receive_skb_list_core+0x295/0x820<br /> [ 778.336955] ? process_backlog+0x780/0x780<br /> [ 778.337941] ? mlx5e_rep_tc_netdevice_event_unregister+0x20/0x20 [mlx5_core]<br /> [ 778.339613] ? seqcount_lockdep_reader_access.constprop.0+0xa7/0xc0<br /> [ 778.341033] ? kvm_clock_get_cycles+0x14/0x20<br /> [ 778.342072] netif_receive_skb_list_internal+0x5f5/0xcb0<br /> [ 778.343288] ? __kasan_kmalloc+0x7a/0x90<br /> [ 778.344234] ? mlx5e_handle_rx_cqe_mpwrq+0x9e0/0x9e0 [mlx5_core]<br /> [ 778.345676] ? mlx5e_xmit_xdp_frame_mpwqe+0x14d0/0x14d0 [mlx5_core]<br /> [ 778.347140] ? __netif_receive_skb_list_core+0x820/0x820<br /> [ 778.348351] ? mlx5e_post_rx_mpwqes+0xa6/0x25d0 [mlx5_core]<br /> [ 778.349688] ? napi_gro_flush+0x26c/0x3c0<br /> [ 778.350641] napi_complete_done+0x188/0x6b0<br /> [ 778.351627] mlx5e_napi_poll+0x373/0x1b80 [mlx5_core]<br /> [ 778.352853] __napi_poll+0x9f/0x510<br /> [ 778.353704] ? mlx5_flow_namespace_set_mode+0x260/0x260 [mlx5_core]<br /> [ 778.355158] net_rx_action+0x34c/0xa40<br /> [ 778.356060] ? napi_threaded_poll+0x3d0/0x3d0<br /> [ 778.357083] ? sched_clock_cpu+0x18/0x190<br /> [ 778.358041] ? __common_interrupt+0x8e/0x1a0<br /> [ 778.359045] __do_softirq+0x1ce/0x984<br /> [ 778.359938] __irq_exit_rcu+0x137/0x1d0<br /> [ 778.360865] irq_exit_rcu+0xa/0x20<br /> [ 778.361708] common_interrupt+0x80/0xa0<br /> [ 778.362640] <br /> [ 778.363212] asm_common_interrupt+0x1e/0x40<br /> [ 778.364204] RIP: 0010:native_safe_halt+0xe/0x10<br /> [ 778.365273] Code: 4f ff ff ff 4c 89 e7 e8 50 3f 40 fe e9 dc fe ff ff 48 89 df e8 43 3f 40 fe eb 90 cc e9 07 00 00 00 0f 00 2d 74 05 62 00 fb f4 90 e9 07 00 00 00 0f 00 2d 64 05 62 00 f4 c3 cc cc 0f 1f 44 00<br /> [ 778.369355] RSP: 0018:ffffffff84407e48 EFLAGS: 00000246<br /> [ 778.370570] RAX<br /> ---truncated---

Anope before 2.0.15 does not prevent resetting the password of a suspended account.

This vulnerability allows remote attackers to traverse paths via file upload on the affected LG LED Assistant.

Improper Neutralization of Special Elements used in an OS Command (&amp;#39;OS Command Injection&amp;#39;), Improper Privilege Management vulnerability in openEuler migration-tools on Linux allows Command Injection, Restful Privilege Elevation. This vulnerability is associated with program files https://gitee.Com/openeuler/migration-tools/blob/master/index.Py.<br /> <br /> This issue affects migration-tools: from 1.0.0 through 1.0.1.<br /> <br />

Improper Neutralization of Special Elements used in a Command (&amp;#39;Command Injection&amp;#39;) vulnerability in openEuler A-Tune-Collector on Linux allows Command Injection. This vulnerability is associated with program files https://gitee.Com/openeuler/A-Tune-Collector/blob/master/atune_collector/plugin/monitor/process/sched.Py.<br /> <br /> This issue affects A-Tune-Collector: from 1.1.0-3 through 1.3.0.<br /> <br />