Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#56832 - [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
Task Type Bug Report
Category Security
Status Closed
Assigned To Tobias Powalowski (tpowa)
Andreas Radke (AndyRTR)
Jan Alexander Steffens (heftig)
Levente Polyak (anthraxx)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


ebpf allows unprivileged local user to read arbitary kernel memory

Additional info:
One of the exploits may impact linux-lts

Steps to reproduce:
Proof of Concepts in link exploit plus details have now been made public
This task depends upon

Closed by  Doug Newgard (Scimmia)
Friday, 29 December 2017, 22:18 GMT
Reason for closing:  Fixed
Comment by loqs (loqs) - Saturday, 23 December 2017, 05:16 GMT
This is the suggested proof of concept against linux-lts
Fixes see
Mitigation sysctl -w kernel.unprivileged_bpf_disabled=1
Comment by Levente Polyak (anthraxx) - Saturday, 23 December 2017, 11:51 GMT
total of 8 CVEs assigned for the issues
CVE-2017-16995 affects linux >= 4.9, the other 7 issues affect linux >= 4.14

bpf: fix incorrect tracking of register size truncation

bpf: fix incorrect sign extension in check_alu_op()

bpf: fix missing error return in check_stack_boundary()

bpf: force strict alignment checks for stack pointers

bpf: don't prune branches when a scalar is replaced with a pointer

bpf: fix integer overflows

bpf/verifier: fix bounds calculation on BPF_RSH

bpf: fix 32-bit ALU op verification
Comment by Jan Alexander Steffens (heftig) - Sunday, 24 December 2017, 04:03 GMT
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.