Openembedded Core Discussions
 help / color / mirror / Atom feed
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
> 


  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