CVE-2022-50579

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: ftrace: fix module PLTs with mcount<br /> <br /> Li Huafei reports that mcount-based ftrace with module PLTs was broken<br /> by commit:<br /> <br /> a6253579977e4c6f ("arm64: ftrace: consistently handle PLTs.")<br /> <br /> When a module PLTs are used and a module is loaded sufficiently far away<br /> from the kernel, we&amp;#39;ll create PLTs for any branches which are<br /> out-of-range. These are separate from the special ftrace trampoline<br /> PLTs, which the module PLT code doesn&amp;#39;t directly manipulate.<br /> <br /> When mcount is in use this is a problem, as each mcount callsite in a<br /> module will be initialized to point to a module PLT, but since commit<br /> a6253579977e4c6f ftrace_make_nop() will assume that the callsite has<br /> been initialized to point to the special ftrace trampoline PLT, and<br /> ftrace_find_callable_addr() rejects other cases.<br /> <br /> This means that when ftrace tries to initialize a callsite via<br /> ftrace_make_nop(), the call to ftrace_find_callable_addr() will find<br /> that the `_mcount` stub is out-of-range and is not handled by the ftrace<br /> PLT, resulting in a splat:<br /> <br /> | ftrace_test: loading out-of-tree module taints kernel.<br /> | ftrace: no module PLT for _mcount<br /> | ------------[ ftrace bug ]------------<br /> | ftrace failed to modify<br /> | [] 0xffff800029180014<br /> | actual: 44:00:00:94<br /> | Initializing ftrace call sites<br /> | ftrace record flags: 2000000<br /> | (0)<br /> | expected tramp: ffff80000802eb3c<br /> | ------------[ cut here ]------------<br /> | WARNING: CPU: 3 PID: 157 at kernel/trace/ftrace.c:2120 ftrace_bug+0x94/0x270<br /> | Modules linked in:<br /> | CPU: 3 PID: 157 Comm: insmod Tainted: G O 6.0.0-rc6-00151-gcd722513a189-dirty #22<br /> | Hardware name: linux,dummy-virt (DT)<br /> | pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> | pc : ftrace_bug+0x94/0x270<br /> | lr : ftrace_bug+0x21c/0x270<br /> | sp : ffff80000b2bbaf0<br /> | x29: ffff80000b2bbaf0 x28: 0000000000000000 x27: ffff0000c4d38000<br /> | x26: 0000000000000001 x25: ffff800009d7e000 x24: ffff0000c4d86e00<br /> | x23: 0000000002000000 x22: ffff80000a62b000 x21: ffff8000098ebea8<br /> | x20: ffff0000c4d38000 x19: ffff80000aa24158 x18: ffffffffffffffff<br /> | x17: 0000000000000000 x16: 0a0d2d2d2d2d2d2d x15: ffff800009aa9118<br /> | x14: 0000000000000000 x13: 6333626532303830 x12: 3030303866666666<br /> | x11: 203a706d61727420 x10: 6465746365707865 x9 : 3362653230383030<br /> | x8 : c0000000ffffefff x7 : 0000000000017fe8 x6 : 000000000000bff4<br /> | x5 : 0000000000057fa8 x4 : 0000000000000000 x3 : 0000000000000001<br /> | x2 : ad2cb14bb5438900 x1 : 0000000000000000 x0 : 0000000000000022<br /> | Call trace:<br /> | ftrace_bug+0x94/0x270<br /> | ftrace_process_locs+0x308/0x430<br /> | ftrace_module_init+0x44/0x60<br /> | load_module+0x15b4/0x1ce8<br /> | __do_sys_init_module+0x1ec/0x238<br /> | __arm64_sys_init_module+0x24/0x30<br /> | invoke_syscall+0x54/0x118<br /> | el0_svc_common.constprop.4+0x84/0x100<br /> | do_el0_svc+0x3c/0xd0<br /> | el0_svc+0x1c/0x50<br /> | el0t_64_sync_handler+0x90/0xb8<br /> | el0t_64_sync+0x15c/0x160<br /> | ---[ end trace 0000000000000000 ]---<br /> | ---------test_init-----------<br /> <br /> Fix this by reverting to the old behaviour of ignoring the old<br /> instruction when initialising an mcount callsite in a module, which was<br /> the behaviour prior to commit a6253579977e4c6f.