CVE-2022-50674

In the Linux kernel, the following vulnerability has been resolved:

riscv: vdso: fix NULL deference in vdsojointimens() when vfork

Testing tools/testing/selftests/timens/vfork_exec.c got below kernel log:

[ 6.838454] Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000000020 [ 6.842255] Oops [#1] [ 6.842871] Modules linked in: [ 6.844249] CPU: 1 PID: 64 Comm: vforkexec Not tainted 6.0.0-rc3-rt15+ #8 [ 6.845861] Hardware name: riscv-virtio,qemu (DT) [ 6.848009] epc : vdsojointimens+0xd2/0x110 [ 6.850097] ra : vdsojointimens+0xd2/0x110 [ 6.851164] epc : ffffffff8000635c ra : ffffffff8000635c sp : ff6000000181fbf0 [ 6.852562] gp : ffffffff80cff648 tp : ff60000000fdb700 t0 : 3030303030303030 [ 6.853852] t1 : 0000000000000030 t2 : 3030303030303030 s0 : ff6000000181fc40 [ 6.854984] s1 : ff60000001e6c000 a0 : 0000000000000010 a1 : ffffffff8005654c [ 6.856221] a2 : 00000000ffffefff a3 : 0000000000000000 a4 : 0000000000000000 [ 6.858114] a5 : 0000000000000000 a6 : 0000000000000008 a7 : 0000000000000038 [ 6.859484] s2 : ff60000001e6c068 s3 : ff6000000108abb0 s4 : 0000000000000000 [ 6.860751] s5 : 0000000000001000 s6 : ffffffff8089dc40 s7 : ffffffff8089dc38 [ 6.862029] s8 : ffffffff8089dc30 s9 : ff60000000fdbe38 s10: 000000000000005e [ 6.863304] s11: ffffffff80cc3510 t3 : ffffffff80d1112f t4 : ffffffff80d1112f [ 6.864565] t5 : ffffffff80d11130 t6 : ff6000000181fa00 [ 6.865561] status: 0000000000000120 badaddr: 0000000000000020 cause: 000000000000000d [ 6.868046] [<ffffffff8008dc94>] timenscommit+0x38/0x11a [ 6.869089] [<ffffffff8008dde8>] timensonfork+0x72/0xb4 [ 6.870055] [<ffffffff80190096>] beginnewexec+0x3c6/0x9f0 [ 6.871231] [<ffffffff801d826c>] loadelfbinary+0x628/0x1214 [ 6.872304] [<ffffffff8018ee7a>] bprmexecve+0x1f2/0x4e4 [ 6.873243] [<ffffffff8018f90c>] doexecveatcommon+0x16e/0x1ee [ 6.874258] [<ffffffff8018f9c8>] sysexecve+0x3c/0x48 [ 6.875162] [<ffffffff80003556>] retfromsyscall+0x0/0x2 [ 6.877484] ---[ end trace 0000000000000000 ]---

This is because the mm->context.vdsoinfo is NULL in vfork case. From another side, mm->context.vdsoinfo either points to vdso info for RV64 or vdso info for compat, there's no need to bloat riscv's mmcontextt, we can handle the difference when setup the additional page for vdso.