2015 kernel CVEs

I like to look back over old CVEs to see how we could do better. Here is the list from 2015. I got most of this information from the Ubuntu CVE tracker. Thanks Ubuntu!. If it doesn't have a hash that means it might not be fixed yet.

CVE-2015-5707 451a2886b6bf fdc81f45e9f5: scsi/sg: integer overflow leading to buffer overflow (iovec) CVE-2015-5257 cbb4be652d37: usb/whiteheat: NULL deref with bad hardware.
CVE-2015-6252 7932c0bd7740: vhost: resource leak. DoS
CVE-2015-5366 beb39db59d14: udp: not yielding the CPU. DoS udp: duplicate of CVE-2015-5366? CVE-2015-4700 3f7352bf21f8: bpf: NULL deref on corner case.
CVE-2015-7872 f05819df10d7: keys: uninitialized data
CVE-2015-4178 820f9f147dcc: fs_pin: uninitialized data
CVE-2015-4002 d114b9fe78c8 9a59029bc218: staging/ozwpan: buffer overflow
CVE-2015-7799 0baa57d8dc32 4ab42d78e37a: ppp: bad bounds check leads to NULL deref. (root only normally). CVE-2015-3290 9b6e6a8334d5: nmi: nested NMI is problematic
CVE-2015-2041 6b8d9117ccb4: net: llc: bounds error leads to info leak
CVE-2015-4003 04bf464a5dfd: staging/ozwpan: divide by zero
CVE-2015-3331 ccfe8c3f7e52: crypto/aesni: buffer overflow because of math error CVE-2015-4001 b1bb5b49373b: staging/ozwpan: array underflow write
CVE-2015-6526 9a5cbce421a2: powerpc/perf: forever loop
CVE-2015-0239 f3747379accb: KVM: x86: uninitialized data
CVE-2015-4176 e0c9c0afd2fc: mnt: flaw in logic
CVE-2015-2150 af6fc858a35b: xen-pciback: accidentally gave too much power
CVE-2015-3339 : fs: race condition between chown and execve
CVE-2015-2830 956421fbb74c: x86/asm/entry/64: faw in assembly logic
CVE-2015-4692 ce40cd3fc7fa: kvm: x86: NULL deref
CVE-2015-4170 cf872776fc84: tty: hang in tty
CVE-2015-1350 : fs: some attributes are managed by chown some by the lsm
CVE-2015-0275 0f2af21aae11: ext4: BUG() alignment issue when page size larger than block size CVE-2015-5706 f15133df088e: path_openat: double free
CVE-2015-4177 cd4a40174b71: mnt: flaw in logic with namespaces (crash I guess). CVE-2015-6937 74e98eb08588: RDS: NULL deref
CVE-2015-2925 cde93be45a8a 397d425dc26d: vfs: logic flaw handling path names CVE-2015-3636 a134f083e79f: ipv4: use after free leads to NULL deref
CVE-2015-2877 : kvm: ASLR base address leak of co-located VMs.
CVE-2013-2015 0e9a9a1ad619: ext4: hang during mount
CVE-2015-5157 9b6e6a8334d5: x86/nmi/64: nested NMI problems
CVE-2015-1420 161f873b8913: vfs: bounds checking error leads to serious info leak CVE-2015-1421 600ddd682554: net/sctp: double free
CVE-2015-7613 b9a532277938: ipc/msg: uninitialized data
CVE-2015-4004 a73e99cb67e7: staging/ozwpan: we just deleted the driver
CVE-2015-3212 2d45a02d0166: net/sctp: race condition
CVE-2015-3291 810bc075f78f: x86/nmi/64: more nested NMI issues
CVE-2015-4167 23b133bdc452: fs/udf: trusting the disk (missing range checks) CVE-2015-1805 f0d1bec9d58d 637b58c2887e: fs/pipe: bad error handling leads to buffer overflow CVE-2015-1333 ca4da5dd1f99: keys: memory leak
CVE-2015-2042 db27ebb111e9: net/rds: using wrong bounds leads to info leak
CVE-2015-5283 8e2d61e0aed2: net/sctp: uninitialized data. life cycle issues. CVE-2015-5697 b6878d9e0304: md: not zeroing memory from kmalloc() leads to info leak CVE-2015-5364 beb39db59d14: udp: duplicate of CVE-2015-5366?
CVE-2015-4036 59c816c1f24d: vhost/scsi: wrong bounds limit
CVE-2015-5156 48900cb6af42: virtio-net: logic flaw leads to buffer overflow CVE-2015-2922 6fd99094de2b: ipv6: logic flaw leads to dropped packets
CVE-2015-1593 4e7c22d447bb: ASLR: shift truncation leads to not enough ASLR CVE-2015-1573 a2f18db0c68f: netfilter/nf_tables: use after free
CVE-2015-2686 4de930efc23b: net: missing access_ok() checks
CVE-2015-2672 06c8173eb92b: x86/fpu/xsaves: logic flaw in assembly leads to DoS CVE-2015-1465 df4d92549f23: ipv4: logic flaw with RCU leading to DoS
CVE-2015-2666 f84598bd7c85: x86/microcode/intel: missing bounds check verifying microcode CVE-2015-0274 8275cdd0e7ac: xfs: using wrong bounds
CVE-2015-8215 77751427a1ff: ipv6: setting wrong mtu causes packet loss
CVE-2015-7885 4b6184336ebb: staging/dgnc: info leak
CVE-2015-7884 eda98796aff0: media/vivid: info leak
CVE-2015-7509 c9b92530a723 0e9a9a1ad619: ext4: hang on mount
CVE-2015-8575 : net/bluetooth: still private
CVE-2015-7513 0185604c2d82: KVM: uninitialized data leads to mod by zero
CVE-2015-8324 744692dc0598: ext4: NULL deref mounting file systems
CVE-2015-5307 54a20552e1ea: KVM: forever loop
CVE-2015-7550 b4a1b4f5047e: KEYS: Race condition
CVE-2015-8569 09ccfd238e5a: pptp: underflow leads to serious information leak CVE-2015-8660 acff81ec2c79: ovl: logic flaw in checking permisions
CVE-2015-8374 0305cd5f7fca: Btrfs: logic flaw in truncate leads to information leak CVE-2015-8539 096fe9eaea40: Keys: uninitialized data leads to bad dereference CVE-2015-8709 : ptrace: race in user namespaces let's users trace root processes CVE-2015-8746 18e3b739fdc8: NFS: NULL deref. missing function pointer.
CVE-2015-8104 cbdb967af3d5: kvm: guest can make the host hang
CVE-2015-8767 635682a14427: sctp: lockup
CVE-2015-7990 8c7188b23474: RDS: race condition leads to NULL deref
CVE-2015-5327 cc25b994acfb: X.509: off by one read leads to badness
CVE-2015-8543 79462ad02e86: ipv4: bad range checking leads to NULL deref

