CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-46997 – arm64: entry: always set GIC_PRIO_PSR_I_SET during entry
https://notcve.org/view.php?id=CVE-2021-46997
In the Linux kernel, the following vulnerability has been resolved: arm64: entry: always set GIC_PRIO_PSR_I_SET during entry Zenghui reports that booting a kernel with "irqchip.gicv3_pseudo_nmi=1" on the command line hits a warning during kernel entry, due to the way we manipulate the PMR. Early in the entry sequence, we call lockdep_hardirqs_off() to inform lockdep that interrupts have been masked (as the HW sets DAIF wqhen entering an exception). Architecturally PMR_EL1 is not affected by exception entry, and we don't set GIC_PRIO_PSR_I_SET in the PMR early in the exception entry sequence, so early in exception entry the PMR can indicate that interrupts are unmasked even though they are masked by DAIF. If DEBUG_LOCKDEP is selected, lockdep_hardirqs_off() will check that interrupts are masked, before we set GIC_PRIO_PSR_I_SET in any of the exception entry paths, and hence lockdep_hardirqs_off() will WARN() that something is amiss. We can avoid this by consistently setting GIC_PRIO_PSR_I_SET during exception entry so that kernel code sees a consistent environment. We must also update local_daif_inherit() to undo this, as currently only touches DAIF. For other paths, local_daif_restore() will update both DAIF and the PMR. With this done, we can remove the existing special cases which set this later in the entry code. We always use (GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET) for consistency with local_daif_save(), as this will warn if it ever encounters (GIC_PRIO_IRQOFF | GIC_PRIO_PSR_I_SET), and never sets this itself. • https://git.kernel.org/stable/c/2a9b3e6ac69a8bf177d8496a11e749e2dc72fa22 https://git.kernel.org/stable/c/51524fa8b5f7b879ba569227738375d283b79382 https://git.kernel.org/stable/c/e67a83f078005461b59b4c776e6b5addd11725fa https://git.kernel.org/stable/c/d8d52005f57bbb4a4ec02f647e2555d327135c68 https://git.kernel.org/stable/c/4d6a38da8e79e94cbd1344aa90876f0f805db705 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-46996 – netfilter: nftables: Fix a memleak from userdata error path in new objects
https://notcve.org/view.php?id=CVE-2021-46996
In the Linux kernel, the following vulnerability has been resolved: netfilter: nftables: Fix a memleak from userdata error path in new objects Release object name if userdata allocation fails. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nftables: corrige una fuga de memoria de la ruta de error de los datos del usuario en objetos nuevos. Libera el nombre del objeto si falla la asignación de los datos del usuario. • https://git.kernel.org/stable/c/b131c96496b369c7b14125e7c50e89ac7cec8051 https://git.kernel.org/stable/c/2c784a500f5edd337258b0fdb2f31bc9abde1a23 https://git.kernel.org/stable/c/59fa98bfa1f4013d658d990cac88c87b46ff410c https://git.kernel.org/stable/c/dd3bebf515f336214a91994348a2b86b9a1d3d7f https://git.kernel.org/stable/c/85dfd816fabfc16e71786eda0a33a7046688b5b0 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-46994 – can: mcp251x: fix resume from sleep before interface was brought up
https://notcve.org/view.php?id=CVE-2021-46994
In the Linux kernel, the following vulnerability has been resolved: can: mcp251x: fix resume from sleep before interface was brought up Since 8ce8c0abcba3 the driver queues work via priv->restart_work when resuming after suspend, even when the interface was not previously enabled. This causes a null dereference error as the workqueue is only allocated and initialized in mcp251x_open(). To fix this we move the workqueue init to mcp251x_can_probe() as there is no reason to do it later and repeat it whenever mcp251x_open() is called. [mkl: fix error handling in mcp251x_stop()] En el kernel de Linux, se resolvió la siguiente vulnerabilidad: can: mcp251x: corregir la reanudación desde la suspensión antes de que se activara la interfaz. Desde 8ce8c0abcba3, las colas de controladores funcionan a través de priv->restart_work cuando se reanudan después de la suspensión, incluso cuando la interfaz no estaba habilitada previamente. Esto provoca un error de desreferencia nula ya que la cola de trabajo solo se asigna e inicializa en mcp251x_open(). Para solucionar este problema, movemos el inicio de la cola de trabajo a mcp251x_can_probe() ya que no hay razón para hacerlo más tarde y repetirlo cada vez que se llama a mcp251x_open(). • https://git.kernel.org/stable/c/8ce8c0abcba314e1fe954a1840f6568bf5aef2ef https://git.kernel.org/stable/c/eecb4df8ec9f896b19ee05bfa632ac6c1dcd8f21 https://git.kernel.org/stable/c/6f8f1c27b577de15f69fefce3c502bb6300d825c https://git.kernel.org/stable/c/e1e10a390fd9479209c4d834d916ca5e6d5d396b https://git.kernel.org/stable/c/03c427147b2d3e503af258711af4fc792b89b0af •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2021-46993 – sched: Fix out-of-bound access in uclamp
https://notcve.org/view.php?id=CVE-2021-46993
In the Linux kernel, the following vulnerability has been resolved: sched: Fix out-of-bound access in uclamp Util-clamp places tasks in different buckets based on their clamp values for performance reasons. However, the size of buckets is currently computed using a rounding division, which can lead to an off-by-one error in some configurations. For instance, with 20 buckets, the bucket size will be 1024/20=51. A task with a clamp of 1024 will be mapped to bucket id 1024/51=20. Sadly, correct indexes are in range [0,19], hence leading to an out of bound memory access. Clamp the bucket id to fix the issue. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sched: corrige el acceso fuera de los límites en uclamp Util-clamp coloca las tareas en diferentes depósitos según sus valores de fijación por razones de rendimiento. • https://git.kernel.org/stable/c/69842cba9ace84849bb9b8edcdf2cefccd97901c https://git.kernel.org/stable/c/687f523c134b7f0bd040ee1230f6d17990d54172 https://git.kernel.org/stable/c/f7347c85490b92dd144fa1fba9e1eca501656ab3 https://git.kernel.org/stable/c/3da3f804b82a0a382d523a21acf4cf3bb35f936d https://git.kernel.org/stable/c/42ee47c7e3569d9a0e2cb5053c496d97d380472f https://git.kernel.org/stable/c/6d2f8909a5fabb73fe2a63918117943986c39b6c •
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 •