CVE-2022-50674

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: vdso: fix NULL deference in vdso_join_timens() when vfork<br /> <br /> Testing tools/testing/selftests/timens/vfork_exec.c got below<br /> kernel log:<br /> <br /> [ 6.838454] Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000000020<br /> [ 6.842255] Oops [#1]<br /> [ 6.842871] Modules linked in:<br /> [ 6.844249] CPU: 1 PID: 64 Comm: vfork_exec Not tainted 6.0.0-rc3-rt15+ #8<br /> [ 6.845861] Hardware name: riscv-virtio,qemu (DT)<br /> [ 6.848009] epc : vdso_join_timens+0xd2/0x110<br /> [ 6.850097] ra : vdso_join_timens+0xd2/0x110<br /> [ 6.851164] epc : ffffffff8000635c ra : ffffffff8000635c sp : ff6000000181fbf0<br /> [ 6.852562] gp : ffffffff80cff648 tp : ff60000000fdb700 t0 : 3030303030303030<br /> [ 6.853852] t1 : 0000000000000030 t2 : 3030303030303030 s0 : ff6000000181fc40<br /> [ 6.854984] s1 : ff60000001e6c000 a0 : 0000000000000010 a1 : ffffffff8005654c<br /> [ 6.856221] a2 : 00000000ffffefff a3 : 0000000000000000 a4 : 0000000000000000<br /> [ 6.858114] a5 : 0000000000000000 a6 : 0000000000000008 a7 : 0000000000000038<br /> [ 6.859484] s2 : ff60000001e6c068 s3 : ff6000000108abb0 s4 : 0000000000000000<br /> [ 6.860751] s5 : 0000000000001000 s6 : ffffffff8089dc40 s7 : ffffffff8089dc38<br /> [ 6.862029] s8 : ffffffff8089dc30 s9 : ff60000000fdbe38 s10: 000000000000005e<br /> [ 6.863304] s11: ffffffff80cc3510 t3 : ffffffff80d1112f t4 : ffffffff80d1112f<br /> [ 6.864565] t5 : ffffffff80d11130 t6 : ff6000000181fa00<br /> [ 6.865561] status: 0000000000000120 badaddr: 0000000000000020 cause: 000000000000000d<br /> [ 6.868046] [] timens_commit+0x38/0x11a<br /> [ 6.869089] [] timens_on_fork+0x72/0xb4<br /> [ 6.870055] [] begin_new_exec+0x3c6/0x9f0<br /> [ 6.871231] [] load_elf_binary+0x628/0x1214<br /> [ 6.872304] [] bprm_execve+0x1f2/0x4e4<br /> [ 6.873243] [] do_execveat_common+0x16e/0x1ee<br /> [ 6.874258] [] sys_execve+0x3c/0x48<br /> [ 6.875162] [] ret_from_syscall+0x0/0x2<br /> [ 6.877484] ---[ end trace 0000000000000000 ]---<br /> <br /> This is because the mm-&gt;context.vdso_info is NULL in vfork case. From<br /> another side, mm-&gt;context.vdso_info either points to vdso info<br /> for RV64 or vdso info for compat, there&amp;#39;s no need to bloat riscv&amp;#39;s<br /> mm_context_t, we can handle the difference when setup the additional<br /> page for vdso.