[PATCH] net: sock: tracing: Fix sock_exceed_buf_limit not to dereference stale pointer

[PATCH] net: sock: tracing: Fix sock_exceed_buf_limit not to dereference stale pointer

[Steven Rostedt]

From: "Steven Rostedt (Google)" <rostedt@goodmis.org>

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) <rostedt@goodmis.org>
---
 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

Re: [PATCH] net: sock: tracing: Fix sock_exceed_buf_limit not to dereference stale pointer

[Kuniyuki Iwashima]

From:   Steven Rostedt <rostedt@goodmis.org>
Date:   Wed, 6 Jul 2022 10:50:40 -0400
> From: "Steven Rostedt (Google)" <rostedt@goodmis.org>
> 
> 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) <rostedt@goodmis.org>

Acked-by: Kuniyuki Iwashima <kuniyu@amazon.com>

Thanks for shipping the proper fix quickly!

Re: [PATCH] net: sock: tracing: Fix sock_exceed_buf_limit not to dereference stale pointer

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to netdev/net.git (master)
by David S. Miller <davem@davemloft.net>:

On Wed, 6 Jul 2022 10:50:40 -0400 you wrote:
> From: "Steven Rostedt (Google)" <rostedt@goodmis.org>
> 
> 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.
> 
> [...]

Here is the summary with links:
  - net: sock: tracing: Fix sock_exceed_buf_limit not to dereference stale pointer
    https://git.kernel.org/netdev/net/c/820b8963adae

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html