CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-46995 – can: mcp251xfd: mcp251xfd_probe(): fix an error pointer dereference in probe
https://notcve.org/view.php?id=CVE-2021-46995
In the Linux kernel, the following vulnerability has been resolved: can: mcp251xfd: mcp251xfd_probe(): fix an error pointer dereference in probe When we converted this code to use dev_err_probe() we accidentally removed a return. It means that if devm_clk_get() it will lead to an Oops when we call clk_get_rate() on the next line. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: mcp251xfd: mcp251xfd_probe(): corrige una desreferencia de puntero de error en la sonda Cuando convertimos este código para usar dev_err_probe() eliminamos accidentalmente un retorno. Significa que si devm_clk_get() generará un Ups cuando llamemos a clk_get_rate() en la siguiente línea. • https://git.kernel.org/stable/c/cf8ee6de2543a0fa6d9471ddbb7216464a9681a1 https://git.kernel.org/stable/c/15f8f96ec7fc35024d4e03296e4d838fcea33d83 https://git.kernel.org/stable/c/4cc7faa406975b460aa674606291dea197c1210c •
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 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2021-46991 – i40e: Fix use-after-free in i40e_client_subtask()
https://notcve.org/view.php?id=CVE-2021-46991
In the Linux kernel, the following vulnerability has been resolved: i40e: Fix use-after-free in i40e_client_subtask() Currently the call to i40e_client_del_instance frees the object pf->cinst, however pf->cinst->lan_info is being accessed after the free. Fix this by adding the missing return. Addresses-Coverity: ("Read from pointer after free") En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i40e: Se corrige use-after-free en i40e_client_subtask() Actualmente la llamada a i40e_client_del_instance libera el objeto pf->cinst, sin embargo se accede a pf->cinst->lan_info después de gratis. Solucione este problema agregando la declaración que falta. Direcciones-Cobertura: ("Leer desde el puntero después de estar libre") • https://git.kernel.org/stable/c/7b0b1a6d0ac983ce1928432285d0222d4fb7c38b https://git.kernel.org/stable/c/c1322eaeb8af0d8985b5cc5fa759140fa0e57b84 https://git.kernel.org/stable/c/d718c15a2bf9ae082d5ae4d177fb19ef23cb4132 https://git.kernel.org/stable/c/829a713450b8fb127cbabfc1244c1d8179ec5107 https://git.kernel.org/stable/c/4ebc10aa7cd17fd9857dedac69600465c9dd16d1 https://git.kernel.org/stable/c/1fd5d262e7442192ac7611ff1597a36c5b044323 https://git.kernel.org/stable/c/38318f23a7ef86a8b1862e5e8078c4de121960c3 •