[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87fsl0na5m.fsf@mpe.ellerman.id.au>
Date: Mon, 23 May 2022 14:30:13 +1000
From: Michael Ellerman <mpe@...erman.id.au>
To: Vaibhav Jain <vaibhav@...ux.ibm.com>, Rob Herring <robh@...nel.org>
Cc: devicetree@...r.kernel.org, Frank Rowand <frowand.list@...il.com>,
linux-kernel@...r.kernel.org,
Prakhar Srivastava <prsriva@...ux.microsoft.com>,
Lakshmi Ramasubramanian <nramas@...ux.microsoft.com>,
linuxppc-dev@...ts.ozlabs.org,
Thiago Jung Bauermann <bauerman@...ux.ibm.com>
Subject: Re: [PATCH] powerpc: check previous kernel's ima-kexec-buffer
against memory bounds
Vaibhav Jain <vaibhav@...ux.ibm.com> writes:
> Rob Herring <robh@...nel.org> writes:
>> On Thu, May 19, 2022 at 01:35:47AM +0530, Vaibhav Jain wrote:
>>> Presently ima_get_kexec_buffer() doesn't check if the previous kernel's
>>> ima-kexec-buffer lies outside the addressable memory range. This can result
>>> in a kernel panic if the new kernel is booted with 'mem=X' arg and the
>>> ima-kexec-buffer was allocated beyond that range by the previous kernel.
>>> The panic is usually of the form below:
>>>
>>> $ sudo kexec --initrd initrd vmlinux --append='mem=16G'
>>>
>>> <snip>
>>> BUG: Unable to handle kernel data access on read at 0xc000c01fff7f0000
>>> Faulting instruction address: 0xc000000000837974
>>> Oops: Kernel access of bad area, sig: 11 [#1]
>>> <snip>
>>> NIP [c000000000837974] ima_restore_measurement_list+0x94/0x6c0
>>> LR [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160
>>> Call Trace:
>>> [c00000000371fa80] [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160
>>> [c00000000371fb00] [c0000000020512c4] ima_init+0x80/0x108
>>> [c00000000371fb70] [c0000000020514dc] init_ima+0x4c/0x120
>>> [c00000000371fbf0] [c000000000012240] do_one_initcall+0x60/0x2c0
>>> [c00000000371fcc0] [c000000002004ad0] kernel_init_freeable+0x344/0x3ec
>>> [c00000000371fda0] [c0000000000128a4] kernel_init+0x34/0x1b0
>>> [c00000000371fe10] [c00000000000ce64] ret_from_kernel_thread+0x5c/0x64
>>> Instruction dump:
>>> f92100b8 f92100c0 90e10090 910100a0 4182050c 282a0017 3bc00000 40810330
>>> 7c0802a6 fb610198 7c9b2378 f80101d0 <a1240000> 2c090001 40820614 e9240010
>>> ---[ end trace 0000000000000000 ]---
>>>
>>> Fix this issue by checking returned address/size of previous kernel's
>>> ima-kexec-buffer against memblock's memory bounds.
>>>
>>> Fixes: fee3ff99bc67("powerpc: Move arch independent ima kexec functions to
>>> drivers/of/kexec.c")
...
>>
>> But more importantly, how did this commit introduce the problem? It just
>> moved the code and didn't have any such check.
> Yes, the code didnt have the necessary check to see if the address for
> previous kernel IMA buffer is beyond the currently addressable memory. I
> have described the problem in patch description.
Rob's point is that commit fee3ff99bc67 only moved existing code, the
bug already existed.
The function was introduced in:
467d27824920 ("powerpc: ima: get the kexec buffer passed by the previous kernel")
So that's where the Fixes tag should point.
cheers
Powered by blists - more mailing lists