CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2021-46992 – netfilter: nftables: avoid overflows in nft_hash_buckets()
https://notcve.org/view.php?id=CVE-2021-46992
In the Linux kernel, the following vulnerability has been resolved: netfilter: nftables: avoid overflows in nft_hash_buckets() Number of buckets being stored in 32bit variables, we have to ensure that no overflows occur in nft_hash_buckets() syzbot injected a size == 0x40000000 and reported: UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13 shift exponent 64 is too large for 64-bit type 'long unsigned int' CPU: 1 PID: 29539 Comm: syz-executor.4 Not tainted 5.12.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x141/0x1d7 lib/dump_stack.c:120 ubsan_epilogue+0xb/0x5a lib/ubsan.c:148 __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:327 __roundup_pow_of_two include/linux/log2.h:57 [inline] nft_hash_buckets net/netfilter/nft_set_hash.c:411 [inline] nft_hash_estimate.cold+0x19/0x1e net/netfilter/nft_set_hash.c:652 nft_select_set_ops net/netfilter/nf_tables_api.c:3586 [inline] nf_tables_newset+0xe62/0x3110 net/netfilter/nf_tables_api.c:4322 nfnetlink_rcv_batch+0xa09/0x24b0 net/netfilter/nfnetlink.c:488 nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:612 [inline] nfnetlink_rcv+0x3af/0x420 net/netfilter/nfnetlink.c:630 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nftables: evitar desbordamientos en nft_hash_buckets() Número de depósitos almacenados en variables de 32 bits, debemos asegurarnos de que no se produzcan desbordamientos en nft_hash_buckets() syzbot inyectó un tamaño == 0x40000000 e informó: UBSAN: desplazamiento fuera de los límites en ./include/linux/log2.h:57:13 el exponente de desplazamiento 64 es demasiado grande para el tipo de 64 bits 'long unsigned int' CPU: 1 PID: 29539 Comm: syz-executor.4 Not tainted 5.12.0-rc7-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:79 [en línea] dump_stack +0x141/0x1d7 lib/dump_stack.c:120 ubsan_epilogue+0xb/0x5a lib/ubsan.c:148 __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:327 __roundup_pow_of_two include/linux/log2.h:57 [en línea] nft_hash_buckets net/netfilter/nft_set_hash.c:411 [en línea] nft_hash_estimate.cold+0x19/0x1e net/netfilter/nft_set_hash.c:652 nft_select_set_ops net/netfilter/nf_tables_api.c:3586 [en línea] nf_tables_newset+0xe62 /0x3110 net/filtro de red /nf_tables_api.c:4322 nfnetlink_rcv_batch+0xa09/0x24b0 net/netfilter/nfnetlink.c:488 nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:612 [en línea] nfnetlink_rcv+0x3af/0x420 net/netfilter/nfnetlink.c:630 netlink_unicast_kernel net/ netlink/af_netlink.c:1312 [en línea] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [en línea] sock_sendmsg +0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 do_sys llamada_64+0x2d /0x70 arco/x86/entry/common.c:46 • https://git.kernel.org/stable/c/0ed6389c483dc77cdbdd48de0ca7ce41723dd667 https://git.kernel.org/stable/c/2824cafc6a93792d9ad85939c499161214d84c4b https://git.kernel.org/stable/c/efcd730ddd6f25578bd31bfe703e593e2421d708 https://git.kernel.org/stable/c/c77e2ef18167ad334e27610ced9a7f6af5ec1787 https://git.kernel.org/stable/c/72b49dd116ca00a46a11d5a4d8d7987f05ed9cd7 https://git.kernel.org/stable/c/1e8ab479cfbe5751efccedb95afb9b112a5ba475 https://git.kernel.org/stable/c/a388d10961ff8578b1a6691945d406c0f33aa71b https://git.kernel.org/stable/c/a54754ec9891830ba548e2010c889e3c8 •
CVSS: -EPSS: 0%CPEs: 10EXPL: 0CVE-2021-46990 – powerpc/64s: Fix crashes when toggling entry flush barrier
https://notcve.org/view.php?id=CVE-2021-46990
In the Linux kernel, the following vulnerability has been resolved: powerpc/64s: Fix crashes when toggling entry flush barrier The entry flush mitigation can be enabled/disabled at runtime via a debugfs file (entry_flush), which causes the kernel to patch itself to enable/disable the relevant mitigations. However depending on which mitigation we're using, it may not be safe to do that patching while other CPUs are active. For example the following crash: sleeper[15639]: segfault (11) at c000000000004c20 nip c000000000004c20 lr c000000000004c20 Shows that we returned to userspace with a corrupted LR that points into the kernel, due to executing the partially patched call to the fallback entry flush (ie. we missed the LR restore). Fix it by doing the patching under stop machine. The CPUs that aren't doing the patching will be spinning in the core of the stop machine logic. That is currently sufficient for our purposes, because none of the patching we do is to that code or anywhere in the vicinity. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: powerpc/64s: soluciona fallas al alternar la barrera de descarga de entrada. • https://git.kernel.org/stable/c/4a1e90af718d1489ffcecc8f52486c4f5dc0f7a6 https://git.kernel.org/stable/c/fa4bf9f38184ed7ca4916eb64f8c767d1e279c1f https://git.kernel.org/stable/c/db01cad9efe3c3838a6b3a3f68affd295c4b92d6 https://git.kernel.org/stable/c/f69bb4e51f41973fb7594be1479fa689831efe1a https://git.kernel.org/stable/c/b65458b6be8032c5179d4f562038575d7b3a6be3 https://git.kernel.org/stable/c/f79643787e0a0762d2409b7b8334e83f22d85695 https://git.kernel.org/stable/c/e590b36718d6e740b7b19514f710402a6499164c https://git.kernel.org/stable/c/8382b15864e5014261b4f36c2aa897236 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-46985 – ACPI: scan: Fix a memory leak in an error handling path
https://notcve.org/view.php?id=CVE-2021-46985
In the Linux kernel, the following vulnerability has been resolved: ACPI: scan: Fix a memory leak in an error handling path If 'acpi_device_set_name()' fails, we must free 'acpi_device_bus_id->bus_id' or there is a (potential) memory leak. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: ACPI: scan: Corregir pérdida de memoria en una ruta de manejo de errores Si falla 'acpi_device_set_name()' debemos liberar 'acpi_device_bus_id->bus_id' o hay una (potencial) memoria filtración. • https://git.kernel.org/stable/c/e5cdbe419004e172f642e876a671a9ff1c52f8bb https://git.kernel.org/stable/c/717d9d88fbd956ab03fad97266f6ce63a036e7f8 https://git.kernel.org/stable/c/7385e438e1f31af5b86f72fd19b0dcd2738502c9 https://git.kernel.org/stable/c/bc0b1a2036dd8072106ec81a8685ecb901f72ed6 https://git.kernel.org/stable/c/4a5891992c680d69d7e490e4d0428d17779d8e85 https://git.kernel.org/stable/c/321dbe6c0b551f9f8030becc6900f77cf9bbb9ad https://git.kernel.org/stable/c/eb50aaf960e3bedfef79063411ffd670da94b84b https://git.kernel.org/stable/c/6901a4f795e0e8d65ae779cb37fc22e0b •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2020-36784 – i2c: cadence: fix reference leak when pm_runtime_get_sync fails
https://notcve.org/view.php?id=CVE-2020-36784
In the Linux kernel, the following vulnerability has been resolved: i2c: cadence: fix reference leak when pm_runtime_get_sync fails The PM reference count is not expected to be incremented on return in functions cdns_i2c_master_xfer and cdns_reg_slave. However, pm_runtime_get_sync will increment pm usage counter even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: i2c: cadencia: corrige la fuga de referencia cuando falla pm_runtime_get_sync No se espera que el recuento de referencias de PM aumente al regresar en las funciones cdns_i2c_master_xfer y cdns_reg_slave. Sin embargo, pm_runtime_get_sync incrementará el contador de uso de pm incluso si falla. Olvidarse de poner en funcionamiento resultará en una fuga de referencia aquí. • https://git.kernel.org/stable/c/7fa32329ca03148fb2c07b4ef3247b8fc0488d6a https://git.kernel.org/stable/c/30410519328c94367e561fd878e5f0d3a0303585 https://git.kernel.org/stable/c/d57ff04e0ed6f3be1682ae861ead33f879225e07 https://git.kernel.org/stable/c/a45fc41beed8e0fe31864619c34aa00797fb60c1 https://git.kernel.org/stable/c/23ceb8462dc6f4b4decdb5536a7e5fc477cdf0b6 •
CVSS: -EPSS: 0%CPEs: 11EXPL: 0CVE-2021-46966 – ACPI: custom_method: fix potential use-after-free issue
https://notcve.org/view.php?id=CVE-2021-46966
In the Linux kernel, the following vulnerability has been resolved: ACPI: custom_method: fix potential use-after-free issue In cm_write(), buf is always freed when reaching the end of the function. If the requested count is less than table.length, the allocated buffer will be freed but subsequent calls to cm_write() will still try to access it. Remove the unconditional kfree(buf) at the end of the function and set the buf to NULL in the -EINVAL error path to match the rest of function. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPI: custom_method: soluciona un posible problema de use-after-free En cm_write(), buf siempre se libera al llegar al final de la función. Si el recuento solicitado es menor que table.length, el búfer asignado se liberará, pero las llamadas posteriores a cm_write() seguirán intentando acceder a él. Elimine el kfree(buf) incondicional al final de la función y establezca el buf en NULL en la ruta de error -EINVAL para que coincida con el resto de la función. • https://git.kernel.org/stable/c/4bda2b79a9d04c8ba31681c66e95877dbb433416 https://git.kernel.org/stable/c/5c12dadcbef8cd55ef1f5dac799bfcbb7ea7db1d https://git.kernel.org/stable/c/35b88a10535edcf62d3e6b7893a8cd506ff98a24 https://git.kernel.org/stable/c/e4467fb6ef547aa352dc03397f9474ec84eced5b https://git.kernel.org/stable/c/03d1571d9513369c17e6848476763ebbd10ec2cb https://git.kernel.org/stable/c/70424999fbf1f160ade111cb9baab51776e0f9c2 https://git.kernel.org/stable/c/06cd4a06eb596a888239fb8ceb6ea15677cab396 https://git.kernel.org/stable/c/1d53ca5d131074c925ce38361fb0376d3 •