Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-pf: fix a buffer overflow in otx2_set_rxfh_context()<br /> <br /> This function is called from ethtool_set_rxfh() and "*rss_context"<br /> comes from the user. Add some bounds checking to prevent memory<br /> corruption.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mld: fix panic in mld_newpack()<br /> <br /> mld_newpack() doesn&amp;#39;t allow to allocate high order page,<br /> only order-0 allocation is allowed.<br /> If headroom size is too large, a kernel panic could occur in skb_put().<br /> <br /> Test commands:<br /> ip netns del A<br /> ip netns del B<br /> ip netns add A<br /> ip netns add B<br /> ip link add veth0 type veth peer name veth1<br /> ip link set veth0 netns A<br /> ip link set veth1 netns B<br /> <br /> ip netns exec A ip link set lo up<br /> ip netns exec A ip link set veth0 up<br /> ip netns exec A ip -6 a a 2001:db8:0::1/64 dev veth0<br /> ip netns exec B ip link set lo up<br /> ip netns exec B ip link set veth1 up<br /> ip netns exec B ip -6 a a 2001:db8:0::2/64 dev veth1<br /> for i in {1..99}<br /> do<br /> let A=$i-1<br /> ip netns exec A ip link add ip6gre$i type ip6gre \<br /> local 2001:db8:$A::1 remote 2001:db8:$A::2 encaplimit 100<br /> ip netns exec A ip -6 a a 2001:db8:$i::1/64 dev ip6gre$i<br /> ip netns exec A ip link set ip6gre$i up<br /> <br /> ip netns exec B ip link add ip6gre$i type ip6gre \<br /> local 2001:db8:$A::2 remote 2001:db8:$A::1 encaplimit 100<br /> ip netns exec B ip -6 a a 2001:db8:$i::2/64 dev ip6gre$i<br /> ip netns exec B ip link set ip6gre$i up<br /> done<br /> <br /> Splat looks like:<br /> kernel BUG at net/core/skbuff.c:110!<br /> invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI<br /> CPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.12.0+ #891<br /> Workqueue: ipv6_addrconf addrconf_dad_work<br /> RIP: 0010:skb_panic+0x15d/0x15f<br /> Code: 92 fe 4c 8b 4c 24 10 53 8b 4d 70 45 89 e0 48 c7 c7 00 ae 79 83<br /> 41 57 41 56 41 55 48 8b 54 24 a6 26 f9 ff 0b 48 8b 6c 24 20 89<br /> 34 24 e8 4a 4e 92 fe 8b 34 24 48 c7 c1 20<br /> RSP: 0018:ffff88810091f820 EFLAGS: 00010282<br /> RAX: 0000000000000089 RBX: ffff8881086e9000 RCX: 0000000000000000<br /> RDX: 0000000000000089 RSI: 0000000000000008 RDI: ffffed1020123efb<br /> RBP: ffff888005f6eac0 R08: ffffed1022fc0031 R09: ffffed1022fc0031<br /> R10: ffff888117e00187 R11: ffffed1022fc0030 R12: 0000000000000028<br /> R13: ffff888008284eb0 R14: 0000000000000ed8 R15: 0000000000000ec0<br /> FS: 0000000000000000(0000) GS:ffff888117c00000(0000)<br /> knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f8b801c5640 CR3: 0000000033c2c006 CR4: 00000000003706f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> ? ip6_mc_hdr.isra.26.constprop.46+0x12a/0x600<br /> ? ip6_mc_hdr.isra.26.constprop.46+0x12a/0x600<br /> skb_put.cold.104+0x22/0x22<br /> ip6_mc_hdr.isra.26.constprop.46+0x12a/0x600<br /> ? rcu_read_lock_sched_held+0x91/0xc0<br /> mld_newpack+0x398/0x8f0<br /> ? ip6_mc_hdr.isra.26.constprop.46+0x600/0x600<br /> ? lock_contended+0xc40/0xc40<br /> add_grhead.isra.33+0x280/0x380<br /> add_grec+0x5ca/0xff0<br /> ? mld_sendpack+0xf40/0xf40<br /> ? lock_downgrade+0x690/0x690<br /> mld_send_initial_cr.part.34+0xb9/0x180<br /> ipv6_mc_dad_complete+0x15d/0x1b0<br /> addrconf_dad_completed+0x8d2/0xbb0<br /> ? lock_downgrade+0x690/0x690<br /> ? addrconf_rs_timer+0x660/0x660<br /> ? addrconf_dad_work+0x73c/0x10e0<br /> addrconf_dad_work+0x73c/0x10e0<br /> <br /> Allowing high order page allocation could fix this problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: fix data stream corruption<br /> <br /> Maxim reported several issues when forcing a TCP transparent proxy<br /> to use the MPTCP protocol for the inbound connections. He also<br /> provided a clean reproducer.<br /> <br /> The problem boils down to &amp;#39;mptcp_frag_can_collapse_to()&amp;#39; assuming<br /> that only MPTCP will use the given page_frag.<br /> <br /> If others - e.g. the plain TCP protocol - allocate page fragments,<br /> we can end-up re-using already allocated memory for mptcp_data_frag.<br /> <br /> Fix the issue ensuring that the to-be-expanded data fragment is<br /> located at the current page frag end.<br /> <br /> v1 -&gt; v2:<br /> - added missing fixes tag (Mat)

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 /> 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 /> 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/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.

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 /> cxgb4: avoid accessing registers when clearing filters<br /> <br /> Hardware register having the server TID base can contain<br /> invalid values when adapter is in bad state (for example,<br /> due to AER fatal error). Reading these invalid values in the<br /> register can lead to out-of-bound memory access. So, fix<br /> by using the saved server TID base when clearing filters.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: lantiq: fix memory corruption in RX ring<br /> <br /> In a situation where memory allocation or dma mapping fails, an<br /> invalid address is programmed into the descriptor. This can lead<br /> to memory corruption. If the memory allocation fails, DMA should<br /> reuse the previous skb and mapping and drop the packet. This patch<br /> also increments rx drop counter.

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.

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