There are several ways that CVEs are assigned. The person who discovers the bug can get it from oss-security. If bugs are reported to [email protected] they get forwarded to linux-distros who allocates a CVE. Distributions look through the stable patches and file for CVEs. A few maintainers apply for CVEs, notably the KVM devs and I think David Howells.

There was only a coupls CVEs that looks like they came from a filesystem fuzzer where you create a corrupt filesystems and then try use them. There was only one that might have come from a USB fuzzer. We probably should be testing those things better.

There was one CVE from Smatch. Smatch has improved, inspired by the ozwpan bugs and hopefully could catch most of those bounds errors now.

Quite a few bugs were found using the Trinity fuzzer. Also the new syzkaller fuzzer seems to have found a bunch of stuff. Good work. I think people are using the fuzzers with kasan as well which is a fantastic tool.

Many of the use-after-free and unintialized data bugs would be less harmful if we had some kernel hardenning patches.

A lot of the bugs are just really complicated things with funny corner cases, namespace issues or people just made mistake in the logic and it's hard to do anything about it.

regards,
dan carpenter

I tried that, but it didn't lead to any results in the kernel [1]. What I did:
* Use filesystem checking tools (fsck) and fuzz them with afl
* Use the queue created by afl and try to mount these with a kasan-enabled kernel

My conclusion was that the filesystem code in the kernel is relatively robust (at least robust enough for this trivial fuzzing). But it led to a number of bugs discovered in filesystem fsck tools.

This is surprising to me. There was a talk at black hat amsterdam in 2014 about a project trying to do exactly this. They sounded like they have dozends of crashers that just need to be sorted and reported upstream. Here's the code [2] and the talk [3].
Maybe this project has stalled and needs someone to look at it?

