Wind River Support Network

Description

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

CVEs

• CVE-2022-50579