CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2021-46912 – net: Make tcp_allowed_congestion_control readonly in non-init netns
https://notcve.org/view.php?id=CVE-2021-46912
In the Linux kernel, the following vulnerability has been resolved: net: Make tcp_allowed_congestion_control readonly in non-init netns Currently, tcp_allowed_congestion_control is global and writable; writing to it in any net namespace will leak into all other net namespaces. tcp_available_congestion_control and tcp_allowed_congestion_control are the only sysctls in ipv4_net_table (the per-netns sysctl table) with a NULL data pointer; their handlers (proc_tcp_available_congestion_control and proc_allowed_congestion_control) have no other way of referencing a struct net. Thus, they operate globally. Because ipv4_net_table does not use designated initializers, there is no easy way to fix up this one "bad" table entry. However, the data pointer updating logic shouldn't be applied to NULL pointers anyway, so we instead force these entries to be read-only. These sysctls used to exist in ipv4_table (init-net only), but they were moved to the per-net ipv4_net_table, presumably without realizing that tcp_allowed_congestion_control was writable and thus introduced a leak. Because the intent of that commit was only to know (i.e. read) "which congestion algorithms are available or allowed", this read-only solution should be sufficient. The logic added in recent commit 31c4d2f160eb: ("net: Ensure net namespace isolation of sysctls") does not and cannot check for NULL data pointers, because other table entries (e.g. /proc/sys/net/netfilter/nf_log/) have .data=NULL but use other methods (.extra2) to access the struct net. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: hacer que tcp_allowed_congestion_control sea de solo lectura en redes no init. • https://git.kernel.org/stable/c/9cb8e048e5d93825ec5e8dfb5b8df4987ea25745 https://git.kernel.org/stable/c/35d7491e2f77ce480097cabcaf93ed409e916e12 https://git.kernel.org/stable/c/1ccdf1bed140820240e383ba0accc474ffc7f006 https://git.kernel.org/stable/c/97684f0970f6e112926de631fdd98d9693c7e5c1 • CWE-476: NULL Pointer Dereference •
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 •