CVE-2022-50674 in Linux
Résumé
par VulDB • 07/06/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
riscv: vdso: correction d'une déréférencement NULL dans vdso_join_timens() lors de l'appel vfork
L'outil de test tools/testing/selftests/timens/vfork_exec.c a généré le journal noyau suivant :
[ 6.838454] Impossible de gérer l'accès du noyau à la mémoire utilisateur sans les routines uaccess à l'adresse virtuelle 0000000000000020
[ 6.842255] Oops [#1]
[ 6.842871] Modules liés :
[ 6.844249] CPU : 1 PID : 64 Comm : vfork_exec Non modifié 6.0.0-rc3-rt15+ #8
[ 6.845861] Matériel : riscv-virtio,qemu (DT)
[ 6.848009] epc : vdso_join_timens+0xd2/0x110
[ 6.850097] ra : vdso_join_timens+0xd2/0x110
[ 6.851283] sp : ff6000000181f9a0 mepc : ff60000000001000
[ 6.852509] mcause: 000000000000000d
[ 6.853433] s0 : ff6000000181fa00 s1 : ff60000000fdbe38
[ 6.854709] s2 : ff60000000fdbe38 s3 : ff60000000fdbe38 s4 : ff60000000fdbe38
[ 6.856009] s5 : 0000000000001000 s6 : ffffffff8089dc40 s7 : ffffffff8089dc38
[ 6.857284] s8 : ffffffff8089dc30 s9 : ff60000000fdbe38 s10: 000000000000005e
[ 6.858559] s11: ffffffff80cc3510 t3 : ffffffff80d1112f t4 : ffffffff80d1112f
[ 6.859819] t5 : ffffffff80d11130 t6 : ff6000000181fa00
[ 6.860815] status: 0000000000000120 badaddr: 0000000000000020 cause: 000000000000000d
[ 6.863350] [<ffffffff8008dc94>] timens_commit+0x38/0x11a
[ 6.864473] [<ffffffff8008dde8>] timens_on_fork+0x72/0xb4
[ 6.865539] [<ffffffff80190096>] begin_new_exec+0x3c6/0x9f0
[ 6.866715] [<ffffffff801d826c>] load_elf_binary+0x628/0x1214
[ 6.867838] [<ffffffff8018ee7a>] bprm_execve+0x1f2/0x4e4
[ 6.868777] [<ffffffff8018f90c>] do_execveat_common+0x16e/0x1ee
[ 6.869842] [<ffffffff8018f9c8>] sys_execve+0x3c/0x48
[ 6.870776] [<ffffffff80003556>] ret_from_syscall+0x0/0x2
[ 6.873084] ---[ end trace 0000000000000000 ]---
Cela est dû au fait que mm->context.vdso_info est NULL dans le cas de vfork. D'un autre côté, mm->context.vdso_info pointe soit vers les informations vdso pour RV64, soit vers les informations vdso pour compat, il n'est donc pas nécessaire d'alourdir mm_context_t de riscv, nous pouvons gérer la différence lors de la configuration de la page supplémentaire pour vdso.
Once again VulDB remains the best source for vulnerability data.