NAK: [PATCH 0/1][SRU][T/X/B/C] CVE-2019-9213 - Incorrect memory protection check

Tyler Hicks tyhicks at canonical.com
Thu Mar 7 03:26:07 UTC 2019


On 2019-03-07 11:11:30, You-Sheng Yang wrote:
> This patch doesn't apply on current trusty master-next HEAD
> 6a34acb7c2f8, and does apply on X/B/C.

A cherry-pick works just fine on trusty master-next which is why I
sent a single patch for all kernels:

$ git cherry-pick 0a1d52994d440e21def1c2174932410b4f2a98a1
[cves 9a5be15dfbfd] mm: enforce min addr even if capable() in expand_downwards()
 Author: Jann Horn <jannh at google.com>
 Date: Wed Feb 27 21:29:52 2019 +0100
 1 file changed, 3 insertions(+), 4 deletions(-)

I guess cherry-pick is including some merge logic to fix up fuzz.

Do I need to resend a patch for Trusty or would the stable team rather
just do a git cherry-pick?

Tyler

> On 2019/3/7 10:36 AM, Tyler Hicks wrote:
> > https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2019-9213.html
> > 
> >  In the Linux kernel before 4.20.14, expand_downwards in mm/mmap.c lacks a
> >  check for the mmap minimum address, which makes it easier for attackers to
> >  exploit kernel NULL pointer dereferences on non-SMAP platforms. This is
> >  related to a capability check for the wrong task.
> > 
> > Clean cherry pick. Clean build logs. Verified the fix in Cosmic through Trusty
> > with the PoC in the Project Zero bug report[1].
> > 
> > Tyler
> > 
> > [1] https://bugs.chromium.org/p/project-zero/issues/detail?id=1792&desc=2
> > 
> > Jann Horn (1):
> >   mm: enforce min addr even if capable() in expand_downwards()
> > 
> >  mm/mmap.c | 7 +++----
> >  1 file changed, 3 insertions(+), 4 deletions(-)
> > 
> 






More information about the kernel-team mailing list