CVE-2021-47274

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Correct the length check which causes memory corruption<br /> <br /> We&amp;#39;ve suffered from severe kernel crashes due to memory corruption on<br /> our production environment, like,<br /> <br /> Call Trace:<br /> [1640542.554277] general protection fault: 0000 [#1] SMP PTI<br /> [1640542.554856] CPU: 17 PID: 26996 Comm: python Kdump: loaded Tainted:G<br /> [1640542.556629] RIP: 0010:kmem_cache_alloc+0x90/0x190<br /> [1640542.559074] RSP: 0018:ffffb16faa597df8 EFLAGS: 00010286<br /> [1640542.559587] RAX: 0000000000000000 RBX: 0000000000400200 RCX:<br /> 0000000006e931bf<br /> [1640542.560323] RDX: 0000000006e931be RSI: 0000000000400200 RDI:<br /> ffff9a45ff004300<br /> [1640542.560996] RBP: 0000000000400200 R08: 0000000000023420 R09:<br /> 0000000000000000<br /> [1640542.561670] R10: 0000000000000000 R11: 0000000000000000 R12:<br /> ffffffff9a20608d<br /> [1640542.562366] R13: ffff9a45ff004300 R14: ffff9a45ff004300 R15:<br /> 696c662f65636976<br /> [1640542.563128] FS: 00007f45d7c6f740(0000) GS:ffff9a45ff840000(0000)<br /> knlGS:0000000000000000<br /> [1640542.563937] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [1640542.564557] CR2: 00007f45d71311a0 CR3: 000000189d63e004 CR4:<br /> 00000000003606e0<br /> [1640542.565279] DR0: 0000000000000000 DR1: 0000000000000000 DR2:<br /> 0000000000000000<br /> [1640542.566069] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:<br /> 0000000000000400<br /> [1640542.566742] Call Trace:<br /> [1640542.567009] anon_vma_clone+0x5d/0x170<br /> [1640542.567417] __split_vma+0x91/0x1a0<br /> [1640542.567777] do_munmap+0x2c6/0x320<br /> [1640542.568128] vm_munmap+0x54/0x70<br /> [1640542.569990] __x64_sys_munmap+0x22/0x30<br /> [1640542.572005] do_syscall_64+0x5b/0x1b0<br /> [1640542.573724] entry_SYSCALL_64_after_hwframe+0x44/0xa9<br /> [1640542.575642] RIP: 0033:0x7f45d6e61e27<br /> <br /> James Wang has reproduced it stably on the latest 4.19 LTS.<br /> After some debugging, we finally proved that it&amp;#39;s due to ftrace<br /> buffer out-of-bound access using a debug tool as follows:<br /> [ 86.775200] BUG: Out-of-bounds write at addr 0xffff88aefe8b7000<br /> [ 86.780806] no_context+0xdf/0x3c0<br /> [ 86.784327] __do_page_fault+0x252/0x470<br /> [ 86.788367] do_page_fault+0x32/0x140<br /> [ 86.792145] page_fault+0x1e/0x30<br /> [ 86.795576] strncpy_from_unsafe+0x66/0xb0<br /> [ 86.799789] fetch_memory_string+0x25/0x40<br /> [ 86.804002] fetch_deref_string+0x51/0x60<br /> [ 86.808134] kprobe_trace_func+0x32d/0x3a0<br /> [ 86.812347] kprobe_dispatcher+0x45/0x50<br /> [ 86.816385] kprobe_ftrace_handler+0x90/0xf0<br /> [ 86.820779] ftrace_ops_assist_func+0xa1/0x140<br /> [ 86.825340] 0xffffffffc00750bf<br /> [ 86.828603] do_sys_open+0x5/0x1f0<br /> [ 86.832124] do_syscall_64+0x5b/0x1b0<br /> [ 86.835900] entry_SYSCALL_64_after_hwframe+0x44/0xa9<br /> <br /> commit b220c049d519 ("tracing: Check length before giving out<br /> the filter buffer") adds length check to protect trace data<br /> overflow introduced in 0fc1b09ff1ff, seems that this fix can&amp;#39;t prevent<br /> overflow entirely, the length check should also take the sizeof<br /> entry-&gt;array[0] into account, since this array[0] is filled the<br /> length of trace data and occupy addtional space and risk overflow.