Linus, I was hoping to get this to you before you released 4.6, but testing went into the weekend, and I don't do work over the weekend. This missed the release. Anyway...
Hao Qin reported an integer overflow possibility with signed and unsigned numbers in the ring-buffer code. https://bugzilla.kernel.org/show_bug.cgi?id=118001 At first I did not think this was too much of an issue, because the overflow would be caught later when either too much data was allocated or it would trigger RB_WARN_ON() which shuts down the ring buffer. But looking closer into it, I found that the right settings could bypass the checks and crash the kernel. Luckily, this is only accessible by root. The first fix is to convert all the variables into long, such that we don't get into issues between 32 bit variables being assigned 64 bit ones. This fixes the RB_WARN_ON() triggering. The next fix is to get rid of a duplicate DIV_ROUND_UP() that when called twice with the right value, can cause a kernel crash. The first DIV_ROUND_UP() is to normalize the input and it is checked against the minimum allowable value. But then DIV_ROUND_UP() is called again, which can overflow due to the (a + b - 1)/b, logic. The first called upped the value, the second can overflow (with the +b part). The second call to DIV_ROUND_UP() came in via a second change a while ago and the code is cleaned up to remove it. Please pull the latest trace-fixes-v4.6-rc7 tree, which can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git trace-fixes-v4.6-rc7 Tag SHA1: d85fb49268a70e889298446b589d34500aa74a41 Head SHA1: 59643d1535eb220668692a5359de22545af579f6 Steven Rostedt (Red Hat) (2): ring-buffer: Use long for nr_pages to avoid overflow failures ring-buffer: Prevent overflow of size in ring_buffer_resize() ---- kernel/trace/ring_buffer.c | 35 ++++++++++++++++++----------------- 1 file changed, 18 insertions(+), 17 deletions(-)
