[T/X][CVE-2017-15127] CVE-2017-15127 (false-positive?)

Andy Whitcroft apw at canonical.com
Thu May 24 09:36:04 UTC 2018


On Wed, May 23, 2018 at 03:36:07PM +0200, Stefan Bader wrote:
> On 16.05.2018 06:40, Khalid Elmously wrote:
> > CVE-2017-15127
> > 
> > I think this may be a false-positive.
> 
> Agreeing with the false positive. But this is not fixed by applying empty
> patches but by fixing the triaging hints.
> 
> If you look at the breaks-fix links, you notice that the breaks link is pointing
> to the first commit in git. The web view actually is a translation from the cve
> tracker statement:
> 
> Patches_linux:
>  break-fix: - 5af10dfd0afc559bb4b0f7e3e8227a1578333995
> 
> which means whoever triaged this did not really know what introduced the issue
> and left a wildcard there. I think you were on the right track about the
> functionality but I think below is the one introducing the problem:
> 
> commit 1c9e8def43a3452e7af658b340f5f4f4ecde5c38
> Author: Mike Kravetz <mike.kravetz at oracle.com>
> Date:   Wed Feb 22 15:43:43 2017 -0800
> 
>     userfaultfd: hugetlbfs: add UFFDIO_COPY support for shared mappings
> 
> This one adds the additional unlock, after the nounlock label. So the right
> thing to do is to update the tracker with this sha1 as the introducing commit.

Agree that this looks to be the introducing commit.  Updated the break
commit as suggested, we shall see what the autotriager makes of this:

    break-fix: 1c9e8def43a3452e7af658b340f5f4f4ecde5c38 5af10dfd0afc559bb4b0f7e3e8227a1578333995

-apw




More information about the kernel-team mailing list