Hacker News Reader

Comment by cirowrc | Hacker News Reader

In the article the author states:

> CVE-2017-5123 was published earlier this year on Oct 12 — it was a Linux kernel vulnerability in the waitid() syscall for 4.12-4.13 kernel versions.

Does this mean that kernel versions prior to 4.12 are not affected? That's what I understood from the related issue in the bug tracker https://bugzilla.redhat.com/show_bug.cgi?id=1500094

By the way, this is very important:

> In 2017 alone, 434 linux kernel exploits where found, and as you have seen in this post, kernel exploits can be devastating for containerized environments. This is because containers share the same kernel as the host, thus trusting the built-in protection mechanisms alone isn’t sufficient. Make sure your kernel is always updated on all of your production hosts.

Great article!

View on HN

That range isn't quite correct. It only impacted 4.13 kernels, and only 4.13.0-4.13.6 (inclusive, distro-dependent due to backports).

It was patched in 4.13.7 after being introduced in the 4.13.0 merge window.

See https://lwn.net/Articles/736348/

This issue shouldn't have happened at all, but it was caught and patched very quickly, so relatively few real-world systems are or were affected.

it was introduced by this commmit: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

which by itself is in a 4.12 vanilla code tree

That commit is correct (4c48abe91be03d191d0c20cc755877da2cb35622), but it was not in 4.12 as cut by linus.

https://github.com/torvalds/linux/commit/4c48abe91be03d191d0... (click the little '...' to expand tags it's in) or:

    $ git tag --contains 4c48abe91be03d191d0c20cc755877da2cb35622
    v4.13

What is your methodology that gets that it is in the 4.12 tree?

you are right, i actually didn't check on git, my bad

Thanks!

> Make sure your kernel is always updated on all of your production hosts.

And in order to avoid any zero-day exploits, always use dedicated machines, never use a VPS server.

I'm not sure I get this - are you saying that you are more at risk due to the VM host layer?

Personally, I'd reasonably trust Xen or KVM or something else with hardware-based virtualization and the like to protect me in an multi-tenancy scenario. Much less so in the case of Docker. Sharing a full kernel with potentially malicious actors is more risky than sharing a hypervisor, much more surface area for attack.

that's correct, versions prior to 4.12 are not affected

This is 4.11:

https://elixir.free-electrons.com/linux/v4.11/source/kernel/...

The code is significantly different but I still see a lack of access_ok(), so was the checking performed somewhere else that I didn't notice (I haven't looked closely at this part of the kernel before)?

it is the use of unsafe_put_user without access_ok(), not access_ok() alone

IIUC, you only need the access_ok() when using the new unsafe_put_user(). That code is still using put_user().

Reply on news.ycombinator.com