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: 7.8EPSS: 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 • CWE-770: Allocation of Resources Without Limits or Throttling •
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 •
CVSS: 4.7EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26643 – netfilter: nf_tables: mark set as dead when unbinding anonymous set with timeout
https://notcve.org/view.php?id=CVE-2024-26643
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: mark set as dead when unbinding anonymous set with timeout While the rhashtable set gc runs asynchronously, a race allows it to collect elements from anonymous sets with timeouts while it is being released from the commit path. Mingi Cho originally reported this issue in a different path in 6.1.x with a pipapo set with low timeouts which is not possible upstream since 7395dfacfff6 ("netfilter: nf_tables: use timestamp to check for set element timeout"). Fix this by setting on the dead flag for anonymous sets to skip async gc in this case. According to 08e4c8c5919f ("netfilter: nf_tables: mark newset as dead on transaction abort"), Florian plans to accelerate abort path by releasing objects via workqueue, therefore, this sets on the dead flag for abort path too. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: marca el conjunto como muerto al desvincular el conjunto anónimo con tiempo de espera. Mientras que el conjunto rhashtable gc se ejecuta de forma asíncrona, una ejecución le permite recopilar elementos de conjuntos anónimos con tiempos de espera mientras se libera de la ruta de confirmación. Mingi Cho informó originalmente este problema en una ruta diferente en 6.1.x con un pipapo configurado con tiempos de espera bajos, lo cual no es posible en sentido ascendente desde 7395dfacfff6 ("netfilter: nf_tables: use la marca de tiempo para verificar el tiempo de espera del elemento establecido"). Solucione este problema configurando la bandera muerta para que los conjuntos anónimos omitan el gc asíncrono en este caso. • https://git.kernel.org/stable/c/bbdb3b65aa91aa0a32b212f27780b28987f2d94f https://git.kernel.org/stable/c/448be0774882f95a74fa5eb7519761152add601b https://git.kernel.org/stable/c/d19e8bf3ea4114dd21fc35da21f398203d7f7df1 https://git.kernel.org/stable/c/ea3eb9f2192e4fc33b795673e56c97a21987f868 https://git.kernel.org/stable/c/5f68718b34a531a556f2f50300ead2862278da26 https://git.kernel.org/stable/c/0624f190b5742a1527cd938295caa8dc5281d4cd https://git.kernel.org/stable/c/edcf1a3f182ecf8b6b805f0ce90570ea98c5f6bf https://git.kernel.org/stable/c/e2d45f467096e931044f0ab7634499879 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •