Per http://seclists.org/oss-sec/2018/q3/76 quoted for convenience below.

TL;DR: Arbitrary kernel memory read primitive in kernels 3.10 - 4.15 when CONFIG_POSIX_TIMERS and CONFIG_CHECKPOINT_RESTORE is enabled. Requires native code execution to access. Chrome OS doesn't enable CONFIG_CHECKPOINT_RESTORE AFAICT, but lakitu does. Given that, setting Impact-None for now, but feel free to adjust for what is appropriate for lakitu.

We should probably pick up the patch in our kernels where it applies (fix referenced below).


Here's the announcement from oss-sec:

Hi!

Syzkaller/syzbot found a global-out-of-bounds bug in the timer
subsystem of the Linux kernel [1], that is exploitable and can be used
to gain an arbitrary-read primitive. This allows to access kernel
memory and leak keys, credentials or other sensitive information that
is stored there (so the bug has a similar impact to Meltdown). I'll
share a PoC exploit in a week.

The bug was introduced in commit 57b8015e ("posix-timers: Show
sigevent info in proc file") [2] in 3.10 and fixed by commit cef31d9a
("posix-timer: Properly check sigevent->sigev_notify") [3] in
4.15-rc4. The bug only affects kernels that have CONFIG_POSIX_TIMERS
and CONFIG_CHECKPOINT_RESTORE enabled, which is done by a lot of
modern distros.

This bug has been fixed in Ubuntu 16.04 [7], but still affects at
least CentOS 7 at this moment (at least 3.10.0-862.9.1.el7.x86_64 that
I've checked). I haven't checked the other distros.

I've contacted linux-distros@ today and was asked to post to
oss-security@ right away, since the issue is already public (and has
been for the last 8 months, see the timeline below).

======

Description from MITRE [4]:

The timer_create syscall implementation in kernel/time/posix-timers.c
in the Linux kernel before 4.14.8 doesn't properly validate the
sigevent->sigev_notify field, which leads to out-of-bounds access in
the show_timer function (called when /proc/$PID/timers is read). This
allows userspace applications to read arbitrary kernel memory (on a
kernel built with CONFIG_POSIX_TIMERS and CONFIG_CHECKPOINT_RESTORE).

======

I thought it would be quite interesting to see when some Linux distros
fixed this bug, since there was no CVE requested and assigned until
recently.

Initially I was only looking at Ubuntu 16.04, here's the related timeline:

* Nov 30, 2017 - the bug reported by syzbot [5]
* Dec 15, 2017 - the fix committed upstream [3]
* Feb 17, 2018 - the fix backported to the 4.4 stable kernel branch [6]
* Mar 15, 2018 - the fix added to the Ubuntu Xenial 4.4 kernel branch [7]
* Jul 25, 2018 - CVE requested
* Aug 2, 2018 - notified linux-distros@
* Aug 2, 2018 - announcement on oss-security@

In this particular case of a somewhat "scary" bug there was a window
of 3.5 months between the bug being reported and the fixing commit
reaching the Ubuntu Xenial 4.4 kernel branch. This gives some insight
into how much time it usually takes for a fix to travel from upstream
through stable into a distro kernel when there's no CVE. Compared to
the 14 days, that distros are usually given to fix a security bug
reported through linux-distros@, that seems rather long.

Then I decided to take a look at the CentOS kernel. I was quite
surprised to find out that this bug hasn't been fixed there at all. I
was under the impression that most Linux distros either follow stable
kernel branches or monitor upstream commits for security related fixes
themselves. It seems that this is not the case. Perhaps this fix was
missed because CentOS 7 kernel is based on the 3.10 kernel version,
and the 3.10 stable kernel release stopped being supported in November
2017.

This is just one bug though. Right now there are 700+ fixed bugs
reported by syzbot [8] and 200+ more, which are still not fixed [9].
Almost none of them have CVEs (if anybody want to practice requesting
CVEs, go for it). There are also ~9000 fixes backported to 4.4 stable
kernel. Some of them are security relevant and don't have CVEs. On top
of that apparently there are ~700 fixes that are missing in the 4.4
stable kernel [10].

It seems that a CVE is required for a particular security related fix
to end up in distro kernels, but there are no CVEs requested for most
of the bugs that are being fixed. So there's this inconsistency
between the Linux kernel community that just fixes the bugs without
bothering about CVEs and the distros, which require CVEs to apply
fixes to their kernels.

Just some thoughts :)

Thanks!

======

[1] https://syzkaller.appspot.com/bug?id=e4cd90db60c4517094c0ffcb9468de1bf86809e7

[2] https://github.com/torvalds/linux/commit/57b8015e07a70301e9ec9f324db1a8b73b5a1e2b

[3] https://github.com/torvalds/linux/commit/cef31d9af908243421258f1df35a4a644604efbe

[4] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-18344

[5] https://groups.google.com/d/msg/syzkaller-bugs/9mUyHIix2ys/bTLPoT-kAgAJ

[6] https://lkml.org/lkml/2018/2/17/139

[7] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1756121

[8] https://syzkaller.appspot.com/

[9] https://syzkaller.appspot.com/?fixed=upstream

[10] https://twitter.com/grsecurity/status/1022599945604526087