On 18 May 2017 at 17:41, Kees Cook wrote:
> On Thu, May 18, 2017 at 9:18 AM, Ard Biesheuvel
> wrote:
>> On 18 May 2017 at 14:01, Kees Cook wrote:
>>> On Thu, May 18, 2017 at 3:35 AM, Ard Biesheuvel
>>> wrote:
On 12 May 2017 at 22:58, Kees Cook wrote:
> During the internal pstore API r
On Thu, May 18, 2017 at 9:18 AM, Ard Biesheuvel
wrote:
> On 18 May 2017 at 14:01, Kees Cook wrote:
>> On Thu, May 18, 2017 at 3:35 AM, Ard Biesheuvel
>> wrote:
>>> On 12 May 2017 at 22:58, Kees Cook wrote:
During the internal pstore API refactoring, the EFI vars read entry was
acciden
On 18 May 2017 at 14:01, Kees Cook wrote:
> On Thu, May 18, 2017 at 3:35 AM, Ard Biesheuvel
> wrote:
>> On 12 May 2017 at 22:58, Kees Cook wrote:
>>> During the internal pstore API refactoring, the EFI vars read entry was
>>> accidentally made to update a stack variable instead of the pstore
>>>
On Thu, May 18, 2017 at 3:35 AM, Ard Biesheuvel
wrote:
> On 12 May 2017 at 22:58, Kees Cook wrote:
>> During the internal pstore API refactoring, the EFI vars read entry was
>> accidentally made to update a stack variable instead of the pstore
>> private data pointer. This corrects the problem (a
On 12 May 2017 at 22:58, Kees Cook wrote:
> During the internal pstore API refactoring, the EFI vars read entry was
> accidentally made to update a stack variable instead of the pstore
> private data pointer. This corrects the problem (and removes the now
> needless argument).
>
> Signed-off-by: K
During the internal pstore API refactoring, the EFI vars read entry was
accidentally made to update a stack variable instead of the pstore
private data pointer. This corrects the problem (and removes the now
needless argument).
Signed-off-by: Kees Cook
---
drivers/firmware/efi/efi-pstore.c | 26
6 matches
Mail list logo
