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