Re: CVE-2018-1130: Linux kernel: dccp: a null pointer dereference in net/dccp/output.c:dccp_write_xmit

[Kurt Seifried <kseifried () redhat com>]

On Fri, May 25, 2018 at 4:48 AM, Andrey Konovalov <andreyknvl () gmail com>
wrote:

> On Wed, May 23, 2018 at 4:57 PM, Kurt Seifried <kseifried () redhat com>
> wrote:
> > On Wed, May 23, 2018 at 8:49 AM, Andrey Konovalov <andreyknvl () gmail com>
> > wrote:
> >
> > > On Thu, May 10, 2018 at 2:05 PM, Vladis Dronov <vdronov () redhat com>
> wrote:
> > > > Hello,
> > > >
> > > > A null pointer dereference in dccp_write_xmit() function in
> > > net/dccp/output.c
> > > > in the Linux kernel before v4.16-rc7 allows a local user to cause a
> > > denial of
> > > > service by a number of certain crafted system calls.
> >
> >
> > So the classic CVE statement for this is "does it cross/violate a trust
> > boundary". Yeah I know, not super helpful.
> >
> > In general when I look at something and need to decide whether or not it
> > deserves/needs a CVE the fundamentals are:
> >
> > 1) Can an attacker use this vulnerability to gain access, additional
> > privileges, basically is there an impact to
> > Confidentiality/Availability/Integrity? This is really two tests: is
> there
> > an impact, and is there a way for the attacker to trigger or exploit it?
> > That's a CVE.
> >
> > 2) Does the software/system make a specific security claim that they then
> > fail to meet? E.g. "we include a firewall that blocks access to
> everything
> > inbound except for port 22", if they were to then also allow port 80,
> > that'd be a CVE.
> >
> > So for the syzbot stuff mostly what you need to determine is:
> >
> > a) is there a security related impact?
> > AND
> > b) can an attacker trigger it?
> >
> > If both are yes, then a CVE is warranted.
>
> Hi Kurt,
>
> Perhaps I should've been more clear. I wasn't asking "what qualifies
> for a CVE?", but rather "There are a 100 bugs that qualify for CVEs,
> how do single out 10 of them to actually request CVEs for?".

So if a security vulnerability qualifies for CVE INCLUSION (see
https://cve.mitre.org/cve/editorial_policies/counting_rules.html) the next
step is to SPLIT and MERGE the vulns as needed. Esentially what we want is
to end up with buckets where each bucket of vulnerability(s) is:

1) unique to a specific code base
2) unique to a specific version(s)(*)
3) the same root cause (this is where you have to do homework)

* Note: the version thing, obviously the affected versions/commits for
these will be different in the Linux kernel and so by this rule, strictly
speaking each vuln would get it's own CVE, but in general if they all
affect the same broad version of the Linux Kernel they can be bucketed
together.

So assuming the homework is done of properly identifying and classifying
these security vulnerabilities then you can simply request CVE's for all of
them, the worst ones, or whatever you want. I would of course prefer that
all of them be identified/tracked but that's just me.


> In particular, the 100 bugs that I'm referring to are the bugs
> reported by syzbot (perhaps there's even more:
> https://syzkaller.appspot.com/?fixed=upstream) and the 10 bugs (or so)
> are the ones Vladis announced on oss-security over the last few
> months. I'm just curious how did he choose those 10 bugs out of that
> 100+.

You'd have to ask him.


> Thanks!



-- 

Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secalert () redhat com