[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-stable] CVE-2018-7550 (was: multiboot: bss_end_addr can be zer
From: |
Konrad Rzeszutek Wilk |
Subject: |
Re: [Qemu-stable] CVE-2018-7550 (was: multiboot: bss_end_addr can be zero / cleanup) |
Date: |
Wed, 14 Mar 2018 13:35:33 -0400 |
User-agent: |
K-9 Mail for Android |
On March 14, 2018 1:23:51 PM EDT, Kevin Wolf <address@hidden> wrote:
>Am 21.12.2017 um 18:25 hat Jack Schwartz geschrieben:
>> Properly account for the possibility of multiboot kernels with a zero
>> bss_end_addr. The Multiboot Specification, section 3.1.3 allows for
>> kernels without a bss section, by allowing a zeroed bss_end_addr
>multiboot
>> header field.
>>
>> Do some cleanup to multiboot.c as well:
>> - Remove some unused variables.
>> - Use more intuitive header names when displaying fields in messages.
>> - Change fprintf(stderr...) to error_report
>
>[ Cc: qemu-stable ]
>
>This series happens to fix CVE-2018-7550.
>http://www.openwall.com/lists/oss-security/2018/03/08/4
>
>Just a shame that we weren't told before merging it so that the
>appropriate tags could have been set in the commit message (and all of
>the problems could have been addressed; I'm going to send another
>Multiboot series now).
Huh?
You mean the CVE tags that were created in 2018 for a patch posted in 2017?
Or that the reporter of the security issue didn't point to this particular
patch?
Irrespective of that, is there a write-up of how security process works at
QEMU?
That is what is the usual embargo period, the list of security folks, how one
can become one, what are the responsibilities, how changes to process are being
carried out (and discussed), what breath of testing and PoC work is done , how
security fixes are being reviewed, etc?
Thanks!
>
>Kevin