CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47141 – gve: Add NULL pointer checks when freeing irqs.
https://notcve.org/view.php?id=CVE-2021-47141
In the Linux kernel, the following vulnerability has been resolved: gve: Add NULL pointer checks when freeing irqs. When freeing notification blocks, we index priv->msix_vectors. If we failed to allocate priv->msix_vectors (see abort_with_msix_vectors) this could lead to a NULL pointer dereference if the driver is unloaded. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gve: agrega comprobaciones de puntero NULL al liberar irqs. Al liberar bloques de notificaciones, indexamos priv->msix_vectors. Si no pudimos asignar priv->msix_vectors (consulte abort_with_msix_vectors), esto podría provocar una desreferencia del puntero NULL si el controlador está descargado. • https://git.kernel.org/stable/c/893ce44df56580fb878ca5af9c4a5fd87567da50 https://git.kernel.org/stable/c/821149ee88c206fa37e79c1868cc270518484876 https://git.kernel.org/stable/c/da21a35c00ff1a1794d4f166d3b3fa8db4d0f6fb https://git.kernel.org/stable/c/5278c75266c5094d3c0958793bf12fc90300e580 https://git.kernel.org/stable/c/5218e919c8d06279884aa0baf76778a6817d5b93 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47139 – net: hns3: put off calling register_netdev() until client initialize complete
https://notcve.org/view.php?id=CVE-2021-47139
In the Linux kernel, the following vulnerability has been resolved: net: hns3: put off calling register_netdev() until client initialize complete Currently, the netdevice is registered before client initializing complete. So there is a timewindow between netdevice available and usable. In this case, if user try to change the channel number or ring param, it may cause the hns3_set_rx_cpu_rmap() being called twice, and report bug. [47199.416502] hns3 0000:35:00.0 eth1: set channels: tqp_num=1, rxfh=0 [47199.430340] hns3 0000:35:00.0 eth1: already uninitialized [47199.438554] hns3 0000:35:00.0: rss changes from 4 to 1 [47199.511854] hns3 0000:35:00.0: Channels changed, rss_size from 4 to 1, tqps from 4 to 1 [47200.163524] ------------[ cut here ]------------ [47200.171674] kernel BUG at lib/cpu_rmap.c:142! [47200.177847] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [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] [47200.205912] CPU: 1 PID: 8260 Comm: ethtool Tainted: G O 5.11.0-rc3+ #1 [47200.215601] Hardware name: , xxxxxx 02/04/2021 [47200.223052] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--) [47200.230188] pc : cpu_rmap_add+0x38/0x40 [47200.237472] lr : irq_cpu_rmap_add+0x84/0x140 [47200.243291] sp : ffff800010e93a30 [47200.247295] x29: ffff800010e93a30 x28: ffff082100584880 [47200.254155] x27: 0000000000000000 x26: 0000000000000000 [47200.260712] x25: 0000000000000000 x24: 0000000000000004 [47200.267241] x23: ffff08209ba03000 x22: ffff08209ba038c0 [47200.273789] x21: 000000000000003f x20: ffff0820e2bc1680 [47200.280400] x19: ffff0820c970ec80 x18: 00000000000000c0 [47200.286944] x17: 0000000000000000 x16: ffffb43debe4a0d0 [47200.293456] x15: fffffc2082990600 x14: dead000000000122 [47200.300059] x13: ffffffffffffffff x12: 000000000000003e [47200.306606] x11: ffff0820815b8080 x10: ffff53e411988000 [47200.313171] x9 : 0000000000000000 x8 : ffff0820e2bc1700 [47200.319682] x7 : 0000000000000000 x6 : 000000000000003f [47200.326170] x5 : 0000000000000040 x4 : ffff800010e93a20 [47200.332656] x3 : 0000000000000004 x2 : ffff0820c970ec80 [47200.339168] x1 : ffff0820e2bc1680 x0 : 0000000000000004 [47200.346058] Call trace: [47200.349324] cpu_rmap_add+0x38/0x40 [47200.354300] hns3_set_rx_cpu_rmap+0x6c/0xe0 [hns3] [47200.362294] hns3_reset_notify_init_enet+0x1cc/0x340 [hns3] [47200.370049] hns3_change_channels+0x40/0xb0 [hns3] [47200.376770] hns3_set_channels+0x12c/0x2a0 [hns3] [47200.383353] ethtool_set_channels+0x140/0x250 [47200.389772] dev_ethtool+0x714/0x23d0 [47200.394440] dev_ioctl+0x4cc/0x640 [47200.399277] sock_do_ioctl+0x100/0x2a0 [47200.404574] sock_ioctl+0x28c/0x470 [47200.409079] __arm64_sys_ioctl+0xb4/0x100 [47200.415217] el0_svc_common.constprop.0+0x84/0x210 [47200.422088] do_el0_svc+0x28/0x34 [47200.426387] el0_svc+0x28/0x70 [47200.431308] el0_sync_handler+0x1a4/0x1b0 [47200.436477] el0_sync+0x174/0x180 [47200.441562] Code: 11000405 79000c45 f8247861 d65f03c0 (d4210000) [47200.448869] ---[ end trace a01efe4ce42e5f34 ]--- The process is like below: excuting hns3_client_init | register_netdev() | hns3_set_channels() | | hns3_set_rx_cpu_rmap() hns3_reset_notify_uninit_enet() | | | quit without calling function | hns3_free_rx_cpu_rmap for flag | HNS3_NIC_STATE_INITED is unset. | | | hns3_reset_notify_init_enet() | | set HNS3_NIC_STATE_INITED call hns3_set_rx_cpu_rmap()-- crash Fix it by calling register_netdev() at the end of function hns3_client_init(). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: hns3: posponga la llamada a Register_netdev() hasta que se complete la inicialización del cliente. • https://git.kernel.org/stable/c/08a100689d4baf296d6898c687ea8d005da8d234 https://git.kernel.org/stable/c/a663c1e418a3b5b8e8edfad4bc8e7278c312d6fc https://git.kernel.org/stable/c/0921a0620b5077796fddffb22a8e6bc635a4bb50 https://git.kernel.org/stable/c/a289a7e5c1d49b7d47df9913c1cc81fb48fab613 •
CVSS: 6.0EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47138 – cxgb4: avoid accessing registers when clearing filters
https://notcve.org/view.php?id=CVE-2021-47138
In the Linux kernel, the following vulnerability has been resolved: cxgb4: avoid accessing registers when clearing filters Hardware register having the server TID base can contain invalid values when adapter is in bad state (for example, due to AER fatal error). Reading these invalid values in the register can lead to out-of-bound memory access. So, fix by using the saved server TID base when clearing filters. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cxgb4: evita acceder a los registros al borrar los filtros El registro de hardware que tiene la base TID del servidor puede contener valores no válidos cuando el adaptador está en mal estado (por ejemplo, debido a un error fatal de AER). Leer estos valores no válidos en el registro puede provocar un acceso a la memoria fuera de límites. • https://git.kernel.org/stable/c/b1a79360ee862f8ada4798ad2346fa45bb41b527 https://git.kernel.org/stable/c/0bf49b3c8d8b3a43ce09f1b2db70e5484d31fcdf https://git.kernel.org/stable/c/02f03883fdb10ad7e66717c70ea163a8d27ae6e7 https://git.kernel.org/stable/c/285207a558ab456aa7d8aa877ecc7e91fcc51710 https://git.kernel.org/stable/c/88c380df84fbd03f9b137c2b9d0a44b9f2f553b0 https://access.redhat.com/security/cve/CVE-2021-47138 https://bugzilla.redhat.com/show_bug.cgi?id=2271484 • CWE-125: Out-of-bounds Read •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47137 – net: lantiq: fix memory corruption in RX ring
https://notcve.org/view.php?id=CVE-2021-47137
In the Linux kernel, the following vulnerability has been resolved: net: lantiq: fix memory corruption in RX ring In a situation where memory allocation or dma mapping fails, an invalid address is programmed into the descriptor. This can lead to memory corruption. If the memory allocation fails, DMA should reuse the previous skb and mapping and drop the packet. This patch also increments rx drop counter. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: lantiq: corrige la corrupción de la memoria en el anillo RX En una situación en la que falla la asignación de memoria o el mapeo dma, se programa una dirección no válida en el descriptor. • https://git.kernel.org/stable/c/fe1a56420cf2ec28c8eceef672b87de0bbe1a260 https://git.kernel.org/stable/c/8bb1077448d43a871ed667520763e3b9f9b7975d https://git.kernel.org/stable/c/5ac72351655f8b033a2935646f53b7465c903418 https://git.kernel.org/stable/c/46dd4abced3cb2c912916f4a5353e0927db0c4a2 https://git.kernel.org/stable/c/c7718ee96dbc2f9c5fc3b578abdf296dd44b9c20 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47136 – net: zero-initialize tc skb extension on allocation
https://notcve.org/view.php?id=CVE-2021-47136
In the Linux kernel, the following vulnerability has been resolved: net: zero-initialize tc skb extension on allocation Function skb_ext_add() doesn't initialize created skb extension with any value and leaves it up to the user. However, since extension of type TC_SKB_EXT originally contained only single value tc_skb_ext->chain its users used to just assign the chain value without setting whole extension memory to zero first. This assumption changed when TC_SKB_EXT extension was extended with additional fields but not all users were updated to initialize the new fields which leads to use of uninitialized memory afterwards. UBSAN log: [ 778.299821] UBSAN: invalid-load in net/openvswitch/flow.c:899:28 [ 778.301495] load of value 107 is not a valid value for type '_Bool' [ 778.303215] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.12.0-rc7+ #2 [ 778.304933] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 778.307901] Call Trace: [ 778.308680] <IRQ> [ 778.309358] dump_stack+0xbb/0x107 [ 778.310307] ubsan_epilogue+0x5/0x40 [ 778.311167] __ubsan_handle_load_invalid_value.cold+0x43/0x48 [ 778.312454] ? memset+0x20/0x40 [ 778.313230] ovs_flow_key_extract.cold+0xf/0x14 [openvswitch] [ 778.314532] ovs_vport_receive+0x19e/0x2e0 [openvswitch] [ 778.315749] ? • https://git.kernel.org/stable/c/038ebb1a713d114d54dbf14868a73181c0c92758 https://git.kernel.org/stable/c/7154bda4cfc1f41b339121475d2b0234141f3492 https://git.kernel.org/stable/c/ac493452e937b8939eaf2d24cac51a4804b6c20e https://git.kernel.org/stable/c/86ab133b695ed7ba1f8786b12f4ca43137ad8c18 https://git.kernel.org/stable/c/9453d45ecb6c2199d72e73c993e9d98677a2801b •