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-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 •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47492 – mm, thp: bail out early in collapse_file for writeback page
https://notcve.org/view.php?id=CVE-2021-47492
In the Linux kernel, the following vulnerability has been resolved: mm, thp: bail out early in collapse_file for writeback page Currently collapse_file does not explicitly check PG_writeback, instead, page_has_private and try_to_release_page are used to filter writeback pages. This does not work for xfs with blocksize equal to or larger than pagesize, because in such case xfs has no page->private. This makes collapse_file bail out early for writeback page. Otherwise, xfs end_page_writeback will panic as follows. page:fffffe00201bcc80 refcount:0 mapcount:0 mapping:ffff0003f88c86a8 index:0x0 pfn:0x84ef32 aops:xfs_address_space_operations [xfs] ino:30000b7 dentry name:"libtest.so" flags: 0x57fffe0000008027(locked|referenced|uptodate|active|writeback) raw: 57fffe0000008027 ffff80001b48bc28 ffff80001b48bc28 ffff0003f88c86a8 raw: 0000000000000000 0000000000000000 00000000ffffffff ffff0000c3e9a000 page dumped because: VM_BUG_ON_PAGE(((unsigned int) page_ref_count(page) + 127u <= 127u)) page->mem_cgroup:ffff0000c3e9a000 ------------[ cut here ]------------ kernel BUG at include/linux/mm.h:1212! Internal error: Oops - BUG: 0 [#1] SMP Modules linked in: BUG: Bad page state in process khugepaged pfn:84ef32 xfs(E) page:fffffe00201bcc80 refcount:0 mapcount:0 mapping:0 index:0x0 pfn:0x84ef32 libcrc32c(E) rfkill(E) aes_ce_blk(E) crypto_simd(E) ... CPU: 25 PID: 0 Comm: swapper/25 Kdump: loaded Tainted: ... pstate: 60400005 (nZCv daif +PAN -UAO -TCO BTYPE=--) Call trace: end_page_writeback+0x1c0/0x214 iomap_finish_page_writeback+0x13c/0x204 iomap_finish_ioend+0xe8/0x19c iomap_writepage_end_bio+0x38/0x50 bio_endio+0x168/0x1ec blk_update_request+0x278/0x3f0 blk_mq_end_request+0x34/0x15c virtblk_request_done+0x38/0x74 [virtio_blk] blk_done_softirq+0xc4/0x110 __do_softirq+0x128/0x38c __irq_exit_rcu+0x118/0x150 irq_exit+0x1c/0x30 __handle_domain_irq+0x8c/0xf0 gic_handle_irq+0x84/0x108 el1_irq+0xcc/0x180 arch_cpu_idle+0x18/0x40 default_idle_call+0x4c/0x1a0 cpuidle_idle_call+0x168/0x1e0 do_idle+0xb4/0x104 cpu_startup_entry+0x30/0x9c secondary_start_kernel+0x104/0x180 Code: d4210000 b0006161 910c8021 94013f4d (d4210000) ---[ end trace 4a88c6a074082f8c ]--- Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm, thp: rescatar temprano en el colapso_archivo para la página de reescritura. Actualmente, colapso_archivo no verifica explícitamente PG_writeback; en su lugar, page_has_private y try_to_release_page se utilizan para filtrar las páginas de reescritura. • https://git.kernel.org/stable/c/99cb0dbd47a15d395bf3faa78dc122bc5efe3fc0 https://git.kernel.org/stable/c/69a7fa5cb0de06c8956b040f19a7248c8c8308ca https://git.kernel.org/stable/c/5e669d8ab30ab61dec3c36e27b4711f07611e6fc https://git.kernel.org/stable/c/74c42e1baacf206338b1dd6b6199ac964512b5bb https://access.redhat.com/security/cve/CVE-2021-47492 https://bugzilla.redhat.com/show_bug.cgi?id=2282924 • CWE-372: Incomplete Internal State Distinction •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47491 – mm: khugepaged: skip huge page collapse for special files
https://notcve.org/view.php?id=CVE-2021-47491
In the Linux kernel, the following vulnerability has been resolved: mm: khugepaged: skip huge page collapse for special files The read-only THP for filesystems will collapse THP for files opened readonly and mapped with VM_EXEC. The intended usecase is to avoid TLB misses for large text segments. But it doesn't restrict the file types so a THP could be collapsed for a non-regular file, for example, block device, if it is opened readonly and mapped with EXEC permission. This may cause bugs, like [1] and [2]. This is definitely not the intended usecase, so just collapse THP for regular files in order to close the attack surface. [shy828301@gmail.com: fix vm_file check [3]] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: khugepaged: omitir el colapso de página enorme para archivos especiales El THP de solo lectura para sistemas de archivos colapsará el THP para archivos abiertos de solo lectura y asignados con VM_EXEC. El caso de uso previsto es evitar errores de TLB en segmentos de texto grandes. • https://git.kernel.org/stable/c/99cb0dbd47a15d395bf3faa78dc122bc5efe3fc0 https://git.kernel.org/stable/c/6d67b2a73b8e3a079c355bab3c1aef7d85a044b8 https://git.kernel.org/stable/c/5fcb6fce74ffa614d964667110cf1a516c48c6d9 https://git.kernel.org/stable/c/a4aeaa06d45e90f9b279f0b09de84bd00006e733 https://access.redhat.com/security/cve/CVE-2021-47491 https://bugzilla.redhat.com/show_bug.cgi?id=2282925 • CWE-664: Improper Control of a Resource Through its Lifetime •