Hi,
Any thoughts on the proposal I made? The bugs libFuzzer has helped find
recently makes a compelling case to integrate OvS with oss-fuzz.
Regards,
Bhargava
On 09/01/2017 05:31 PM, Bhargava Shastry wrote:
> Dear all,
>
> I suppose the following are the agenda points for adding OvS to OSS-Fuzz
Update on the conntrack test case: It turns out AddressSanitizer doesn't
work well with multithreaded applications. I noticed that
conntrack_init() creates a thread in each iteration. Is there a
workaround for this perhaps not using pthread*()?
Regards,
Bhargava
On 09/01/2017 03:16 PM, Bhargava S
Dear all,
I suppose the following are the agenda points for adding OvS to OSS-Fuzz.
1. [Easy] Write Docker file for getting OvS to build. Feel this should
be easy as I don't see any non-default dependencies
2. [Easy] Add a project.yaml that documents project metadata such as
contact persons, pro
Here's another test harness for connection tracking code. This is over
30x slower than the other two test cases (speed=2700 exec/s vs 85000
exec/s for the other two test cases). Just to clarify, I am not testing
on trunk (as I incorrectly claimed earlier). Rather, I am testing the
latest release v2
Here is another test harness for fuzzing Openflow packet parsing on
trunk. Feedback welcome!
= target-ofp.c =
#include "flow.h"
#include "dp-packet.h"
#include "pcap-file.h"
#include "odp-util.h"
static bool
is_openflow_port(ovs_be16 port_)
{
uint16_t port = ntohs(port_);
return
I would also like to point out that the wireshark corpus will make
testing more efficient. I am currently using a corpus from here [1] and
it covers code more quickly. Please bear in mind that this particular
payload corpus contains the packet payload (hence suitable for our
testcases) but is limit
This is a nice test case for upstream. Am currently running on 8 cores,
no crashes in the flow_extract API so far.
Regards,
Bhargava
On 08/31/2017 11:03 PM, Ben Pfaff wrote:
> int LLVMFuzzerTestOneInput(const uint8_t* data, size_t size)
> {
> struct dp_packet packet;
> dp_packet_use_const
With this fuzz target on v2.3.2 fuzzing finds CVE-2016-2074 in just a few
seconds starting from an empty corpus:
mkdir C; ./openvswitch-2.3.2-libfuzzer C -jobs=20
==34306==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7ffcfbfddce8 at pc 0x0050e2b8 bp 0x7ffcfbfdd990 sp 0x7ffcfbf
For the version Bhargava is testing I guess this reads as
int LLVMFuzzerTestOneInput(const uint8_t* data, size_t size)
{
struct ofpbuf packet;
ofpbuf_use_const(&packet, data, size);
struct flow flow;
flow_extract(&packet, NULL, &flow);
return 0;
}
Looks great, and runs fast.
On Thu,
Hi,
> I didn't look at the actual code before, but now that I have, I don't
> understand at all why it was doing file I/O just to write a packet to
> disk and then read it back.
Sorry, this was due to my ignorance. I was not aware of something like
dp_packet_use_const(). This should speed things
On Thu, Aug 31, 2017 at 12:46:50PM -0700, Kostya Serebryany wrote:
> On Thu, Aug 31, 2017 at 12:41 PM, Ben Pfaff wrote:
>
> > What's the issue with file I/O? If you can help me understand why you
> > want to get rid of it, maybe I can suggest what to do instead.
> >
>
> The file IO takes more t
On Thu, Aug 31, 2017 at 12:46 PM, Kostya Serebryany wrote:
>
>
> On Thu, Aug 31, 2017 at 12:41 PM, Ben Pfaff wrote:
>
>> What's the issue with file I/O? If you can help me understand why you
>> want to get rid of it, maybe I can suggest what to do instead.
>>
>
> The file IO takes more time tha
On Thu, Aug 31, 2017 at 12:41 PM, Ben Pfaff wrote:
> What's the issue with file I/O? If you can help me understand why you
> want to get rid of it, maybe I can suggest what to do instead.
>
The file IO takes more time than direct access to memory.
Even if the actual IO happens on tmpfs, this is
What's the issue with file I/O? If you can help me understand why you
want to get rid of it, maybe I can suggest what to do instead.
On Thu, Aug 31, 2017 at 09:24:29PM +0200, Bhargava Shastry wrote:
> An update from my side. I have written a small test case for catching
> CVE-2016-2074 here [1].
On Thu, Aug 31, 2017 at 12:24 PM, Bhargava Shastry <
bshas...@sec.t-labs.tu-berlin.de> wrote:
> Dear dev@OVS, KCC@google,
>
> Konstantin Serebryany (KCC) in CC is part of the OSS-Fuzz project that I
> mentioned before. I think he will be happy to see openvswitch use
> OSS-Fuzz services.
>
Yes, op
Dear dev@OVS, KCC@google,
Konstantin Serebryany (KCC) in CC is part of the OSS-Fuzz project that I
mentioned before. I think he will be happy to see openvswitch use
OSS-Fuzz services.
An update from my side. I have written a small test case for catching
CVE-2016-2074 here [1]. KCC strongly encour
I also support this idea. Thanks!
On Wed, Aug 16, 2017 at 07:55:51PM -0700, Bhargava Shastry wrote:
> Hi Justin,
>
> Nice to hear. I have CC ed Dev ml.
>
> Regards
> Bhargava
>
>
> On August 16, 2017 5:18:58 PM PDT, Justin Pettit wrote:
> >Hi, Bhargava. This seems like a great idea to me.
Hi Justin,
Nice to hear. I have CC ed Dev ml.
Regards
Bhargava
On August 16, 2017 5:18:58 PM PDT, Justin Pettit wrote:
>Hi, Bhargava. This seems like a great idea to me. Unless there's
>something sensitive, I'd suggest we discuss it on the
>d...@openvswitch.org mailing list. The security ma
18 matches
Mail list logo