[1]
https://www.coreinfrastructure.org/sites/cii/files/pages/files/2015-09-fuzzing-report.pdf
[2] https://github.com/schumilo/vUSBf
[3] https://www.youtube.com/watch?v=OAbzN8k6Am4

Hanno Böck
http://hboeck.de/

mail/jabber: [email protected]
GPG: BBB51E42

One of the unsung heros that frequently assisted in discovery in some of these issues were ktsan.

Thanks for the nice writeup,

Wade Mealing

Thanks,

Wade Mealing

That's the list of bugs originating in 2015. You need to go back further to see some of the fun ones still present (CVE-2013-7445 for example)

There are a bunch of those ignored in Bugzilla for years. I think the ones for the mainstream file systems have all been tackled but things like reiserfs don't survive fuzzing too well, which is a problem if your distribution naïvely builds in automounting support for people rooting your box via USB stick.

Alan

As an experimental toy project, we've managed to implement the glue to have AFL run on the kernel code, using either a patched afl-as wrapper or a slightly modified GCC extension written by Dmitry Vyukov for syzkaller (-fsanitize-coverage=trace-pc), and our conclusion is quite different.

In the month Vegard Nossum has been using it, he reported at least a dozen problems at mount or readdir time:

btrfs:
https://www.mail-archive.com/[email protected]/msg48448.html
https://www.mail-archive.com/[email protected]/msg48976.html
https://www.mail-archive.com/[email protected]/msg49011.html

ext4:
http://marc.info/?l=linux-ext4&m=144898824424465&w=2
https://lkml.org/lkml/2015/12/13/187

hfs:
http://marc.info/?l=linux-fsdevel&m=144900215929323&w=2

isofs:
https://marc.info/?l=linux-kernel&m=144933509518680&w=2

udf:
https://lkml.org/lkml/2015/12/10/438
https://lkml.org/lkml/2015/12/11/526

vfat:
https://lkml.org/lkml/2015/11/13/782
https://lkml.org/lkml/2015/11/23/36

xfs:
https://marc.info/?l=linux-xfs&m=144904267207656&w=2

It should be noted that most of these problems were found relatively quickly and without changing much the filesystem code, checksums weren't disabled for example a part for superblock checksum in btrfs. And that was mostly fuzzing the mount/readdir syscalls so a lot more can probably be found there.

Thanks,
Quentin

[...]

[...]

That's not *from* 2015.

You missed a few recent ones:

CVE-2015-7566 : Crash on invalid USB device descriptors in visor driver
CVE-2015-8550 54d5d882c7e4, 0f589967a73f, 68a33bfd8403, 1f13d75ccb80, 18779149101c, be69746ec12f, 8135cf8b0927: paravirtualized drivers incautious about shared memory contents CVE-2015-8551 56441f3c8e5b, 5e0ce1455c09, a396f3a210c3, 7cfb905b9638, 408fb0e5aa7f: Linux pciback missing sanity checks leading to crash CVE-2015-8552 56441f3c8e5b, 5e0ce1455c09, a396f3a210c3, 7cfb905b9638, 408fb0e5aa7f: Linux pciback missing sanity checks leading to crash

(There's some subtle distinction between the last two.)

[...]

I think that hardening filesystems is a losing battle.  We can fuzz with and protect against invalid static filesystem images, but the full problem includes malicious removable storage devices that can exploit TOCTTOU issues.  We should probably be encouraging distributions to mount removable devices using FUSE and to run the filesystem code with minimal privileges.

As for USB descriptors, I'm somewhat more hopeful about hardening.  At the same time, it seems like it should be practical to put more low- performance USB drivers into userspace.

[...]

We can add chicken bits so that admins who don't need certain features can turn them off (or, inversely, those who do need them will need to turn them on).

Ben.

Ben Hutchings
Horngren's Observation:
                   Among economists, the real world is often a special case.

[...]

Makes no sense that this was assigned a CVE.
I fixed this _2 yrs before_ it was reported and the patch was CC'd stable.

Regards,
Peter Hurley

I'm guessing the CVE was assigned because there are distributions that ship based on kernels earlier than 3.13. Those distributors need to verify if they have the fix, etc.

josh

Yes, that's what happened here, Red Hat asked for it from what I remember. I complained loudly on the oss-security list about it, but oh well...

greg k-h

What drivers do we currently have in the kernel that should/could be done in userspace instead? I'll gladly drop them from the tree.

And yes, we need to do better about handling crazy USB descriptors, I think the majority of this work is already done, but it takes hand-auditing to verify it :(

thanks,

greg k-h

An engineer at Red Hat did a pretty exhaustive set of file system fuzzing some 5 years or so ago (plus or minus; I'm a little fuzzy on the dates). At the time he found a number of problems in ext4 and other file systems, and those got fixed fairly promptly. (It was great; he gave us sample file systems to reproduce the bug, so it was pretty straightforward to find and fix the problems found during that effort.)

The ext4 related 2015 CVE's were all due to code that went in more recently, and partially in response to that, Darrick Wong contributed ext4-specific fuzzers to xfstess and to e2fsprogs. I think he found at least one or two ext4 bug that way, although I don't remember if they got CVE's assigned to them.

Darrick's work, plus the relatively disciplined regression test suite development policy in e2fsprogs is probably why Hanno didn't find any such issues in e2fsprogs, although he did seem to find bugs in many of the others file systems.

If I recall correctly Darrick had talked about trying to make a filesystem-generic fuzzer for xfstests, but I'm not sure what happened to that idea. It looks like he also did provide a set of fuzzing tests in xfstests, though.

So while I wouldn't want to discourage people from spending more time in doing file system fuzz tests (I really *love* it when people find and report bugs to me :-), I suspect the reason why we aren't finding as many file system related CVE's is that it's well trodden ground, since it's a pretty easy / obvious place to start probing for weaknesses. (And it's much easier than finding data races, for example.)

If people do what to invest more in hardening file systems, I would recommend automating the file system fuzz testers and then trying to get the upstream file system developers to run them.

Cheers,

- Ted

Why is that a CVE? Affected code is in pin_remove(), which is only called from fs_pin ->kill() instances; if one is _ever_ called more than once per fs_pin lifetime, we are already FUBAR. If Eric had ever intended to add checks for hlist_unhashed() on those lists, such checks never had been added to the tree. They definitely did not exist at the moment when that commit went in.

It got merged mostly on the "it doesn't harm anything and it's a bit more tidy that way" basis; if it had ever changed behaviour in any visible way, *THEN* we had a real problem and that problem was not fixed by that commit, so I would really like to see the details - simply to make sure that the damn thing had been eventually fixed.

Eric, could you explain? And could whoever'd been responsible for that CVE describe the process that had lead to its creation?

As best I know this was an issue because someone borked a backport, and skipped this patch.

As I recall hlist_del_init was needed because in one instance one of the lists was not used. Which is actually what it says in the description of 820f9f147dcc so I will leave it at that.

Eric

As this isn't a kernel bug, and is not a race, and no one has even bothered to see if any userspace processes are this stupid I don't even think that qualifies as a CVE.

There is room for improvement in this area but I don't see how this qualifies as a CVE.

So for doing better I recommend a little more vetting and paying attention before assigning CVEs.

Eric

I think this nicely underscores the importance of all the hardening efforts, especially Laura's PAX_MEMORY_SANITIZE port. And with the recent keyring issue, having David's PAX_REFCOUNT port too. It's all coming along (slowly). :)

-Kees

Kees Cook
Chrome OS & Brillo Security

The question for CVE assignment is more if this bug existed in shipped kernel releases, not when it was fixed in relation to assignment.

Ciao, Marcus

FWIW, fixed by 8b01fc86b9f4 ("fs: take i_mutex during prepare_binprm for set[ug]id executables").

Regards,
Miroslav

https://packetstormsecurity.com/files/133892/RedHat-Enterprise-Linux-7.1-Denial-Of-Service.html

It seems they have started reporting issues and got limited replies.

Hanno Böck
http://hboeck.de/

mail/jabber: [email protected]
GPG: BBB51E42

Disclaimer: I work for Red Hat Product Security group in the kernel sub group with Vladis.

So from what I can see:

- The CVE has been assigned.
- A kernel has been built with a patch
- Communicated with upstream about accepting the patch.
- The issue is awaiting testing on the reporter since 24th of November last year.
- This is not the only bugs that has been reported and worked between Ralf and Vladis ( https://goo.gl/5G1cnw )

I'm all about improving process, I imagine I would have done the same
steps. What changes to the responses would need to be made to be less
limited ? Understand that i'm not taking this personally and consider this an opportunity for Red Hat Security to improve as a group.

If you want to take this off list, I'm cool with that.

Thanks,

Wade Mealing

Thanks,

Wade Mealing

An obvious example would be HID drivers.  (I'll grant you that putting those in user-space would complicate the boot process when a disk encryption passphrase is needed.)

Ben.

Ben Hutchings
The program is absolutely right; therefore, the computer must be wrong.

Just to make this clear, I was not involved at all. I based my statement purely on publicly available information from the advisory that says:
"We unsuccessfully tried to contact the vendor for several months. We never received any response on our bugtraq ticket:"

So I'm not the right person to discuss what went wrong in the process.

FWIW I tried to reach out to one of the people doing this research (Sergej Schumilo) and hope we can make sure these issues get tackled.

Hanno Böck
http://hboeck.de/

mail/jabber: [email protected]
GPG: BBB51E42

That and for userspace that expects to get an input device stream, combining serial, ps2, bluetooth, and USB devices all at the same time. So while it might be possible, keeping input devices and HID support in the kernel makes sense.

Except for those drivers that abuse the HID interface due to the decisions the Windows developers made years ago, and are not reall HID devices, those should all be done in userspace, just like Windows does. Hopefully we have been good in keeping those types of drivers out of the kernel.

thanks,

greg k-h

I agree that it's not a kernel bug and not a kernel race - userspace developers assumed security guarantees that the kernel didn't actually provide.

However, I think that the kernel is missing documentation here and that namespaces are designed somewhat unfortunately. A container that can be created and securely, robustly entered by an unprivileged user would have to work like this under the current rules as far as I can tell:

To create the container:
setsid
[prevent tty pushback via /dev/tty]
set up tty IO forwarding if necessary
[prevents tty pushback, possibly additional filtering]
unshare(CLONE_NEWUSER) to create a "purgatory" user ns.
Map the container owner to uid 0, map all uids that should be mapped into
the container (including the container root) to 1 and higher (where 1 is the container root).
stash FD to the purgatory user namespace somewhere in the outer ns drop all privileges (open fds, ...)
setresuid(1,1,1) [still protected against ptrace by nondumpability] unshare(CLONE_NEWUSER) to create the container's user ns
[From here on, we can be ptraced by the ns root user from outside.
The ns root user could ptrace us from outside at this point and see the outer namespaces through us, but that's okay, he'd have to already be in the outer user ns for that.]
set up other namespaces for the container
stash FDs to the container namespaces in the purgatory ns
let a process in the purgatory map the container uids and gids do security-revelant setup work (setup bind mounts, ...)
[be careful here, don't trust any files in container-controlled
filesystem parts]
do security-irrelevant setup work
execlp("init")

Then, to enter the container:
setsid
[prevent tty pushback via /dev/tty]
set up tty IO forwarding if necessary
[prevents tty pushback, possibly additional filtering]
Enter the purgatory user ns, referenced through an FD setresuid(1, 1, 1) [still protected against ptrace by nondumpability] enter container namespaces, but not the user namespace yet
[We don't really trust the namespace FDs supplied by the setup
process because they were sent after the ns root user gained ptrace access, but that's okay because we can only move downward using setns(), so we end up in namespaces below the purgatory that are owned by the namespace root. That's good enough.]
drop privileges (open fds, ...)
enter container user namespace [ns root gains ptrace access]

The purgatory user ns is necessary because without privileges in the container's parent user namespace, it's not possible to switch to the container root uid prior to entering it (except with an ugly hack involving a temporary namespace, newuidmap and a (possibly temporary) setuid binary), and more importantly, even given access to the container's root uid, it's not possible to actually enter the container without having the container owner's euid unless you have CAP_SYS_ADMIN in the outer namespace.

(Of course, this could be simplified with a setuid root helper, but I don't think anyone wants more of those to be necessary.)

I know of at least two projects that enter user namespaces without the necessary care, one of them is LXC.

I think I agree with that.

If there are projects that screw it up then there should be a CVE - it just needs someone to update the CVE to indicate where the actual flaw is.

Alan

This has been one of the motivations for creating hidraw interface. So my hope here is that we're doing reasonably well in this respect.

Jiri Kosina
SUSE Labs

[...]

I was thinking that the HID drivers would feed events back into the kernel through an enhanced version of evdev_write().  The userland consumers of input events wouldn't need to change at all.

Ben.

Ben Hutchings
Horngren's Observation:
                   Among economists, the real world is often a special case.