CVE-2021-47068 – net/nfc: fix use-after-free llcp_sock_bind/connect
https://notcve.org/view.php?id=CVE-2021-47068
In the Linux kernel, the following vulnerability has been resolved: net/nfc: fix use-after-free llcp_sock_bind/connect Commits 8a4cd82d ("nfc: fix refcount leak in llcp_sock_connect()") and c33b1cc62 ("nfc: fix refcount leak in llcp_sock_bind()") fixed a refcount leak bug in bind/connect but introduced a use-after-free if the same local is assigned to 2 different sockets. This can be triggered by the following simple program: int sock1 = socket( AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP ); int sock2 = socket( AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP ); memset( &addr, 0, sizeof(struct sockaddr_nfc_llcp) ); addr.sa_family = AF_NFC; addr.nfc_protocol = NFC_PROTO_NFC_DEP; bind( sock1, (struct sockaddr*) &addr, sizeof(struct sockaddr_nfc_llcp) ) bind( sock2, (struct sockaddr*) &addr, sizeof(struct sockaddr_nfc_llcp) ) close(sock1); close(sock2); Fix this by assigning NULL to llcp_sock->local after calling nfc_llcp_local_put. This addresses CVE-2021-23134. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/nfc: corrige use-after-free llcp_sock_bind/connect Commits 8a4cd82d ("nfc: corrige la fuga de refcount en llcp_sock_connect()") y c33b1cc62 ("nfc: corrige la fuga de refcount en llcp_sock_bind()") corrigió un error de fuga de recuento en bind/connect pero introdujo un Use-After-Free si el mismo local está asignado a 2 sockets diferentes. Esto puede activarse mediante el siguiente programa simple: int sock1 = socket( AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP ); int sock2 = conector (AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP); memset( &addr, 0, sizeof(struct sockaddr_nfc_llcp) ); addr.sa_family = AF_NFC; addr.nfc_protocol = NFC_PROTO_NFC_DEP; bind( sock1, (struct sockaddr*) & addr, sizeof(struct sockaddr_nfc_llcp) ) bind( sock2, (struct sockaddr*) & addr, sizeof(struct sockaddr_nfc_llcp) ) close(sock1); cerrar(calcetín2); Solucione este problema asignando NULL a llcp_sock->local después de llamar a nfc_llcp_local_put. Esto aborda CVE-2021-23134. • https://git.kernel.org/stable/c/a1cdd18c49d23ec38097ac2c5b0d761146fc0109 https://git.kernel.org/stable/c/18013007b596771bf5f5e7feee9586fb0386ad14 https://git.kernel.org/stable/c/538a6ff11516d38a61e237d2d2dc04c30c845fbe https://git.kernel.org/stable/c/adbb1d218c5f56dbae052765da83c0f57fce2a31 https://git.kernel.org/stable/c/c89903c9eff219a4695e63715cf922748d743f65 https://git.kernel.org/stable/c/6fb003e5ae18d8cda4c8a1175d9dd8db12bec049 https://git.kernel.org/stable/c/8c9e4971e142e2899606a2490b77a1208c1f4638 https://git.kernel.org/stable/c/c33b1cc62ac05c1dbb1cdafe2eb66da01 •
CVE-2021-47067 – soc/tegra: regulators: Fix locking up when voltage-spread is out of range
https://notcve.org/view.php?id=CVE-2021-47067
In the Linux kernel, the following vulnerability has been resolved: soc/tegra: regulators: Fix locking up when voltage-spread is out of range Fix voltage coupler lockup which happens when voltage-spread is out of range due to a bug in the code. The max-spread requirement shall be accounted when CPU regulator doesn't have consumers. This problem is observed on Tegra30 Ouya game console once system-wide DVFS is enabled in a device-tree. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: soc/tegra: regulators: se corrigió el bloqueo cuando la dispersión de voltaje está fuera de rango. Se corrigió el bloqueo del acoplador de voltaje que ocurre cuando la dispersión de voltaje está fuera de rango debido a un error en el código. . • https://git.kernel.org/stable/c/783807436f363e5b1ad4d43ba7debbedfcadbb99 https://git.kernel.org/stable/c/a1ad124c836816fac8bd5e461d36eaf33cee4e24 https://git.kernel.org/stable/c/dc4452867200fa94589b382740952b58aa1c3e6c https://git.kernel.org/stable/c/ff39adf5d31c72025bba799aec69c5c86d81d549 https://git.kernel.org/stable/c/ef85bb582c41524e9e68dfdbde48e519dac4ab3d •
CVE-2021-47066 – async_xor: increase src_offs when dropping destination page
https://notcve.org/view.php?id=CVE-2021-47066
In the Linux kernel, the following vulnerability has been resolved: async_xor: increase src_offs when dropping destination page Now we support sharing one page if PAGE_SIZE is not equal stripe size. To support this, it needs to support calculating xor value with different offsets for each r5dev. One offset array is used to record those offsets. In RMW mode, parity page is used as a source page. It sets ASYNC_TX_XOR_DROP_DST before calculating xor value in ops_run_prexor5. So it needs to add src_list and src_offs at the same time. Now it only needs src_list. • https://git.kernel.org/stable/c/29bcff787a2593b2126cfaff612c0b4e560022e9 https://git.kernel.org/stable/c/cab2e8e5997b592fdb7d02cf2387b4b8e3057174 https://git.kernel.org/stable/c/29ffa50f33de824b5491f8239c88c4a0efdd03af https://git.kernel.org/stable/c/53f8208e11abd6dde9480dfcb97fecdb1bc2ac18 https://git.kernel.org/stable/c/ceaf2966ab082bbc4d26516f97b3ca8a676e2af8 •
CVE-2021-47065 – rtw88: Fix array overrun in rtw_get_tx_power_params()
https://notcve.org/view.php?id=CVE-2021-47065
In the Linux kernel, the following vulnerability has been resolved: rtw88: Fix array overrun in rtw_get_tx_power_params() Using a kernel with the Undefined Behaviour Sanity Checker (UBSAN) enabled, the following array overrun is logged: ================================================================================ UBSAN: array-index-out-of-bounds in /home/finger/wireless-drivers-next/drivers/net/wireless/realtek/rtw88/phy.c:1789:34 index 5 is out of range for type 'u8 [5]' CPU: 2 PID: 84 Comm: kworker/u16:3 Tainted: G O 5.12.0-rc5-00086-gd88bba47038e-dirty #651 Hardware name: TOSHIBA TECRA A50-A/TECRA A50-A, BIOS Version 4.50 09/29/2014 Workqueue: phy0 ieee80211_scan_work [mac80211] Call Trace: dump_stack+0x64/0x7c ubsan_epilogue+0x5/0x40 __ubsan_handle_out_of_bounds.cold+0x43/0x48 rtw_get_tx_power_params+0x83a/drivers/net/wireless/realtek/rtw88/0xad0 [rtw_core] ? rtw_pci_read16+0x20/0x20 [rtw_pci] ? check_hw_ready+0x50/0x90 [rtw_core] rtw_phy_get_tx_power_index+0x4d/0xd0 [rtw_core] rtw_phy_set_tx_power_level+0xee/0x1b0 [rtw_core] rtw_set_channel+0xab/0x110 [rtw_core] rtw_ops_config+0x87/0xc0 [rtw_core] ieee80211_hw_config+0x9d/0x130 [mac80211] ieee80211_scan_state_set_channel+0x81/0x170 [mac80211] ieee80211_scan_work+0x19f/0x2a0 [mac80211] process_one_work+0x1dd/0x3a0 worker_thread+0x49/0x330 ? rescuer_thread+0x3a0/0x3a0 kthread+0x134/0x150 ? kthread_create_worker_on_cpu+0x70/0x70 ret_from_fork+0x22/0x30 ================================================================================ The statement where an array is being overrun is shown in the following snippet: if (rate <= DESC_RATE11M) tx_power = pwr_idx_2g->cck_base[group]; else ====> tx_power = pwr_idx_2g->bw40_base[group]; The associated arrays are defined in main.h as follows: struct rtw_2g_txpwr_idx { u8 cck_base[6]; u8 bw40_base[5]; struct rtw_2g_1s_pwr_idx_diff ht_1s_diff; struct rtw_2g_ns_pwr_idx_diff ht_2s_diff; struct rtw_2g_ns_pwr_idx_diff ht_3s_diff; struct rtw_2g_ns_pwr_idx_diff ht_4s_diff; }; The problem arises because the value of group is 5 for channel 14. • https://git.kernel.org/stable/c/fa6dfe6bff246ddd5be3cfe81637f137acd6c294 https://git.kernel.org/stable/c/6b5aa0cf321c25f41e09a61c83ee4dc7ab9549cb https://git.kernel.org/stable/c/95fb153c6027924cda3422120169d1890737f3a0 https://git.kernel.org/stable/c/5f3dbced8eaa5c9ed7d6943f3fea99f235a6516a https://git.kernel.org/stable/c/9cd09722e18a08b6a3d68b8bccfac39ddc22434c https://git.kernel.org/stable/c/2ff25985ea9ccc6c9af2c77b0b49045adcc62e0e •
CVE-2021-47064 – mt76: fix potential DMA mapping leak
https://notcve.org/view.php?id=CVE-2021-47064
In the Linux kernel, the following vulnerability has been resolved: mt76: fix potential DMA mapping leak With buf uninitialized in mt76_dma_tx_queue_skb_raw, its field skip_unmap could potentially inherit a non-zero value from stack garbage. If this happens, it will cause DMA mappings for MCU command frames to not be unmapped after completion En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mt76: corrige una posible fuga de mapeo DMA Con buf no inicializado en mt76_dma_tx_queue_skb_raw, su campo skip_unmap podría potencialmente heredar un valor distinto de cero de la basura de la pila. Si esto sucede, las asignaciones DMA para las tramas de comando MCU no se desasignarán una vez finalizadas. • https://git.kernel.org/stable/c/27d5c528a7ca08dcd44877fdd9fc08b76630bf77 https://git.kernel.org/stable/c/9fa26701cd1fc4d932d431971efc5746325bdfce https://git.kernel.org/stable/c/9b68ce2856dadc0e1cb6fd21fbeb850da49efd08 https://git.kernel.org/stable/c/91b9548d413fda488ea853cd1b9f59b572db3a0c https://git.kernel.org/stable/c/b4403cee6400c5f679e9c4a82b91d61aa961eccf •