CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2021-46911 – ch_ktls: Fix kernel panic
https://notcve.org/view.php?id=CVE-2021-46911
In the Linux kernel, the following vulnerability has been resolved: ch_ktls: Fix kernel panic Taking page refcount is not ideal and causes kernel panic sometimes. It's better to take tx_ctx lock for the complete skb transmit, to avoid page cleanup if ACK received in middle. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ch_ktls: soluciona el pánico del kernel. Realizar un recuento de páginas no es ideal y a veces provoca pánico en el kernel. Es mejor utilizar el bloqueo tx_ctx para la transmisión skb completa, para evitar la limpieza de la página si se recibe ACK en el medio. • https://git.kernel.org/stable/c/5a4b9fe7fece62ecab6fb28fe92362f83b41c33e https://git.kernel.org/stable/c/8d5a9dbd2116a852f8f0f91f6fbc42a0afe1091f https://git.kernel.org/stable/c/8348665d4181c68b0ca1205b48e1753d78bc810f https://git.kernel.org/stable/c/1a73e427b824133940c2dd95ebe26b6dce1cbf10 •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2021-46910 – ARM: 9063/1: mm: reduce maximum number of CPUs if DEBUG_KMAP_LOCAL is enabled
https://notcve.org/view.php?id=CVE-2021-46910
In the Linux kernel, the following vulnerability has been resolved: ARM: 9063/1: mm: reduce maximum number of CPUs if DEBUG_KMAP_LOCAL is enabled The debugging code for kmap_local() doubles the number of per-CPU fixmap slots allocated for kmap_local(), in order to use half of them as guard regions. This causes the fixmap region to grow downwards beyond the start of its reserved window if the supported number of CPUs is large, and collide with the newly added virtual DT mapping right below it, which is obviously not good. One manifestation of this is EFI boot on a kernel built with NR_CPUS=32 and CONFIG_DEBUG_KMAP_LOCAL=y, which may pass the FDT in highmem, resulting in block entries below the fixmap region that the fixmap code misidentifies as fixmap table entries, and subsequently tries to dereference using a phys-to-virt translation that is only valid for lowmem. This results in a cryptic splat such as the one below. ftrace: allocating 45548 entries in 89 pages 8<--- cut here --- Unable to handle kernel paging request at virtual address fc6006f0 pgd = (ptrval) [fc6006f0] *pgd=80000040207003, *pmd=00000000 Internal error: Oops: a06 [#1] SMP ARM Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 5.11.0+ #382 Hardware name: Generic DT based system PC is at cpu_ca15_set_pte_ext+0x24/0x30 LR is at __set_fixmap+0xe4/0x118 pc : [<c041ac9c>] lr : [<c04189d8>] psr: 400000d3 sp : c1601ed8 ip : 00400000 fp : 00800000 r10: 0000071f r9 : 00421000 r8 : 00c00000 r7 : 00c00000 r6 : 0000071f r5 : ffade000 r4 : 4040171f r3 : 00c00000 r2 : 4040171f r1 : c041ac78 r0 : fc6006f0 Flags: nZcv IRQs off FIQs off Mode SVC_32 ISA ARM Segment none Control: 30c5387d Table: 40203000 DAC: 00000001 Process swapper (pid: 0, stack limit = 0x(ptrval)) So let's limit CONFIG_NR_CPUS to 16 when CONFIG_DEBUG_KMAP_LOCAL=y. Also, fix the BUILD_BUG_ON() check that was supposed to catch this, by checking whether the region grows below the start address rather than above the end address. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ARM: 9063/1: mm: reduce el número máximo de CPU si DEBUG_KMAP_LOCAL está habilitado El código de depuración para kmap_local() duplica el número de ranuras de mapas de reparación por CPU asignadas para kmap_local() , para utilizar la mitad de ellos como regiones de guardia. • https://git.kernel.org/stable/c/2a15ba82fa6ca3f35502b3060f22118a938d2889 https://git.kernel.org/stable/c/5965ac11b1d5fcb38464728931649cd9df79c7c9 https://git.kernel.org/stable/c/d624833f5984d484c5e3196f34b926f9e71dafee •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2021-46909 – ARM: footbridge: fix PCI interrupt mapping
https://notcve.org/view.php?id=CVE-2021-46909
In the Linux kernel, the following vulnerability has been resolved: ARM: footbridge: fix PCI interrupt mapping Since commit 30fdfb929e82 ("PCI: Add a call to pci_assign_irq() in pci_device_probe()"), the PCI code will call the IRQ mapping function whenever a PCI driver is probed. If these are marked as __init, this causes an oops if a PCI driver is loaded or bound after the kernel has initialised. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ARM: footbridge: corrige el mapeo de interrupciones PCI Desde el commit 30fdfb929e82 ("PCI: agregue una llamada a pci_assign_irq() en pci_device_probe()"), el código PCI llamará a la función de mapeo IRQ cada vez que se prueba un controlador PCI. Si están marcados como __init, esto provoca un error si se carga o enlaza un controlador PCI después de que el kernel se haya inicializado. • https://git.kernel.org/stable/c/30fdfb929e82450bbf3d0e0aba56efbc29b52b52 https://git.kernel.org/stable/c/532747fd5c7aaa17ee5cf79f3e947c31eb0e35cf https://git.kernel.org/stable/c/2643da6aa57920d9159a1a579fb04f89a2b0d29a https://git.kernel.org/stable/c/871b569a3e67f570df9f5ba195444dc7c621293b https://git.kernel.org/stable/c/1fc087fdb98d556b416c82ed6e3964a30885f47a https://git.kernel.org/stable/c/c3efce8cc9807339633ee30e39882f4c8626ee1d https://git.kernel.org/stable/c/30e3b4f256b4e366a61658c294f6a21b8626dda7 https://access.redhat.com/security/cve/CVE-2021-46909 • CWE-391: Unchecked Error Condition CWE-754: Improper Check for Unusual or Exceptional Conditions •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2021-46908 – bpf: Use correct permission flag for mixed signed bounds arithmetic
https://notcve.org/view.php?id=CVE-2021-46908
In the Linux kernel, the following vulnerability has been resolved: bpf: Use correct permission flag for mixed signed bounds arithmetic We forbid adding unknown scalars with mixed signed bounds due to the spectre v1 masking mitigation. Hence this also needs bypass_spec_v1 flag instead of allow_ptr_leaks. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf: use el indicador de permiso correcto para aritmética de los límites con signo mixto Prohibimos agregar escalares desconocidos con límites con signo mixto debido a la mitigación de enmascaramiento de Spectre v1. Por lo tanto, esto también necesita el indicador bypass_spec_v1 en lugar de enable_ptr_leaks. • https://git.kernel.org/stable/c/2c78ee898d8f10ae6fb2fa23a3fbaec96b1b7366 https://git.kernel.org/stable/c/4f3ff11204eac0ee23acf64deecb3bad7b0db0c6 https://git.kernel.org/stable/c/4ccdc6c6cae38b91c871293fb0ed8c6845a61b51 https://git.kernel.org/stable/c/9601148392520e2e134936e76788fc2a6371e7be •
CVSS: 7.8EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52474 – IB/hfi1: Fix bugs with non-PAGE_SIZE-end multi-iovec user SDMA requests
https://notcve.org/view.php?id=CVE-2023-52474
In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Fix bugs with non-PAGE_SIZE-end multi-iovec user SDMA requests hfi1 user SDMA request processing has two bugs that can cause data corruption for user SDMA requests that have multiple payload iovecs where an iovec other than the tail iovec does not run up to the page boundary for the buffer pointed to by that iovec.a Here are the specific bugs: 1. user_sdma_txadd() does not use struct user_sdma_iovec->iov.iov_len. Rather, user_sdma_txadd() will add up to PAGE_SIZE bytes from iovec to the packet, even if some of those bytes are past iovec->iov.iov_len and are thus not intended to be in the packet. 2. user_sdma_txadd() and user_sdma_send_pkts() fail to advance to the next iovec in user_sdma_request->iovs when the current iovec is not PAGE_SIZE and does not contain enough data to complete the packet. The transmitted packet will contain the wrong data from the iovec pages. This has not been an issue with SDMA packets from hfi1 Verbs or PSM2 because they only produce iovecs that end short of PAGE_SIZE as the tail iovec of an SDMA request. Fixing these bugs exposes other bugs with the SDMA pin cache (struct mmu_rb_handler) that get in way of supporting user SDMA requests with multiple payload iovecs whose buffers do not end at PAGE_SIZE. So this commit fixes those issues as well. Here are the mmu_rb_handler bugs that non-PAGE_SIZE-end multi-iovec payload user SDMA requests can hit: 1. Overlapping memory ranges in mmu_rb_handler will result in duplicate pinnings. 2. When extending an existing mmu_rb_handler entry (struct mmu_rb_node), the mmu_rb code (1) removes the existing entry under a lock, (2) releases that lock, pins the new pages, (3) then reacquires the lock to insert the extended mmu_rb_node. If someone else comes in and inserts an overlapping entry between (2) and (3), insert in (3) will fail. The failure path code in this case unpins _all_ pages in either the original mmu_rb_node or the new mmu_rb_node that was inserted between (2) and (3). 3. • https://git.kernel.org/stable/c/7724105686e718ac476a6ad3304fea2fbcfcffde https://git.kernel.org/stable/c/9c4c6512d7330b743c4ffd18bd999a86ca26db0d https://git.kernel.org/stable/c/a2bd706ab63509793b5cd5065e685b7ef5cba678 https://git.kernel.org/stable/c/dce59b5443700fbd0d2433ec6e4d4cf063448844 https://git.kernel.org/stable/c/c76cb8f4bdf26d04cfa5485a93ce297dba5e6a80 https://git.kernel.org/stable/c/7e6010f79b58f45b204cf18aa58f4b73c3f30adc https://git.kernel.org/stable/c/00cbce5cbf88459cd1aa1d60d0f1df15477df127 •