CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47451 – netfilter: xt_IDLETIMER: fix panic that occurs when timer_type has garbage value
https://notcve.org/view.php?id=CVE-2021-47451
In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_IDLETIMER: fix panic that occurs when timer_type has garbage value Currently, when the rule related to IDLETIMER is added, idletimer_tg timer structure is initialized by kmalloc on executing idletimer_tg_create function. However, in this process timer->timer_type is not defined to a specific value. Thus, timer->timer_type has garbage value and it occurs kernel panic. So, this commit fixes the panic by initializing timer->timer_type using kzalloc instead of kmalloc. Test commands: # iptables -A OUTPUT -j IDLETIMER --timeout 1 --label test $ cat /sys/class/xt_idletimer/timers/test Killed Splat looks like: BUG: KASAN: user-memory-access in alarm_expires_remaining+0x49/0x70 Read of size 8 at addr 0000002e8c7bc4c8 by task cat/917 CPU: 12 PID: 917 Comm: cat Not tainted 5.14.0+ #3 79940a339f71eb14fc81aee1757a20d5bf13eb0e Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: dump_stack_lvl+0x6e/0x9c kasan_report.cold+0x112/0x117 ? alarm_expires_remaining+0x49/0x70 __asan_load8+0x86/0xb0 alarm_expires_remaining+0x49/0x70 idletimer_tg_show+0xe5/0x19b [xt_IDLETIMER 11219304af9316a21bee5ba9d58f76a6b9bccc6d] dev_attr_show+0x3c/0x60 sysfs_kf_seq_show+0x11d/0x1f0 ? • https://git.kernel.org/stable/c/68983a354a655c35d3fb204489d383a2a051fda7 https://git.kernel.org/stable/c/2a670c323055282c9b72794a491d53cef86bbeaf https://git.kernel.org/stable/c/cae7cab804c943d723d52724a3aeb07a3f4a2650 https://git.kernel.org/stable/c/902c0b1887522a099aa4e1e6b4b476c2fe5dd13e •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47450 – KVM: arm64: Fix host stage-2 PGD refcount
https://notcve.org/view.php?id=CVE-2021-47450
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Fix host stage-2 PGD refcount The KVM page-table library refcounts the pages of concatenated stage-2 PGDs individually. However, when running KVM in protected mode, the host's stage-2 PGD is currently managed by EL2 as a single high-order compound page, which can cause the refcount of the tail pages to reach 0 when they shouldn't, hence corrupting the page-table. Fix this by introducing a new hyp_split_page() helper in the EL2 page allocator (matching the kernel's split_page() function), and make use of it from host_s2_zalloc_pages_exact(). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: KVM: arm64: corrige el recuento de PGD de etapa 2 del host La librería de tablas de páginas de KVM vuelve a contar las páginas de los PGD de etapa 2 concatenados individualmente. Sin embargo, cuando se ejecuta KVM en modo protegido, EL2 administra actualmente el PGD de etapa 2 del host como una única página compuesta de alto orden, lo que puede causar que el recuento de las páginas finales llegue a 0 cuando no debería, corrompiendo así el tabla de páginas. Solucione este problema introduciendo un nuevo asistente hyp_split_page() en el asignador de páginas EL2 (que coincida con la función split_page() del kernel) y utilícelo desde host_s2_zalloc_pages_exact(). • https://git.kernel.org/stable/c/1025c8c0c6accfcbdc8f52ca1940160f65cd87d6 https://git.kernel.org/stable/c/b372264c66ef78f2cab44e877fbd765ad6d24c39 https://git.kernel.org/stable/c/1d58a17ef54599506d44c45ac95be27273a4d2b1 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47448 – mptcp: fix possible stall on recvmsg()
https://notcve.org/view.php?id=CVE-2021-47448
In the Linux kernel, the following vulnerability has been resolved: mptcp: fix possible stall on recvmsg() recvmsg() can enter an infinite loop if the caller provides the MSG_WAITALL, the data present in the receive queue is not sufficient to fulfill the request, and no more data is received by the peer. When the above happens, mptcp_wait_data() will always return with no wait, as the MPTCP_DATA_READY flag checked by such function is set and never cleared in such code path. Leveraging the above syzbot was able to trigger an RCU stall: rcu: INFO: rcu_preempt self-detected stall on CPU rcu: 0-...!: (10499 ticks this GP) idle=0af/1/0x4000000000000000 softirq=10678/10678 fqs=1 (t=10500 jiffies g=13089 q=109) rcu: rcu_preempt kthread starved for 10497 jiffies! g13089 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=1 rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior. rcu: RCU grace-period kthread stack dump: task:rcu_preempt state:R running task stack:28696 pid: 14 ppid: 2 flags:0x00004000 Call Trace: context_switch kernel/sched/core.c:4955 [inline] __schedule+0x940/0x26f0 kernel/sched/core.c:6236 schedule+0xd3/0x270 kernel/sched/core.c:6315 schedule_timeout+0x14a/0x2a0 kernel/time/timer.c:1881 rcu_gp_fqs_loop+0x186/0x810 kernel/rcu/tree.c:1955 rcu_gp_kthread+0x1de/0x320 kernel/rcu/tree.c:2128 kthread+0x405/0x4f0 kernel/kthread.c:327 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 rcu: Stack dump where RCU GP kthread last ran: Sending NMI from CPU 0 to CPUs 1: NMI backtrace for cpu 1 CPU: 1 PID: 8510 Comm: syz-executor827 Not tainted 5.15.0-rc2-next-20210920-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:bytes_is_nonzero mm/kasan/generic.c:84 [inline] RIP: 0010:memory_is_nonzero mm/kasan/generic.c:102 [inline] RIP: 0010:memory_is_poisoned_n mm/kasan/generic.c:128 [inline] RIP: 0010:memory_is_poisoned mm/kasan/generic.c:159 [inline] RIP: 0010:check_region_inline mm/kasan/generic.c:180 [inline] RIP: 0010:kasan_check_range+0xc8/0x180 mm/kasan/generic.c:189 Code: 38 00 74 ed 48 8d 50 08 eb 09 48 83 c0 01 48 39 d0 74 7a 80 38 00 74 f2 48 89 c2 b8 01 00 00 00 48 85 d2 75 56 5b 5d 41 5c c3 <48> 85 d2 74 5e 48 01 ea eb 09 48 83 c0 01 48 39 d0 74 50 80 38 00 RSP: 0018:ffffc9000cd676c8 EFLAGS: 00000283 RAX: ffffed100e9a110e RBX: ffffed100e9a110f RCX: ffffffff88ea062a RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff888074d08870 RBP: ffffed100e9a110e R08: 0000000000000001 R09: ffff888074d08877 R10: ffffed100e9a110e R11: 0000000000000000 R12: ffff888074d08000 R13: ffff888074d08000 R14: ffff888074d08088 R15: ffff888074d08000 FS: 0000555556d8e300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 S: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000180 CR3: 0000000068909000 CR4: 00000000001506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: instrument_atomic_read_write include/linux/instrumented.h:101 [inline] test_and_clear_bit include/asm-generic/bitops/instrumented-atomic.h:83 [inline] mptcp_release_cb+0x14a/0x210 net/mptcp/protocol.c:3016 release_sock+0xb4/0x1b0 net/core/sock.c:3204 mptcp_wait_data net/mptcp/protocol.c:1770 [inline] mptcp_recvmsg+0xfd1/0x27b0 net/mptcp/protocol.c:2080 inet6_recvmsg+0x11b/0x5e0 net/ipv6/af_inet6.c:659 sock_recvmsg_nosec net/socket.c:944 [inline] ____sys_recvmsg+0x527/0x600 net/socket.c:2626 ___sys_recvmsg+0x127/0x200 net/socket.c:2670 do_recvmmsg+0x24d/0x6d0 net/socket.c:2764 __sys_recvmmsg net/socket.c:2843 [inline] __do_sys_recvmmsg net/socket.c:2866 [inline] __se_sys_recvmmsg net/socket.c:2859 [inline] __x64_sys_recvmmsg+0x20b/0x260 net/socket.c:2859 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fc200d2 ---truncated--- En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: corrige posible bloqueo en recvmsg() recvmsg() puede entrar en un bucle infinito si la persona que llama proporciona MSG_WAITALL, los datos presentes en la cola de recepción no son suficientes para cumplir con la solicitud y el par no recibe más datos. Cuando sucede lo anterior, mptcp_wait_data() siempre regresará sin espera, ya que el indicador MPTCP_DATA_READY verificado por dicha función se establece y nunca se borra en dicha ruta de código. Aprovechar el syzbot anterior fue capaz de desencadenar una parada de RCU: rcu: INFO: rcu_preempt parada autodetectada en la CPU rcu: 0-...! • https://git.kernel.org/stable/c/7a6a6cbc3e592e339ad23e4e8ede9a3f6160bda8 https://git.kernel.org/stable/c/1a4554e94f0deff9fc1dc5addf93fa579cc29711 https://git.kernel.org/stable/c/612f71d7328c14369924384ad2170aae2a6abd92 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47447 – drm/msm/a3xx: fix error handling in a3xx_gpu_init()
https://notcve.org/view.php?id=CVE-2021-47447
In the Linux kernel, the following vulnerability has been resolved: drm/msm/a3xx: fix error handling in a3xx_gpu_init() These error paths returned 1 on failure, instead of a negative error code. This would lead to an Oops in the caller. A second problem is that the check for "if (ret != -ENODATA)" did not work because "ret" was set to 1. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/msm/a3xx: corrige el manejo de errores en a3xx_gpu_init() Estas rutas de error devolvieron 1 en caso de falla, en lugar de un código de error negativo. • https://git.kernel.org/stable/c/5785dd7a8ef0de8049f40a1a109de6a1bf17b479 https://git.kernel.org/stable/c/d59e44e7821a8f2bb6f2e846b9167397a5f01608 https://git.kernel.org/stable/c/3eda901995371d390ef82d0b6462f4ea8efbcfdf •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47446 – drm/msm/a4xx: fix error handling in a4xx_gpu_init()
https://notcve.org/view.php?id=CVE-2021-47446
In the Linux kernel, the following vulnerability has been resolved: drm/msm/a4xx: fix error handling in a4xx_gpu_init() This code returns 1 on error instead of a negative error. It leads to an Oops in the caller. A second problem is that the check for "if (ret != -ENODATA)" cannot be true because "ret" is set to 1. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/msm/a4xx: corrige el manejo de errores en a4xx_gpu_init() Este código devuelve 1 en caso de error en lugar de un error negativo. • https://git.kernel.org/stable/c/5785dd7a8ef0de8049f40a1a109de6a1bf17b479 https://git.kernel.org/stable/c/3962d626eb3e3b23ebb2e2a61537fa764acbfe11 https://git.kernel.org/stable/c/980d74e7d03ccf2eaa11d133416946bd880c7c08 •