Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp2571267imw; Wed, 6 Jul 2022 08:11:00 -0700 (PDT) X-Google-Smtp-Source: AGRyM1uD6yreDXVe8Dbzwty/5mleMmh/tOu6gBV17BUWm0RJTs+EOz+ckNDcu+Cgb8K5yfUu/kSo X-Received: by 2002:a17:906:4313:b0:726:3b55:704b with SMTP id j19-20020a170906431300b007263b55704bmr40623211ejm.398.1657120260344; Wed, 06 Jul 2022 08:11:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657120260; cv=none; d=google.com; s=arc-20160816; b=DvnZEOKy7UebubVWN5RW4e+xlFCnWR33Sbg5+quHmDEZkQi65mEOsSoubCgfM1dv7L AaWQyJpDHXg9u2Lla59fwh+R4fchkzsBncareDFsV3pIklBG0zbyVPshToHMXNWtmn5H oZcHeP3xOcAkcz0Uj7ObtB4TzFyoRnrf1fQTm6bJuwwvy1vQS+VWg9O9oeOpTWAirlM6 qiwlGOi9ZgjGULKOsSkQtpCfoOAU/UBbemzqQLhXIersN0mZAwYO2wT6DLBpYcW+gUh9 wwC5Z7u8iqU7jwSxH7ofomSwMWTCn0jeIZcQ8wdznGCmCtnfyX3Tq7+jP1AYmfyGSUWv 95pA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:subject:cc:to:from:date; bh=ze0Yi9anHk7AcFnDICanJhjbze5oAZsDo4u978VVPzA=; b=04capXf/KAzYQMwjN/4ktGEehQaugxnF9PvmkvEWpbkYQ1KeooiaWcsHEU3ZMru787 UVLjHj21WLog+1GChiGkKZkXPBQkho+aS7lv+dVK1EqxKYGHkGKmhYZgYNXt0RPYkicB YD7ydFB7GDhw9sJmV/Sz3vLNdsRQCr9x0MLkbCXNr9ea3hUH5CplFN8Dg2nMWbKCk8Vj UDJpjcoNKSxv0vGZjw5hmi3TP9vIfyQQHmpHjjqK4/jCOphu5aSS+4eL9aeI5shaCdGT OIccJcQ/Xu+H4n9j+ODYe0KrP2ebkxoxMFA+VOhOQhFV+1UYsvZB7NZy4hz5FEPXNVFn kV3g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hc39-20020a17090716a700b00711da366315si1161883ejc.717.2022.07.06.08.10.34; Wed, 06 Jul 2022 08:11:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231431AbiGFOur (ORCPT + 99 others); Wed, 6 Jul 2022 10:50:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39694 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232070AbiGFOuo (ORCPT ); Wed, 6 Jul 2022 10:50:44 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A04ED240B0; Wed, 6 Jul 2022 07:50:43 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 2B83661E8E; Wed, 6 Jul 2022 14:50:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DEA7EC3411C; Wed, 6 Jul 2022 14:50:41 +0000 (UTC) Date: Wed, 6 Jul 2022 10:50:40 -0400 From: Steven Rostedt To: LKML Cc: Neil Horman , "David S. Miller" , netdev , Eric Dumazet , Kuniyuki Iwashima Subject: [PATCH] net: sock: tracing: Fix sock_exceed_buf_limit not to dereference stale pointer Message-ID: <20220706105040.54fc03b0@gandalf.local.home> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: "Steven Rostedt (Google)" The trace event sock_exceed_buf_limit saves the prot->sysctl_mem pointer and then dereferences it in the TP_printk() portion. This is unsafe as the TP_printk() portion is executed at the time the buffer is read. That is, it can be seconds, minutes, days, months, even years later. If the proto is freed, then this dereference will can also lead to a kernel crash. Instead, save the sysctl_mem array into the ring buffer and have the TP_printk() reference that instead. This is the proper and safe way to read pointers in trace events. Link: https://lore.kernel.org/all/20220706052130.16368-12-kuniyu@amazon.com/ Cc: stable@vger.kernel.org Fixes: 3847ce32aea9f ("core: add tracepoints for queueing skb to rcvbuf") Signed-off-by: Steven Rostedt (Google) --- include/trace/events/sock.h | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/include/trace/events/sock.h b/include/trace/events/sock.h index 12c315782766..777ee6cbe933 100644 --- a/include/trace/events/sock.h +++ b/include/trace/events/sock.h @@ -98,7 +98,7 @@ TRACE_EVENT(sock_exceed_buf_limit, TP_STRUCT__entry( __array(char, name, 32) - __field(long *, sysctl_mem) + __array(long, sysctl_mem, 3) __field(long, allocated) __field(int, sysctl_rmem) __field(int, rmem_alloc) @@ -110,7 +110,9 @@ TRACE_EVENT(sock_exceed_buf_limit, TP_fast_assign( strncpy(__entry->name, prot->name, 32); - __entry->sysctl_mem = prot->sysctl_mem; + __entry->sysctl_mem[0] = READ_ONCE(prot->sysctl_mem[0]); + __entry->sysctl_mem[1] = READ_ONCE(prot->sysctl_mem[1]); + __entry->sysctl_mem[2] = READ_ONCE(prot->sysctl_mem[2]); __entry->allocated = allocated; __entry->sysctl_rmem = sk_get_rmem0(sk, prot); __entry->rmem_alloc = atomic_read(&sk->sk_rmem_alloc); -- 2.35.1