From: akuster808 <akuster808@gmail.com>
To: Joshua G Lock <joshua.g.lock@linux.intel.com>,
akuster <akuster@mvista.com>,
openembedded-core@lists.openembedded.org
Subject: Re: [master][krogoth][PATCH 1/2] qemu: Security fix CVE-2016-2857
Date: Fri, 6 May 2016 08:47:10 -0700 [thread overview]
Message-ID: <572CBC7E.9080407@gmail.com> (raw)
In-Reply-To: <1462400231.6485.19.camel@linux.intel.com>
On 05/04/2016 03:17 PM, Joshua G Lock wrote:
> On Wed, 2016-05-04 at 07:16 -0700, akuster wrote:
>>
>> On 05/04/2016 02:52 AM, Joshua G Lock wrote:
>>>
>>> Hi Armin,
>>>
>>> On Thu, 2016-04-28 at 11:23 -0700, Armin Kuster wrote:
>>>>
>>>> From: Armin Kuster <akuster@mvista.com>
>>>>
>>> I've been seeing:
>>>
>>> "qemu: uncaught target signal 11 (Segmentation fault) - core
>>> dumped"
>>>
>>> when trying to build gobject-introspection for qemux86 recently and
>>> narrowed it down to this change, if I revert this patch the use of
>>> qemu-native by gobject-introspection no longer causes a
>>> segmentation
>>> fault.
>> well that is not good. To be clear, this is a build issue not an
>> execution issue? I would like to better understand what went wrong to
>> tighten up my processes.
>
> It's an execution issue for qemu-native, the segmentation error occurs
> when trying to build gobject-introspection (which calls qemu-native).
>
> I didn't try calling qemu-native any other way (runqemu, etc) to see
> whether it was something specific to the way gobject-introspection
> calls qemu.
>
I can not reproduce this issue. I have used two different build systems.
I have another I will try.
so the testcase be?
1) bitbake core-image-sato
2) runqemu qemux86
I am surprised the AB didn't catch this prior to release.
>>>
>>>
>>> Are we missing some related patches for this CVE fix?
>> The only commit identified for is the on this patch came from.
>>
>> I haven't dug
>>>
>>> into the details, but noticed that Fedora's CVE-2016-2857
>>> diffstat[1]
>>> is much larger than ours[2].
>> The Fedora change includes several other CVE fixes
>> +# CVE-2016-2538: Integer overflow in usb module (bz #1305815)
>> +Patch0103: 0103-usb-check-RNDIS-message-length.patch
>> +Patch0104: 0104-usb-check-RNDIS-buffer-offsets-length.patch
>> +# CVE-2016-2841: ne2000: infinite loop (bz #1304047)
>> +Patch0105: 0105-net-ne2000-check-ring-buffer-control-registers.patch
>> +# CVE-2016-2857: net: out of bounds read (bz #1309564)
>> +Patch0106: 0106-net-check-packet-payload-length.patch
>> +# CVE-2016-2392: usb: null pointer dereference (bz #1307115)
>> +Patch0107: 0107-usb-check-USB-configuration-descriptor-object.patch
>> +# Fix external snapshot any more after active committing (bz
>> #1300209)
>> +Patch0108: 0108-block-set-device_list.tqe_prev-to-NULL-on-BDS-
>> remova.patch
>>
>> which we seem to be missing some as well.
>
> Several (possibly all) of those are in the 2.5.1 upgrade I proposed.
There are over 50 commits in that release, some of them extend
functionality which is why I am a bit hesitant in upgrading Krogoth at
this time. Dot releases tend to be the cleaner method to loads for back
ports. I need to think about this a bit more.
Is anyone else seeing a problem?
- Armin
>
> Regards,
>
> Joshua
>
next prev parent reply other threads:[~2016-05-06 15:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-28 18:23 [master][krogoth][PATCH 1/2] qemu: Security fix CVE-2016-2857 Armin Kuster
2016-04-28 18:23 ` [master][krogoth][PATCH 2/2] qemu: Security fix CVE-2016-2858 Armin Kuster
2016-05-04 9:52 ` [master][krogoth][PATCH 1/2] qemu: Security fix CVE-2016-2857 Joshua G Lock
2016-05-04 9:58 ` Alexander Kanavin
2016-05-04 10:49 ` Joshua G Lock
[not found] ` <572A0450.10100@mvista.com>
2016-05-04 22:17 ` Joshua G Lock
2016-05-06 15:47 ` akuster808 [this message]
2016-05-06 15:51 ` Alexander Kanavin
2016-05-09 21:27 ` akuster808
2016-05-10 13:46 ` Joshua G Lock
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=572CBC7E.9080407@gmail.com \
--to=akuster808@gmail.com \
--cc=akuster@mvista.com \
--cc=joshua.g.lock@linux.intel.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox