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: 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 •