Received: by 10.223.185.116 with SMTP id b49csp6420205wrg; Wed, 28 Feb 2018 09:06:32 -0800 (PST) X-Google-Smtp-Source: AG47ELsRRQU0l6mv0Qp2wKM/pjtfpbLWR5PPM00lWqMZQ6NQzbvixUb0ghAVJeR3wBQtRPWoch8b X-Received: by 10.98.238.2 with SMTP id e2mr10446718pfi.68.1519837592764; Wed, 28 Feb 2018 09:06:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519837592; cv=none; d=google.com; s=arc-20160816; b=yYEWiJOyp2bG9QH5HKNVy7auiWOZuKW2NAUtCbqDbge+m/bg9Q71FrQp8H/OwXwES4 LepLcrxjTgPfaBudSkizQRYY+LSS4wB1EefFQLAOFFn/YuPQpTlXxJwxEQsJQlS12qMc DUUKC/IB6m9sX8mvH2oK98kULxb7jm05aKZnGFVxjMr9vwxwoE3aWqM16f6RTT2Ri2PV jgTFm3kRiAA6Ea9gX1vwujytEftnoYEuBjYvoVSEzsF8HiPBCLpqo5bW0TOqWITIPO+k hBEuXnC5pxXbiOTl6KqYKoEwNSQcm5R+SgjmGRExSq/3NYFatrJZ+2XDyxh/9wx6sSDZ /UmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition :arc-authentication-results; bh=ReC/7Cy86LAyD76Z0rvpx3wxbzBx+erfu8C+5gkeFG8=; b=xCBKQGEqr0F2PeI7DADQCWp6U3Rz+ARSG2lD+Ukn82HWeNJSWA9fDytfwmDV5r6NQp z3bi+PCpd7ElhBUex3c8WJ5rjnaU86VxgExmlRb9mAdCz37xe+36XucOwt9aUq0IEosD WDoyCF11YC0gwHojSpLJ8JO6oNcwuSAdWmmqeu41Ez2K5zPYw8++YCVJywwMg3sTrcCC N7uFGtX00xmKVzWNBGrbTn7H3wTzJ7rIVH6u21DO+lbPUq/NeRkG091YErMGYBeaZM8m AWg4QTizhkU7RZNbbJgwPWbJj6N1SNR6C4dQlwlHi86lVDZ7DCzchGfDnPugjAJV9jMu 9Siw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v6si1467409pfa.116.2018.02.28.09.06.13; Wed, 28 Feb 2018 09:06:32 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753470AbeB1REa (ORCPT + 99 others); Wed, 28 Feb 2018 12:04:30 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:34334 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933273AbeB1Pv3 (ORCPT ); Wed, 28 Feb 2018 10:51:29 -0500 Received: from [2a02:8011:400e:2:6f00:88c8:c921:d332] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1er3Yr-0006XT-PF; Wed, 28 Feb 2018 15:22:29 +0000 Received: from ben by deadeye with local (Exim 4.90_1) (envelope-from ) id 1er3Yh-00009t-QC; Wed, 28 Feb 2018 15:22:19 +0000 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Steven Rostedt (VMware)" Date: Wed, 28 Feb 2018 15:20:18 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 144/254] ring-buffer: Mask out the info bits when returning buffer page length In-Reply-To: X-SA-Exim-Connect-IP: 2a02:8011:400e:2:6f00:88c8:c921:d332 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.55-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: "Steven Rostedt (VMware)" commit 45d8b80c2ac5d21cd1e2954431fb676bc2b1e099 upstream. Two info bits were added to the "commit" part of the ring buffer data page when returned to be consumed. This was to inform the user space readers that events have been missed, and that the count may be stored at the end of the page. What wasn't handled, was the splice code that actually called a function to return the length of the data in order to zero out the rest of the page before sending it up to user space. These data bits were returned with the length making the value negative, and that negative value was not checked. It was compared to PAGE_SIZE, and only used if the size was less than PAGE_SIZE. Luckily PAGE_SIZE is unsigned long which made the compare an unsigned compare, meaning the negative size value did not end up causing a large portion of memory to be randomly zeroed out. Fixes: 66a8cb95ed040 ("ring-buffer: Add place holder recording of dropped events") Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Ben Hutchings --- kernel/trace/ring_buffer.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/kernel/trace/ring_buffer.c +++ b/kernel/trace/ring_buffer.c @@ -336,6 +336,8 @@ EXPORT_SYMBOL_GPL(ring_buffer_event_data /* Missed count stored at end */ #define RB_MISSED_STORED (1 << 30) +#define RB_MISSED_FLAGS (RB_MISSED_EVENTS|RB_MISSED_STORED) + struct buffer_data_page { u64 time_stamp; /* page time stamp */ local_t commit; /* write committed index */ @@ -387,7 +389,9 @@ static void rb_init_page(struct buffer_d */ size_t ring_buffer_page_len(void *page) { - return local_read(&((struct buffer_data_page *)page)->commit) + struct buffer_data_page *bpage = page; + + return (local_read(&bpage->commit) & ~RB_MISSED_FLAGS) + BUF_PAGE_HDR_SIZE; }