linux-kernel - [PATCH v2] tracing: fix oob write in trace_seq_to

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250421152850.15387-1-aha310510@gmail.com>
Date: Tue, 22 Apr 2025 00:28:50 +0900
From: Jeongjun Park <aha310510@...il.com>
To: rostedt@...dmis.org,
	mhiramat@...nel.org
Cc: linux-kernel@...r.kernel.org,
	linux-trace-kernel@...r.kernel.org,
	syzbot+c8cd2d2c412b868263fb@...kaller.appspotmail.com,
	Jeongjun Park <aha310510@...il.com>
Subject: [PATCH v2] tracing: fix oob write in trace_seq_to_buffer()

syzbot reported this bug:
==================================================================
BUG: KASAN: slab-out-of-bounds in trace_seq_to_buffer kernel/trace/trace.c:1830 [inline]
BUG: KASAN: slab-out-of-bounds in tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822
Write of size 4507 at addr ffff888032b6b000 by task syz.2.320/7260

CPU: 1 UID: 0 PID: 7260 Comm: syz.2.320 Not tainted 6.15.0-rc1-syzkaller-00301-g3bde70a2c827 #0 PREEMPT(full) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:408 [inline]
 print_report+0xc3/0x670 mm/kasan/report.c:521
 kasan_report+0xe0/0x110 mm/kasan/report.c:634
 check_region_inline mm/kasan/generic.c:183 [inline]
 kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189
 __asan_memcpy+0x3c/0x60 mm/kasan/shadow.c:106
 trace_seq_to_buffer kernel/trace/trace.c:1830 [inline]
 tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822
 ....
==================================================================

It has been reported that trace_seq_to_buffer() tries to copy more data
than PAGE_SIZE to buf. Therefore, to prevent this, we should use the
smaller of trace_seq_used(&iter->seq) and PAGE_SIZE as an argument.

Reported-by: syzbot+c8cd2d2c412b868263fb@...kaller.appspotmail.com
Fixes: 3c56819b14b0 ("tracing: splice support for tracing_pipe")
Suggested-by: Steven Rostedt <rostedt@...dmis.org>
Signed-off-by: Jeongjun Park <aha310510@...il.com>
---
v2: Corrected the correct location as suggested by the maintainer
---
 kernel/trace/trace.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 8ddf6b17215c..170c31da61e0 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -6784,7 +6784,7 @@ static ssize_t tracing_splice_read_pipe(struct file *filp,
 	};
 	ssize_t ret;
 	size_t rem;
-	unsigned int i;
+	unsigned int i, copy_len;

 	if (splice_grow_spd(pipe, &spd))
 		return -ENOMEM;
@@ -6818,16 +6818,18 @@ static ssize_t tracing_splice_read_pipe(struct file *filp,

 		rem = tracing_fill_pipe_page(rem, iter);

+		copy_len = trace_seq_used(&iter->seq);
+
 		/* Copy the data into the page, so we can start over. */
 		ret = trace_seq_to_buffer(&iter->seq,
 					  page_address(spd.pages[i]),
-					  trace_seq_used(&iter->seq));
+					  min(copy_len, PAGE_SIZE));
 		if (ret < 0) {
 			__free_page(spd.pages[i]);
 			break;
 		}
 		spd.partial[i].offset = 0;
-		spd.partial[i].len = trace_seq_used(&iter->seq);
+		spd.partial[i].len = min(copy_len, PAGE_SIZE);

 		trace_seq_init(&iter->seq);
 	}
--