CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2022-48630 – crypto: qcom-rng - fix infinite loop on requests not multiple of WORD_SZ
https://notcve.org/view.php?id=CVE-2022-48630
In the Linux kernel, the following vulnerability has been resolved: crypto: qcom-rng - fix infinite loop on requests not multiple of WORD_SZ The commit referenced in the Fixes tag removed the 'break' from the else branch in qcom_rng_read(), causing an infinite loop whenever 'max' is not a multiple of WORD_SZ. This can be reproduced e.g. by running: kcapi-rng -b 67 >/dev/null There are many ways to fix this without adding back the 'break', but they all seem more awkward than simply adding it back, so do just that. Tested on a machine with Qualcomm Amberwing processor. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: crypto: qcom-rng: corrige el bucle infinito en solicitudes que no sean múltiples de WORD_SZ. El commit a la que se hace referencia en la etiqueta Fixes eliminó la 'ruptura' de la rama else en qcom_rng_read(), lo que provocó una bucle infinito siempre que 'max' no sea un múltiplo de WORD_SZ. Esto se puede reproducir, por ejemplo, ejecutando: kcapi-rng -b 67 >/dev/null Hay muchas formas de solucionar este problema sin volver a agregar el 'descanso', pero todas parecen más incómodas que simplemente volver a agregarlo, así que hazlo. • https://git.kernel.org/stable/c/a8e32bbb96c25b7ab29b1894dcd45e0b3b08fd9d https://git.kernel.org/stable/c/184f7bd08ce56f003530fc19f160d54e75bf5c9d https://git.kernel.org/stable/c/0f9b7b8df17525e464294c916acc8194ce38446b https://git.kernel.org/stable/c/ab9337c7cb6f875b6286440b1adfbeeef2b2b2bd https://git.kernel.org/stable/c/a680b1832ced3b5fa7c93484248fd221ea0d614b https://git.kernel.org/stable/c/485995cbc98a4f77cfd4f8ed4dd7ff8ab262964d https://git.kernel.org/stable/c/71a89789552b7faf3ef27969b9bc783fa0df3550 https://git.kernel.org/stable/c/8be06f62b426801dba43ddf8893952a0e •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2022-48629 – crypto: qcom-rng - ensure buffer for generate is completely filled
https://notcve.org/view.php?id=CVE-2022-48629
In the Linux kernel, the following vulnerability has been resolved: crypto: qcom-rng - ensure buffer for generate is completely filled The generate function in struct rng_alg expects that the destination buffer is completely filled if the function returns 0. qcom_rng_read() can run into a situation where the buffer is partially filled with randomness and the remaining part of the buffer is zeroed since qcom_rng_generate() doesn't check the return value. This issue can be reproduced by running the following from libkcapi: kcapi-rng -b 9000000 > OUTFILE The generated OUTFILE will have three huge sections that contain all zeros, and this is caused by the code where the test 'val & PRNG_STATUS_DATA_AVAIL' fails. Let's fix this issue by ensuring that qcom_rng_read() always returns with a full buffer if the function returns success. Let's also have qcom_rng_generate() return the correct value. Here's some statistics from the ent project (https://www.fourmilab.ch/random/) that shows information about the quality of the generated numbers: $ ent -c qcom-random-before Value Char Occurrences Fraction 0 606748 0.067416 1 33104 0.003678 2 33001 0.003667 ... 253 � 32883 0.003654 254 � 33035 0.003671 255 � 33239 0.003693 Total: 9000000 1.000000 Entropy = 7.811590 bits per byte. Optimum compression would reduce the size of this 9000000 byte file by 2 percent. Chi square distribution for 9000000 samples is 9329962.81, and randomly would exceed this value less than 0.01 percent of the times. Arithmetic mean value of data bytes is 119.3731 (127.5 = random). Monte Carlo value for Pi is 3.197293333 (error 1.77 percent). Serial correlation coefficient is 0.159130 (totally uncorrelated = 0.0). Without this patch, the results of the chi-square test is 0.01%, and the numbers are certainly not random according to ent's project page. The results improve with this patch: $ ent -c qcom-random-after Value Char Occurrences Fraction 0 35432 0.003937 1 35127 0.003903 2 35424 0.003936 ... 253 � 35201 0.003911 254 � 34835 0.003871 255 � 35368 0.003930 Total: 9000000 1.000000 Entropy = 7.999979 bits per byte. Optimum compression would reduce the size of this 9000000 byte file by 0 percent. Chi square distribution for 9000000 samples is 258.77, and randomly would exceed this value 42.24 percent of the times. Arithmetic mean value of data bytes is 127.5006 (127.5 = random). Monte Carlo value for Pi is 3.141277333 (error 0.01 percent). Serial correlation coefficient is 0.000468 (totally uncorrelated = 0.0). This change was tested on a Nexus 5 phone (msm8974 SoC). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: qcom-rng: asegúrese de que el búfer para generar esté completamente lleno. La función de generación en la estructura rng_alg espera que el búfer de destino esté completamente lleno si la función devuelve 0. qcom_rng_read() puede ejecutarse en una situación en la que el búfer está parcialmente lleno de aleatoriedad y la parte restante del búfer se pone a cero ya que qcom_rng_generate() no verifica el valor de retorno. • https://git.kernel.org/stable/c/ceec5f5b59882b871a722ca4d49b767a09a4bde9 https://git.kernel.org/stable/c/a8e32bbb96c25b7ab29b1894dcd45e0b3b08fd9d https://git.kernel.org/stable/c/184f7bd08ce56f003530fc19f160d54e75bf5c9d https://git.kernel.org/stable/c/0f9b7b8df17525e464294c916acc8194ce38446b https://git.kernel.org/stable/c/ab9337c7cb6f875b6286440b1adfbeeef2b2b2bd https://git.kernel.org/stable/c/485995cbc98a4f77cfd4f8ed4dd7ff8ab262964d https://git.kernel.org/stable/c/a680b1832ced3b5fa7c93484248fd221ea0d614b •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47105 – ice: xsk: return xsk buffers back to pool when cleaning the ring
https://notcve.org/view.php?id=CVE-2021-47105
In the Linux kernel, the following vulnerability has been resolved: ice: xsk: return xsk buffers back to pool when cleaning the ring Currently we only NULL the xdp_buff pointer in the internal SW ring but we never give it back to the xsk buffer pool. This means that buffers can be leaked out of the buff pool and never be used again. Add missing xsk_buff_free() call to the routine that is supposed to clean the entries that are left in the ring so that these buffers in the umem can be used by other sockets. Also, only go through the space that is actually left to be cleaned instead of a whole ring. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: xsk: devuelve los buffers xsk al grupo al limpiar el anillo. Actualmente solo hacemos NULL en el puntero xdp_buff en el anillo SW interno, pero nunca lo devolvemos al grupo de buffers xsk. Esto significa que los buffers se pueden filtrar fuera del grupo de buffers y no volver a usarse nunca más. • https://git.kernel.org/stable/c/2d4238f5569722197612656163d824098208519c https://git.kernel.org/stable/c/ad6d20da2cfbe14b7b1200d15f39e65988b0b9e8 https://git.kernel.org/stable/c/afe8a3ba85ec2a6b6849367e25c06a2f8e0ddd05 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2021-47104 – IB/qib: Fix memory leak in qib_user_sdma_queue_pkts()
https://notcve.org/view.php?id=CVE-2021-47104
In the Linux kernel, the following vulnerability has been resolved: IB/qib: Fix memory leak in qib_user_sdma_queue_pkts() The wrong goto label was used for the error case and missed cleanup of the pkt allocation. Addresses-Coverity-ID: 1493352 ("Resource leak") En el kernel de Linux, se resolvió la siguiente vulnerabilidad: IB/qib: corrige la pérdida de memoria en qib_user_sdma_queue_pkts() Se utilizó la etiqueta goto incorrecta para el caso de error y se omitió la limpieza de la asignación de paquetes. Direcciones-Coverity-ID: 1493352 ("Fuga de recursos") • https://git.kernel.org/stable/c/bda41654b6e0c125a624ca35d6d20beb8015b5d0 https://git.kernel.org/stable/c/3f57c3f67fd93b4da86aeffea1ca32c484d054ad https://git.kernel.org/stable/c/60833707b968d5ae02a75edb7886dcd4a957cf0d https://git.kernel.org/stable/c/73d2892148aa4397a885b4f4afcfc5b27a325c42 https://git.kernel.org/stable/c/0f8cdfff06829a0b0348b6debc29ff6a61967724 https://git.kernel.org/stable/c/c3e17e58f571f34c51aeb17274ed02c2ed5cf780 https://git.kernel.org/stable/c/d39bf40e55e666b5905fdbd46a0dced030ce87be https://git.kernel.org/stable/c/0d4395477741608d123dad51def9fe50b •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2021-47103 – inet: fully convert sk->sk_rx_dst to RCU rules
https://notcve.org/view.php?id=CVE-2021-47103
In the Linux kernel, the following vulnerability has been resolved: inet: fully convert sk->sk_rx_dst to RCU rules syzbot reported various issues around early demux, one being included in this changelog [1] sk->sk_rx_dst is using RCU protection without clearly documenting it. And following sequences in tcp_v4_do_rcv()/tcp_v6_do_rcv() are not following standard RCU rules. [a] dst_release(dst); [b] sk->sk_rx_dst = NULL; They look wrong because a delete operation of RCU protected pointer is supposed to clear the pointer before the call_rcu()/synchronize_rcu() guarding actual memory freeing. In some cases indeed, dst could be freed before [b] is done. We could cheat by clearing sk_rx_dst before calling dst_release(), but this seems the right time to stick to standard RCU annotations and debugging facilities. [1] BUG: KASAN: use-after-free in dst_check include/net/dst.h:470 [inline] BUG: KASAN: use-after-free in tcp_v4_early_demux+0x95b/0x960 net/ipv4/tcp_ipv4.c:1792 Read of size 2 at addr ffff88807f1cb73a by task syz-executor.5/9204 CPU: 0 PID: 9204 Comm: syz-executor.5 Not tainted 5.16.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0x8d/0x320 mm/kasan/report.c:247 __kasan_report mm/kasan/report.c:433 [inline] kasan_report.cold+0x83/0xdf mm/kasan/report.c:450 dst_check include/net/dst.h:470 [inline] tcp_v4_early_demux+0x95b/0x960 net/ipv4/tcp_ipv4.c:1792 ip_rcv_finish_core.constprop.0+0x15de/0x1e80 net/ipv4/ip_input.c:340 ip_list_rcv_finish.constprop.0+0x1b2/0x6e0 net/ipv4/ip_input.c:583 ip_sublist_rcv net/ipv4/ip_input.c:609 [inline] ip_list_rcv+0x34e/0x490 net/ipv4/ip_input.c:644 __netif_receive_skb_list_ptype net/core/dev.c:5508 [inline] __netif_receive_skb_list_core+0x549/0x8e0 net/core/dev.c:5556 __netif_receive_skb_list net/core/dev.c:5608 [inline] netif_receive_skb_list_internal+0x75e/0xd80 net/core/dev.c:5699 gro_normal_list net/core/dev.c:5853 [inline] gro_normal_list net/core/dev.c:5849 [inline] napi_complete_done+0x1f1/0x880 net/core/dev.c:6590 virtqueue_napi_complete drivers/net/virtio_net.c:339 [inline] virtnet_poll+0xca2/0x11b0 drivers/net/virtio_net.c:1557 __napi_poll+0xaf/0x440 net/core/dev.c:7023 napi_poll net/core/dev.c:7090 [inline] net_rx_action+0x801/0xb40 net/core/dev.c:7177 __do_softirq+0x29b/0x9c2 kernel/softirq.c:558 invoke_softirq kernel/softirq.c:432 [inline] __irq_exit_rcu+0x123/0x180 kernel/softirq.c:637 irq_exit_rcu+0x5/0x20 kernel/softirq.c:649 common_interrupt+0x52/0xc0 arch/x86/kernel/irq.c:240 asm_common_interrupt+0x1e/0x40 arch/x86/include/asm/idtentry.h:629 RIP: 0033:0x7f5e972bfd57 Code: 39 d1 73 14 0f 1f 80 00 00 00 00 48 8b 50 f8 48 83 e8 08 48 39 ca 77 f3 48 39 c3 73 3e 48 89 13 48 8b 50 f8 48 89 38 49 8b 0e <48> 8b 3e 48 83 c3 08 48 83 c6 08 eb bc 48 39 d1 72 9e 48 39 d0 73 RSP: 002b:00007fff8a413210 EFLAGS: 00000283 RAX: 00007f5e97108990 RBX: 00007f5e97108338 RCX: ffffffff81d3aa45 RDX: ffffffff81d3aa45 RSI: 00007f5e97108340 RDI: ffffffff81d3aa45 RBP: 00007f5e97107eb8 R08: 00007f5e97108d88 R09: 0000000093c2e8d9 R10: 0000000000000000 R11: 0000000000000000 R12: 00007f5e97107eb0 R13: 00007f5e97108338 R14: 00007f5e97107ea8 R15: 0000000000000019 </TASK> Allocated by task 13: kasan_save_stack+0x1e/0x50 mm/kasan/common.c:38 kasan_set_track mm/kasan/common.c:46 [inline] set_alloc_info mm/kasan/common.c:434 [inline] __kasan_slab_alloc+0x90/0xc0 mm/kasan/common.c:467 kasan_slab_alloc include/linux/kasan.h:259 [inline] slab_post_alloc_hook mm/slab.h:519 [inline] slab_alloc_node mm/slub.c:3234 [inline] slab_alloc mm/slub.c:3242 [inline] kmem_cache_alloc+0x202/0x3a0 mm/slub.c:3247 dst_alloc+0x146/0x1f0 net/core/dst.c:92 rt_dst_alloc+0x73/0x430 net/ipv4/route.c:1613 ip_route_input_slow+0x1817/0x3a20 net/ipv4/route.c:234 ---truncated--- En el kernel de Linux, se resolvió la siguiente vulnerabilidad: inet: conversión completa de sk->sk_rx_dst a reglas de RCU syzbot informó varios problemas relacionados con la demux inicial, uno de los cuales se incluye en este registro de cambios [1] sk->sk_rx_dst está usando protección de RCU sin claridad documentándolo. Y las siguientes secuencias en tcp_v4_do_rcv()/tcp_v6_do_rcv() no siguen las reglas estándar de RCU. [a] dst_release(dst); [b] sk->sk_rx_dst = NULL; Se ven incorrectos porque se supone que una operación de eliminación del puntero protegido de RCU borra el puntero antes de que call_rcu()/synchronize_rcu() proteja la liberación de memoria real. De hecho, en algunos casos, dst podría liberarse antes de que se realice [b]. Podríamos hacer trampa borrando sk_rx_dst antes de llamar a dst_release(), pero este parece el momento adecuado para ceñirnos a las anotaciones estándar de RCU y las funciones de depuración • https://git.kernel.org/stable/c/41063e9dd11956f2d285e12e4342e1d232ba0ea2 https://git.kernel.org/stable/c/68c34ce11ef23328692aa35fa6aaafdd75913100 https://git.kernel.org/stable/c/92e6e36ecd16808866ac6172b9491b5097cde449 https://git.kernel.org/stable/c/75a578000ae5e511e5d0e8433c94a14d9c99c412 https://git.kernel.org/stable/c/c3bb4a7e8cbc984e1cdac0fe6af60e880214ed6e https://git.kernel.org/stable/c/f039b43cbaea5e0700980c2f0052da05a70782e0 https://git.kernel.org/stable/c/0249a4b8a554f2eb6a27b62516fa50168584faa4 https://git.kernel.org/stable/c/8f905c0e7354ef261360fb7535ea079b1 •