CVSS: 4.4EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47497 – nvmem: Fix shift-out-of-bound (UBSAN) with byte size cells
https://notcve.org/view.php?id=CVE-2021-47497
In the Linux kernel, the following vulnerability has been resolved: nvmem: Fix shift-out-of-bound (UBSAN) with byte size cells If a cell has 'nbits' equal to a multiple of BITS_PER_BYTE the logic *p &= GENMASK((cell->nbits%BITS_PER_BYTE) - 1, 0); will become undefined behavior because nbits modulo BITS_PER_BYTE is 0, and we subtract one from that making a large number that is then shifted more than the number of bits that fit into an unsigned long. UBSAN reports this problem: UBSAN: shift-out-of-bounds in drivers/nvmem/core.c:1386:8 shift exponent 64 is too large for 64-bit type 'unsigned long' CPU: 6 PID: 7 Comm: kworker/u16:0 Not tainted 5.15.0-rc3+ #9 Hardware name: Google Lazor (rev3+) with KB Backlight (DT) Workqueue: events_unbound deferred_probe_work_func Call trace: dump_backtrace+0x0/0x170 show_stack+0x24/0x30 dump_stack_lvl+0x64/0x7c dump_stack+0x18/0x38 ubsan_epilogue+0x10/0x54 __ubsan_handle_shift_out_of_bounds+0x180/0x194 __nvmem_cell_read+0x1ec/0x21c nvmem_cell_read+0x58/0x94 nvmem_cell_read_variable_common+0x4c/0xb0 nvmem_cell_read_variable_le_u32+0x40/0x100 a6xx_gpu_init+0x170/0x2f4 adreno_bind+0x174/0x284 component_bind_all+0xf0/0x264 msm_drm_bind+0x1d8/0x7a0 try_to_bring_up_master+0x164/0x1ac __component_add+0xbc/0x13c component_add+0x20/0x2c dp_display_probe+0x340/0x384 platform_probe+0xc0/0x100 really_probe+0x110/0x304 __driver_probe_device+0xb8/0x120 driver_probe_device+0x4c/0xfc __device_attach_driver+0xb0/0x128 bus_for_each_drv+0x90/0xdc __device_attach+0xc8/0x174 device_initial_probe+0x20/0x2c bus_probe_device+0x40/0xa4 deferred_probe_work_func+0x7c/0xb8 process_one_work+0x128/0x21c process_scheduled_works+0x40/0x54 worker_thread+0x1ec/0x2a8 kthread+0x138/0x158 ret_from_fork+0x10/0x20 Fix it by making sure there are any bits to mask out. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nvmem: corrige el desplazamiento fuera de los límites (UBSAN) con celdas de tamaño de bytes. Si una celda tiene 'nbits' iguales a un múltiplo de BITS_PER_BYTE, la lógica *p &= GENMASK( (celda->nbits%BITS_PER_BYTE) - 1, 0); se convertirá en un comportamiento indefinido porque el módulo de nbits BITS_PER_BYTE es 0, y restamos uno de eso, lo que genera un número grande que luego se desplaza más que el número de bits que caben en un largo sin signo. UBSAN informa este problema: UBSAN: desplazamiento fuera de los límites en drivers/nvmem/core.c:1386:8 el exponente de desplazamiento 64 es demasiado grande para el tipo de 64 bits 'largo sin firmar' CPU: 6 PID: 7 Comm: kworker /u16:0 Not tainted 5.15.0-rc3+ #9 Nombre del hardware: Google Lazor (rev3+) con KB Backlight (DT) Cola de trabajo: events_unbound deferred_probe_work_func Rastreo de llamadas: dump_backtrace+0x0/0x170 show_stack+0x24/0x30 dump_stack_lvl+0x64/0x7c dump_stack +0x18/0x38 ubsan_epilogue+0x10/0x54 __ubsan_handle_shift_out_of_bounds+0x180/0x194 __nvmem_cell_read+0x1ec/0x21c nvmem_cell_read+0x58/0x94 nvmem_cell_read_variable_common+0x4c/0xb0 mem_cell_read_variable_le_u32+0x40/0x100 a6xx_gpu_init+0x170/0x2f4 adreno_bind+0x174/0x284 componente_bind_all+0xf0/0x264 msm_drm_bind +0x1d8/0x7a0 try_to_bring_up_master+0x164/0x1ac __component_add+0xbc/0x13c componente_add+0x20/0x2c dp_display_probe+0x340/0x384 platform_probe+0xc0/0x100 very_probe+0x110/0x304 _device+0xb8/0x120 driver_probe_device+0x4c/0xfc __device_attach_driver+0xb0/0x128 bus_for_each_drv +0x90/0xdc __device_attach+0xc8/0x174 dispositivo_inicial_probe+0x20/0x2c bus_probe_device+0x40/0xa4 diferido_probe_work_func+0x7c/0xb8 proceso_one_work+0x128/0x21c proceso_scheduled_works+0x40/0x54 trabajador_hilo+0 x1ec/0x2a8 kthread+0x138/0x158 ret_from_fork+0x10/0x20 Arreglar asegurándose de que haya partes que enmascarar. • https://git.kernel.org/stable/c/69aba7948cbe53f2f1827e84e9dd0ae470a5072e https://git.kernel.org/stable/c/abcb8d33e4d2215ccde5ab5ccf9f730a59d79d97 https://git.kernel.org/stable/c/60df06bbdf497e37ed25ad40572c362e5b0998df https://git.kernel.org/stable/c/2df6c023050205c4d04ffc121bc549f65cb8d1df https://git.kernel.org/stable/c/eb0fc8e7170e61eaf65d28dee4a8baf4e86b19ca https://git.kernel.org/stable/c/0594f1d048d8dc338eb9a240021b1d00ae1eb082 https://git.kernel.org/stable/c/57e48886401b14cd351423fabfec2cfd18df4f66 https://git.kernel.org/stable/c/0e822e5413da1af28cca350cb1cb42b61 • CWE-125: Out-of-bounds Read •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47496 – net/tls: Fix flipped sign in tls_err_abort() calls
https://notcve.org/view.php?id=CVE-2021-47496
In the Linux kernel, the following vulnerability has been resolved: net/tls: Fix flipped sign in tls_err_abort() calls sk->sk_err appears to expect a positive value, a convention that ktls doesn't always follow and that leads to memory corruption in other code. For instance, [kworker] tls_encrypt_done(..., err=<negative error from crypto request>) tls_err_abort(.., err) sk->sk_err = err; [task] splice_from_pipe_feed ... tls_sw_do_sendpage if (sk->sk_err) { ret = -sk->sk_err; // ret is positive splice_from_pipe_feed (continued) ret = actor(...) // ret is still positive and interpreted as bytes // written, resulting in underflow of buf->len and // sd->len, leading to huge buf->offset and bogus // addresses computed in later calls to actor() Fix all tls_err_abort() callers to pass a negative error code consistently and centralize the error-prone sign flip there, throwing in a warning to catch future misuse and uninlining the function so it really does only warn once. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/tls: corrige las llamadas invertidas de tls_err_abort() sk->sk_err parece esperar un valor positivo, una convención que ktls no siempre sigue y que conduce a daños en la memoria en otro código. Por ejemplo, [kworker] tls_encrypt_done(..., err=) tls_err_abort(.., err) sk->sk_err = err; [tarea] splice_from_pipe_feed ... tls_sw_do_sendpage if (sk->sk_err) { ret = -sk->sk_err; // ret es positivo splice_from_pipe_feed (continuación) ret = actor(...) // ret sigue siendo positivo y se interpreta como bytes // escritos, lo que resulta en un desbordamiento insuficiente de buf->len y // sd->len, lo que genera enormes buf->offset y bogus // direcciones calculadas en llamadas posteriores a actor(). Repare todas las llamadas tls_err_abort() para que pasen un código de error negativo de manera consistente y centralice el cambio de señal propenso a errores allí, lanzando una advertencia para detectar futuros usos indebidos y eliminación de líneas. la función por lo que realmente solo advierte una vez. • https://git.kernel.org/stable/c/c46234ebb4d1eee5e09819f49169e51cfc6eb909 https://git.kernel.org/stable/c/e0cfd5159f314d6b304d030363650b06a2299cbb https://git.kernel.org/stable/c/f3dec7e7ace38224f82cf83f0049159d067c2e19 https://git.kernel.org/stable/c/e41473543f75f7dbc5d605007e6f883f1bd13b9a https://git.kernel.org/stable/c/da353fac65fede6b8b4cfe207f0d9408e3121105 •
CVSS: 4.4EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47495 – usbnet: sanity check for maxpacket
https://notcve.org/view.php?id=CVE-2021-47495
In the Linux kernel, the following vulnerability has been resolved: usbnet: sanity check for maxpacket maxpacket of 0 makes no sense and oopses as we need to divide by it. Give up. V2: fixed typo in log and stylistic issues En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usbnet: verificación de cordura para maxpacket maxpacket de 0 no tiene sentido y falla ya que necesitamos dividirlo por él. Abandonar. V2: error tipográfico corregido en el registro y problemas de estilo • https://git.kernel.org/stable/c/b9eba0a4a527e04d712f0e0401e5391ef124b33e https://git.kernel.org/stable/c/524f333e98138d909a0a0c574a9ff6737dce2767 https://git.kernel.org/stable/c/74b3b27cf9fecce00cd8918b7882fd81191d0aa4 https://git.kernel.org/stable/c/002d82227c0abe29118cf80f7e2f396b22d448ed https://git.kernel.org/stable/c/492140e45d2bf27c1014243f8616a9b612144e20 https://git.kernel.org/stable/c/693ecbe8f799405f8775719deedb1f76265d375a https://git.kernel.org/stable/c/7e8b6a4f18edee070213cb6a77118e8a412253c5 https://git.kernel.org/stable/c/397430b50a363d8b7bdda00522123f82d • CWE-369: Divide By Zero •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47494 – cfg80211: fix management registrations locking
https://notcve.org/view.php?id=CVE-2021-47494
In the Linux kernel, the following vulnerability has been resolved: cfg80211: fix management registrations locking The management registrations locking was broken, the list was locked for each wdev, but cfg80211_mgmt_registrations_update() iterated it without holding all the correct spinlocks, causing list corruption. Rather than trying to fix it with fine-grained locking, just move the lock to the wiphy/rdev (still need the list on each wdev), we already need to hold the wdev lock to change it, so there's no contention on the lock in any case. This trivially fixes the bug since we hold one wdev's lock already, and now will hold the lock that protects all lists. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: cfg80211: corrige el bloqueo de registros de administración. El bloqueo de registros de administración estaba roto, la lista estaba bloqueada para cada wdev, pero cfg80211_mgmt_registrations_update() la repitió sin mantener todos los spinlocks correctos, lo que provocó corrupción en la lista. En lugar de intentar solucionarlo con un bloqueo detallado, simplemente mueva el bloqueo a wiphy/rdev (aún necesitamos la lista en cada wdev), ya necesitamos mantener presionado el bloqueo wdev para cambiarlo, por lo que no hay contención en el bloqueo. • https://git.kernel.org/stable/c/6cd536fe62ef58d7c4eac2da07ab0ed7fd19010d https://git.kernel.org/stable/c/4c22227e39c7a0b4dab55617ee8d34d171fab8d4 https://git.kernel.org/stable/c/3c897f39b71fe68f90599f6a45b5f7bf5618420e https://git.kernel.org/stable/c/09b1d5dc6ce1c9151777f6c4e128a59457704c97 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47493 – ocfs2: fix race between searching chunks and release journal_head from buffer_head
https://notcve.org/view.php?id=CVE-2021-47493
In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix race between searching chunks and release journal_head from buffer_head Encountered a race between ocfs2_test_bg_bit_allocatable() and jbd2_journal_put_journal_head() resulting in the below vmcore. PID: 106879 TASK: ffff880244ba9c00 CPU: 2 COMMAND: "loop3" Call trace: panic oops_end no_context __bad_area_nosemaphore bad_area_nosemaphore __do_page_fault do_page_fault page_fault [exception RIP: ocfs2_block_group_find_clear_bits+316] ocfs2_block_group_find_clear_bits [ocfs2] ocfs2_cluster_group_search [ocfs2] ocfs2_search_chain [ocfs2] ocfs2_claim_suballoc_bits [ocfs2] __ocfs2_claim_clusters [ocfs2] ocfs2_claim_clusters [ocfs2] ocfs2_local_alloc_slide_window [ocfs2] ocfs2_reserve_local_alloc_bits [ocfs2] ocfs2_reserve_clusters_with_limit [ocfs2] ocfs2_reserve_clusters [ocfs2] ocfs2_lock_refcount_allocators [ocfs2] ocfs2_make_clusters_writable [ocfs2] ocfs2_replace_cow [ocfs2] ocfs2_refcount_cow [ocfs2] ocfs2_file_write_iter [ocfs2] lo_rw_aio loop_queue_work kthread_worker_fn kthread ret_from_fork When ocfs2_test_bg_bit_allocatable() called bh2jh(bg_bh), the bg_bh->b_private NULL as jbd2_journal_put_journal_head() raced and released the jounal head from the buffer head. Needed to take bit lock for the bit 'BH_JournalHead' to fix this race. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ocfs2: corrige la ejecución entre fragmentos de búsqueda y libera journal_head de buffer_head Se encontró una ejecución entre ocfs2_test_bg_bit_allocatable() y jbd2_journal_put_journal_head() que resultó en el siguiente vmcore. PID: 106879 TAREA: ffff880244ba9c00 CPU: 2 COMANDO: "loop3" Rastreo de llamadas: pánico oops_end no_context __bad_area_nosemaphore bad_area_nosemaphore __do_page_fault do_page_fault page_fault [excepción RIP: ocfs2_block_group_find_clear_bits+316] 2_block_group_find_clear_bits [ocfs2] ocfs2_cluster_group_search [ocfs2] ocfs2_search_chain [ocfs2] ocfs2_claim_suballoc_bits [ocfs2] __ocfs2_claim_clusters [ocfs2] ocfs2_claim_clusters [ocfs2] ocfs2_local_alloc_slide_window [ocfs2] ocfs2_reserve_local_alloc_bits [ocfs2] ocfs2_reserve_clusters_with_limit [ocfs2] ocfs2_reserve_clusters [ocfs2] ocfs2_lock_refcount_allocators [ocfs2] 2_make_clusters_writable [ocfs2] ocfs2_replace_cow [ocfs2] ocfs2_refcount_cow [ocfs2] ocfs2_file_write_iter [ocfs2] lo_rw_aio loop_queue_work kthread_worker_fn kthread ret_from_fork Cuando ocfs2_test_bg_bit_allocatable () llamado bh2jh(bg_bh), el bg_bh->b_private NULL como jbd2_journal_put_journal_head() corrió y liberó el encabezado del diario del encabezado del búfer. Era necesario bloquear el bit 'BH_JournalHead' para solucionar esta ejecución. • https://git.kernel.org/stable/c/5043fbd294f5909a080ade0f04b70a4da9e122b7 https://git.kernel.org/stable/c/2e382600e8856ea654677b5134ee66e03ea72bc2 https://git.kernel.org/stable/c/6f1b228529ae49b0f85ab89bcdb6c365df401558 •