[linux{,-lts,zen,hardened}] 4.14.8-1 arbitrary read+write via incorrect range tracking in eBPF
Attached to Project:
Arch Linux
Opened by loqs (loqs) - Saturday,
23 December 2017, 05:09 GMT
Last edited by
Doug Newgard (Scimmia) - Friday, 29
December 2017, 22:18 GMT
|
Details
Description:
Additional info:
Steps to reproduce: |
This task depends upon
Closed by Doug Newgard (Scimmia)
Friday, 29 December 2017, 22:18 GMT
Reason for closing: Fixed
This is the suggested proof of concept against linux-lts https://github.com/brl/grlh/blob/master/get-rekt-linux-hardened.c
Fixes see https://bugs.chromium.org/p/project-zero/issues/detail?id=1454#c7
Mitigation sysctl -w kernel.unprivileged_bpf_disabled=1
total of 8 CVEs assigned for the issues
CVE-2017-16995 affects linux >= 4.9, the other 7 issues affect linux >= 4.14
CVE-2017-16996
bpf: fix incorrect tracking of register size truncation
https://git.kernel.org/linus/0c17d1d2c61936401f4702e1846e2c19b200f958
CVE-2017-16995
bpf: fix incorrect sign extension in check_alu_op()
https://git.kernel.org/linus/95a762e2c8c942780948091f8f2a4f32fce1ac6f
CVE-2017-17857
bpf: fix missing error return in check_stack_boundary()
https://git.kernel.org/linus/ea25f914dc164c8d56b36147ecc86bc65f83c469
CVE-2017-17856
bpf: force strict alignment checks for stack pointers
https://git.kernel.org/linus/a5ec6ae161d72f01411169a938fa5f8baea16e8f
CVE-2017-17855
bpf: don't prune branches when a scalar is replaced with a pointer
https://git.kernel.org/linus/179d1c5602997fef5a940c6ddcf31212cbfebd14
CVE-2017-17854
bpf: fix integer overflows
https://git.kernel.org/linus/bb7f0f989ca7de1153bd128a40a71709e339fa03
CVE-2017-17853
bpf/verifier: fix bounds calculation on BPF_RSH
https://git.kernel.org/linus/4374f256ce8182019353c0c639bb8d0695b4c941
CVE-2017-17852
bpf: fix 32-bit ALU op verification
https://git.kernel.org/linus/468f6eafa6c44cb2c5d8aad35e12f06c240a812a
http://openwall.com/lists/oss-security/2017/12/21/2
http://openwall.com/lists/oss-security/2017/12/23/2
The patches are all already part of the 4.14 stable queue, so I guess instead of rushing to patch we'll just wait for 4.14.9.