* Forwarded: Re: [syzbot] [bpf?] KASAN: stack-out-of-bounds Write in __bpf_get_stack
2025-11-10 18:41 [syzbot] [bpf?] KASAN: stack-out-of-bounds Write in __bpf_get_stack syzbot
@ 2025-11-10 19:01 ` syzbot
2025-11-10 19:17 ` syzbot
` (8 subsequent siblings)
9 siblings, 0 replies; 24+ messages in thread
From: syzbot @ 2025-11-10 19:01 UTC (permalink / raw)
To: linux-kernel, syzkaller-bugs
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.
***
Subject: Re: [syzbot] [bpf?] KASAN: stack-out-of-bounds Write in __bpf_get_stack
Author: listout@listout.xyz
On 10.11.2025 10:41, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: f8c67d8550ee bpf: Use kmalloc_nolock() in range tree
> git tree: bpf-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=121a50b4580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=e46b8a1c645465a9
> dashboard link: https://syzkaller.appspot.com/bug?extid=d1b7fa1092def3628bd7
> compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12270412580000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=128bd084580000
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/d9e95bfbe4ee/disk-f8c67d85.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/0766b6dd0e91/vmlinux-f8c67d85.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/79089f9e9e93/bzImage-f8c67d85.xz
>
> The issue was bisected to:
>
> commit e17d62fedd10ae56e2426858bd0757da544dbc73
> Author: Arnaud Lecomte <contact@arnaud-lcm.com>
> Date: Sat Oct 25 19:28:58 2025 +0000
>
> bpf: Refactor stack map trace depth calculation into helper function
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1632d0b4580000
> final oops: https://syzkaller.appspot.com/x/report.txt?x=1532d0b4580000
> console output: https://syzkaller.appspot.com/x/log.txt?x=1132d0b4580000
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+d1b7fa1092def3628bd7@syzkaller.appspotmail.com
> Fixes: e17d62fedd10 ("bpf: Refactor stack map trace depth calculation into helper function")
>
> ==================================================================
> BUG: KASAN: stack-out-of-bounds in __bpf_get_stack+0x5a3/0xaa0 kernel/bpf/stackmap.c:493
> Write of size 168 at addr ffffc900030e73a8 by task syz.1.44/6108
#syz test
diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
index 2365541c81dd..c68589d0f5f0 100644
--- a/kernel/bpf/stackmap.c
+++ b/kernel/bpf/stackmap.c
@@ -479,7 +479,6 @@ static long __bpf_get_stack(struct pt_regs *regs, struct task_struct *task,
goto err_fault;
}
- trace_nr = trace->nr - skip;
copy_len = trace_nr * elem_size;
ips = trace->ip + skip;
--
Regards,
listout
^ permalink raw reply related [flat|nested] 24+ messages in thread* Forwarded: Re: [syzbot] [bpf?] KASAN: stack-out-of-bounds Write in __bpf_get_stack
2025-11-10 18:41 [syzbot] [bpf?] KASAN: stack-out-of-bounds Write in __bpf_get_stack syzbot
2025-11-10 19:01 ` Forwarded: " syzbot
@ 2025-11-10 19:17 ` syzbot
2025-11-10 20:58 ` syzbot
` (7 subsequent siblings)
9 siblings, 0 replies; 24+ messages in thread
From: syzbot @ 2025-11-10 19:17 UTC (permalink / raw)
To: linux-kernel, syzkaller-bugs
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.
***
Subject: Re: [syzbot] [bpf?] KASAN: stack-out-of-bounds Write in __bpf_get_stack
Author: listout@listout.xyz
On 10.11.2025 10:41, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: f8c67d8550ee bpf: Use kmalloc_nolock() in range tree
> git tree: bpf-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=121a50b4580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=e46b8a1c645465a9
> dashboard link: https://syzkaller.appspot.com/bug?extid=d1b7fa1092def3628bd7
> compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12270412580000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=128bd084580000
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/d9e95bfbe4ee/disk-f8c67d85.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/0766b6dd0e91/vmlinux-f8c67d85.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/79089f9e9e93/bzImage-f8c67d85.xz
>
> The issue was bisected to:
>
> commit e17d62fedd10ae56e2426858bd0757da544dbc73
> Author: Arnaud Lecomte <contact@arnaud-lcm.com>
> Date: Sat Oct 25 19:28:58 2025 +0000
>
> bpf: Refactor stack map trace depth calculation into helper function
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1632d0b4580000
> final oops: https://syzkaller.appspot.com/x/report.txt?x=1532d0b4580000
> console output: https://syzkaller.appspot.com/x/log.txt?x=1132d0b4580000
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+d1b7fa1092def3628bd7@syzkaller.appspotmail.com
> Fixes: e17d62fedd10 ("bpf: Refactor stack map trace depth calculation into helper function")
>
> ==================================================================
> BUG: KASAN: stack-out-of-bounds in __bpf_get_stack+0x5a3/0xaa0 kernel/bpf/stackmap.c:493
#syz test
diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
index 2365541c81dd..2db09ce39828 100644
--- a/kernel/bpf/stackmap.c
+++ b/kernel/bpf/stackmap.c
@@ -480,7 +480,7 @@ static long __bpf_get_stack(struct pt_regs *regs, struct task_struct *task,
}
trace_nr = trace->nr - skip;
- copy_len = trace_nr * elem_size;
+ /*copy_len = trace_nr * elem_size;*/
ips = trace->ip + skip;
if (user_build_id) {
@@ -490,7 +490,7 @@ static long __bpf_get_stack(struct pt_regs *regs, struct task_struct *task,
for (i = 0; i < trace_nr; i++)
id_offs[i].ip = ips[i];
} else {
- memcpy(buf, ips, copy_len);
+ memcpy(buf, ips, trace_nr);
}
/* trace/ips should not be dereferenced after this point */
--
Regards,
listout
^ permalink raw reply related [flat|nested] 24+ messages in thread* Forwarded: Re: [syzbot] [bpf?] KASAN: stack-out-of-bounds Write in __bpf_get_stack
2025-11-10 18:41 [syzbot] [bpf?] KASAN: stack-out-of-bounds Write in __bpf_get_stack syzbot
2025-11-10 19:01 ` Forwarded: " syzbot
2025-11-10 19:17 ` syzbot
@ 2025-11-10 20:58 ` syzbot
2025-11-10 21:16 ` [RFC bpf-next PATCH] bpf: Clamp trace length in __bpf_get_stack to fix OOB write Brahmajit Das
` (6 subsequent siblings)
9 siblings, 0 replies; 24+ messages in thread
From: syzbot @ 2025-11-10 20:58 UTC (permalink / raw)
To: linux-kernel, syzkaller-bugs
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.
***
Subject: Re: [syzbot] [bpf?] KASAN: stack-out-of-bounds Write in __bpf_get_stack
Author: listout@listout.xyz
On 10.11.2025 10:41, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: f8c67d8550ee bpf: Use kmalloc_nolock() in range tree
> git tree: bpf-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=121a50b4580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=e46b8a1c645465a9
> dashboard link: https://syzkaller.appspot.com/bug?extid=d1b7fa1092def3628bd7
> compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12270412580000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=128bd084580000
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/d9e95bfbe4ee/disk-f8c67d85.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/0766b6dd0e91/vmlinux-f8c67d85.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/79089f9e9e93/bzImage-f8c67d85.xz
>
> The issue was bisected to:
>
> commit e17d62fedd10ae56e2426858bd0757da544dbc73
> Author: Arnaud Lecomte <contact@arnaud-lcm.com>
> Date: Sat Oct 25 19:28:58 2025 +0000
>
> bpf: Refactor stack map trace depth calculation into helper function
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1632d0b4580000
> final oops: https://syzkaller.appspot.com/x/report.txt?x=1532d0b4580000
> console output: https://syzkaller.appspot.com/x/log.txt?x=1132d0b4580000
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+d1b7fa1092def3628bd7@syzkaller.appspotmail.com
> Fixes: e17d62fedd10 ("bpf: Refactor stack map trace depth calculation into helper function")
>
> ==================================================================
> BUG: KASAN: stack-out-of-bounds in __bpf_get_stack+0x5a3/0xaa0 kernel/bpf/stackmap.c:493
> Write of size 168 at addr ffffc900030e73a8 by task syz.1.44/6108
#syz test
diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
index 2365541c81dd..885130e4ab0d 100644
--- a/kernel/bpf/stackmap.c
+++ b/kernel/bpf/stackmap.c
@@ -480,6 +480,7 @@ static long __bpf_get_stack(struct pt_regs *regs, struct task_struct *task,
}
trace_nr = trace->nr - skip;
+ trace_nr = min_t(u32, trace_nr, size / elem_size);
copy_len = trace_nr * elem_size;
ips = trace->ip + skip;
--
Regards,
listout
^ permalink raw reply related [flat|nested] 24+ messages in thread* [RFC bpf-next PATCH] bpf: Clamp trace length in __bpf_get_stack to fix OOB write
2025-11-10 18:41 [syzbot] [bpf?] KASAN: stack-out-of-bounds Write in __bpf_get_stack syzbot
` (2 preceding siblings ...)
2025-11-10 20:58 ` syzbot
@ 2025-11-10 21:16 ` Brahmajit Das
2025-11-10 23:43 ` Forwarded: Re: [syzbot] [bpf?] KASAN: stack-out-of-bounds Write in __bpf_get_stack syzbot
` (5 subsequent siblings)
9 siblings, 0 replies; 24+ messages in thread
From: Brahmajit Das @ 2025-11-10 21:16 UTC (permalink / raw)
To: syzbot+d1b7fa1092def3628bd7
Cc: andrii, ast, bpf, contact, daniel, eddyz87, haoluo,
john.fastabend, jolsa, kpsingh, linux-kernel, martin.lau, netdev,
sdf, song, syzkaller-bugs, yonghong.song
syzbot reported a stack-out-of-bounds write in __bpf_get_stack()
triggered via bpf_get_stack() when capturing a kernel stack trace.
After the recent refactor that introduced stack_map_calculate_max_depth(),
the code in stack_map_get_build_id_offset() (and related helpers) stopped
clamping the number of trace entries (`trace_nr`) to the number of elements
that fit into the stack map value (`num_elem`).
As a result, if the captured stack contained more frames than the map value
can hold, the subsequent memcpy() would write past the end of the buffer,
triggering a KASAN report like:
BUG: KASAN: stack-out-of-bounds in __bpf_get_stack+0x...
Write of size N at addr ... by task syz-executor...
Restore the missing clamp by limiting `trace_nr` to `num_elem` before
computing the copy length. This mirrors the pre-refactor logic and ensures
we never copy more bytes than the destination buffer can hold.
No functional change intended beyond reintroducing the missing bound check.
Reported-by: syzbot+d1b7fa1092def3628bd7@syzkaller.appspotmail.com
Fixes: e17d62fedd10 ("bpf: Refactor stack map trace depth calculation into helper function")
Signed-off-by: Brahmajit Das <listout@listout.xyz>
---
kernel/bpf/stackmap.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
index 2365541c81dd..885130e4ab0d 100644
--- a/kernel/bpf/stackmap.c
+++ b/kernel/bpf/stackmap.c
@@ -480,6 +480,7 @@ static long __bpf_get_stack(struct pt_regs *regs, struct task_struct *task,
}
trace_nr = trace->nr - skip;
+ trace_nr = min_t(u32, trace_nr, size / elem_size);
copy_len = trace_nr * elem_size;
ips = trace->ip + skip;
--
2.51.2
^ permalink raw reply related [flat|nested] 24+ messages in thread* Forwarded: Re: [syzbot] [bpf?] KASAN: stack-out-of-bounds Write in __bpf_get_stack
2025-11-10 18:41 [syzbot] [bpf?] KASAN: stack-out-of-bounds Write in __bpf_get_stack syzbot
` (3 preceding siblings ...)
2025-11-10 21:16 ` [RFC bpf-next PATCH] bpf: Clamp trace length in __bpf_get_stack to fix OOB write Brahmajit Das
@ 2025-11-10 23:43 ` syzbot
2025-11-11 0:21 ` syzbot
` (4 subsequent siblings)
9 siblings, 0 replies; 24+ messages in thread
From: syzbot @ 2025-11-10 23:43 UTC (permalink / raw)
To: linux-kernel, syzkaller-bugs
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.
***
Subject: Re: [syzbot] [bpf?] KASAN: stack-out-of-bounds Write in __bpf_get_stack
Author: listout@listout.xyz
On 10.11.2025 10:41, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: f8c67d8550ee bpf: Use kmalloc_nolock() in range tree
> git tree: bpf-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=121a50b4580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=e46b8a1c645465a9
> dashboard link: https://syzkaller.appspot.com/bug?extid=d1b7fa1092def3628bd7
> compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12270412580000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=128bd084580000
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/d9e95bfbe4ee/disk-f8c67d85.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/0766b6dd0e91/vmlinux-f8c67d85.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/79089f9e9e93/bzImage-f8c67d85.xz
>
> The issue was bisected to:
>
> commit e17d62fedd10ae56e2426858bd0757da544dbc73
> Author: Arnaud Lecomte <contact@arnaud-lcm.com>
> Date: Sat Oct 25 19:28:58 2025 +0000
>
> bpf: Refactor stack map trace depth calculation into helper function
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1632d0b4580000
> final oops: https://syzkaller.appspot.com/x/report.txt?x=1532d0b4580000
> console output: https://syzkaller.appspot.com/x/log.txt?x=1132d0b4580000
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+d1b7fa1092def3628bd7@syzkaller.appspotmail.com
> Fixes: e17d62fedd10 ("bpf: Refactor stack map trace depth calculation into helper function")
>
> ==================================================================
> BUG: KASAN: stack-out-of-bounds in __bpf_get_stack+0x5a3/0xaa0 kernel/bpf/stackmap.c:493
> Write of size 168 at addr ffffc900030e73a8 by task syz.1.44/6108
#syz test
diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
index 885130e4ab0d..f9081de43689 100644
--- a/kernel/bpf/stackmap.c
+++ b/kernel/bpf/stackmap.c
@@ -480,7 +480,7 @@ static long __bpf_get_stack(struct pt_regs *regs, struct task_struct *task,
}
trace_nr = trace->nr - skip;
- trace_nr = min_t(u32, trace_nr, size / elem_size);
+ trace_nr = min_t(u32, trace_nr, max_depth - skip);
copy_len = trace_nr * elem_size;
ips = trace->ip + skip;
--
Regards,
listout
^ permalink raw reply related [flat|nested] 24+ messages in thread* Forwarded: Re: [syzbot] [bpf?] KASAN: stack-out-of-bounds Write in __bpf_get_stack
2025-11-10 18:41 [syzbot] [bpf?] KASAN: stack-out-of-bounds Write in __bpf_get_stack syzbot
` (4 preceding siblings ...)
2025-11-10 23:43 ` Forwarded: Re: [syzbot] [bpf?] KASAN: stack-out-of-bounds Write in __bpf_get_stack syzbot
@ 2025-11-11 0:21 ` syzbot
2025-11-11 0:37 ` [PATCH bpf-next v2] bpf: Clamp trace length in __bpf_get_stack to fix OOB write Brahmajit Das
` (3 subsequent siblings)
9 siblings, 0 replies; 24+ messages in thread
From: syzbot @ 2025-11-11 0:21 UTC (permalink / raw)
To: linux-kernel, syzkaller-bugs
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.
***
Subject: Re: [syzbot] [bpf?] KASAN: stack-out-of-bounds Write in __bpf_get_stack
Author: listout@listout.xyz
On 10.11.2025 10:41, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: f8c67d8550ee bpf: Use kmalloc_nolock() in range tree
> git tree: bpf-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=121a50b4580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=e46b8a1c645465a9
> dashboard link: https://syzkaller.appspot.com/bug?extid=d1b7fa1092def3628bd7
> compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12270412580000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=128bd084580000
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/d9e95bfbe4ee/disk-f8c67d85.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/0766b6dd0e91/vmlinux-f8c67d85.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/79089f9e9e93/bzImage-f8c67d85.xz
>
> The issue was bisected to:
>
> commit e17d62fedd10ae56e2426858bd0757da544dbc73
> Author: Arnaud Lecomte <contact@arnaud-lcm.com>
> Date: Sat Oct 25 19:28:58 2025 +0000
>
> bpf: Refactor stack map trace depth calculation into helper function
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1632d0b4580000
> final oops: https://syzkaller.appspot.com/x/report.txt?x=1532d0b4580000
> console output: https://syzkaller.appspot.com/x/log.txt?x=1132d0b4580000
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+d1b7fa1092def3628bd7@syzkaller.appspotmail.com
> Fixes: e17d62fedd10 ("bpf: Refactor stack map trace depth calculation into helper function")
>
> ==================================================================
> BUG: KASAN: stack-out-of-bounds in __bpf_get_stack+0x5a3/0xaa0 kernel/bpf/stackmap.c:493
> Write of size 168 at addr ffffc900030e73a8 by task syz.1.44/6108
#syz test
diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
index 2365541c81dd..f9081de43689 100644
--- a/kernel/bpf/stackmap.c
+++ b/kernel/bpf/stackmap.c
@@ -480,6 +480,7 @@ static long __bpf_get_stack(struct pt_regs *regs, struct task_struct *task,
}
trace_nr = trace->nr - skip;
+ trace_nr = min_t(u32, trace_nr, max_depth - skip);
copy_len = trace_nr * elem_size;
ips = trace->ip + skip;
--
Regards,
listout
^ permalink raw reply related [flat|nested] 24+ messages in thread* [PATCH bpf-next v2] bpf: Clamp trace length in __bpf_get_stack to fix OOB write
2025-11-10 18:41 [syzbot] [bpf?] KASAN: stack-out-of-bounds Write in __bpf_get_stack syzbot
` (5 preceding siblings ...)
2025-11-11 0:21 ` syzbot
@ 2025-11-11 0:37 ` Brahmajit Das
2025-11-11 1:04 ` bot+bpf-ci
2025-11-11 8:12 ` [PATCH bpf-next v3] " Brahmajit Das
` (2 subsequent siblings)
9 siblings, 1 reply; 24+ messages in thread
From: Brahmajit Das @ 2025-11-11 0:37 UTC (permalink / raw)
To: syzbot+d1b7fa1092def3628bd7
Cc: andrii, ast, bpf, contact, daniel, eddyz87, haoluo,
john.fastabend, jolsa, kpsingh, linux-kernel, martin.lau, netdev,
sdf, song, syzkaller-bugs, yonghong.song
syzbot reported a stack-out-of-bounds write in __bpf_get_stack()
triggered via bpf_get_stack() when capturing a kernel stack trace.
After the recent refactor that introduced stack_map_calculate_max_depth(),
the code in stack_map_get_build_id_offset() (and related helpers) stopped
clamping the number of trace entries (`trace_nr`) to the number of elements
that fit into the stack map value (`num_elem`).
As a result, if the captured stack contained more frames than the map value
can hold, the subsequent memcpy() would write past the end of the buffer,
triggering a KASAN report like:
BUG: KASAN: stack-out-of-bounds in __bpf_get_stack+0x...
Write of size N at addr ... by task syz-executor...
Restore the missing clamp by limiting `trace_nr` to `num_elem` before
computing the copy length. This mirrors the pre-refactor logic and ensures
we never copy more bytes than the destination buffer can hold.
No functional change intended beyond reintroducing the missing bound check.
Reported-by: syzbot+d1b7fa1092def3628bd7@syzkaller.appspotmail.com
Fixes: e17d62fedd10 ("bpf: Refactor stack map trace depth calculation into helper function")
Signed-off-by: Brahmajit Das <listout@listout.xyz>
---
Changes in v2:
- Use max_depth instead of num_elem logic, this logic is similar to what
we are already using __bpf_get_stackid
Changes in v1:
- RFC patch that restores the number of trace entries by setting
trace_nr to trace_nr or num_elem based on whichever is the smallest.
Link: https://lore.kernel.org/all/20251110211640.963-1-listout@listout.xyz/
---
kernel/bpf/stackmap.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
index 2365541c81dd..f9081de43689 100644
--- a/kernel/bpf/stackmap.c
+++ b/kernel/bpf/stackmap.c
@@ -480,6 +480,7 @@ static long __bpf_get_stack(struct pt_regs *regs, struct task_struct *task,
}
trace_nr = trace->nr - skip;
+ trace_nr = min_t(u32, trace_nr, max_depth - skip);
copy_len = trace_nr * elem_size;
ips = trace->ip + skip;
--
2.51.2
^ permalink raw reply related [flat|nested] 24+ messages in thread* Re: [PATCH bpf-next v2] bpf: Clamp trace length in __bpf_get_stack to fix OOB write
2025-11-11 0:37 ` [PATCH bpf-next v2] bpf: Clamp trace length in __bpf_get_stack to fix OOB write Brahmajit Das
@ 2025-11-11 1:04 ` bot+bpf-ci
0 siblings, 0 replies; 24+ messages in thread
From: bot+bpf-ci @ 2025-11-11 1:04 UTC (permalink / raw)
To: listout, syzbot+d1b7fa1092def3628bd7
Cc: andrii, ast, bpf, contact, daniel, eddyz87, haoluo,
john.fastabend, jolsa, kpsingh, linux-kernel, martin.lau, netdev,
sdf, song, syzkaller-bugs, yonghong.song, ast, andrii, daniel,
martin.lau, eddyz87, yonghong.song, clm, ihor.solodrai
[-- Attachment #1: Type: text/plain, Size: 1828 bytes --]
> diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
> index 2365541c8..f9081de43 100644
> --- a/kernel/bpf/stackmap.c
> +++ b/kernel/bpf/stackmap.c
> @@ -480,6 +480,7 @@ static long __bpf_get_stack(struct pt_regs *regs, struct task_struct *task,
> }
>
> trace_nr = trace->nr - skip;
> + trace_nr = min_t(u32, trace_nr, max_depth - skip);
> copy_len = trace_nr * elem_size;
>
> ips = trace->ip + skip;
Can max_depth - skip underflow when max_depth < skip?
The stack_map_calculate_max_depth() function can return a value less than
skip when sysctl_perf_event_max_stack is lowered below the skip value:
max_depth = size / elem_size;
max_depth += skip;
if (max_depth > curr_sysctl_max_stack)
return curr_sysctl_max_stack;
If sysctl_perf_event_max_stack = 10 and skip = 20, this returns 10.
Then max_depth - skip = 10 - 20 underflows to 4294967286 (u32 wraps),
causing min_t() to not limit trace_nr at all. This means the original OOB
write is not fixed in cases where skip > max_depth.
With the default sysctl_perf_event_max_stack = 127 and skip up to 255, this
scenario is reachable even without admin changing sysctls.
The pre-refactor code used:
num_elem = size / elem_size;
trace_nr = (trace_nr <= num_elem) ? trace_nr : num_elem;
Perhaps the fix should directly use num_elem instead of max_depth - skip:
u32 num_elem = size / elem_size;
trace_nr = min_t(u32, trace_nr, num_elem);
Or check for underflow:
if (max_depth > skip)
trace_nr = min_t(u32, trace_nr, max_depth - skip);
else
trace_nr = 0;
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/19251115736
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH bpf-next v3] bpf: Clamp trace length in __bpf_get_stack to fix OOB write
2025-11-10 18:41 [syzbot] [bpf?] KASAN: stack-out-of-bounds Write in __bpf_get_stack syzbot
` (6 preceding siblings ...)
2025-11-11 0:37 ` [PATCH bpf-next v2] bpf: Clamp trace length in __bpf_get_stack to fix OOB write Brahmajit Das
@ 2025-11-11 8:12 ` Brahmajit Das
2025-11-12 1:44 ` Yonghong Song
` (2 more replies)
2026-01-04 18:29 ` #syz test Arnaud Lecomte
2026-01-04 18:30 ` #syz test Arnaud Lecomte
9 siblings, 3 replies; 24+ messages in thread
From: Brahmajit Das @ 2025-11-11 8:12 UTC (permalink / raw)
To: syzbot+d1b7fa1092def3628bd7
Cc: andrii, ast, bpf, contact, daniel, eddyz87, haoluo,
john.fastabend, jolsa, kpsingh, linux-kernel, martin.lau, netdev,
sdf, song, syzkaller-bugs, yonghong.song
syzbot reported a stack-out-of-bounds write in __bpf_get_stack()
triggered via bpf_get_stack() when capturing a kernel stack trace.
After the recent refactor that introduced stack_map_calculate_max_depth(),
the code in stack_map_get_build_id_offset() (and related helpers) stopped
clamping the number of trace entries (`trace_nr`) to the number of elements
that fit into the stack map value (`num_elem`).
As a result, if the captured stack contained more frames than the map value
can hold, the subsequent memcpy() would write past the end of the buffer,
triggering a KASAN report like:
BUG: KASAN: stack-out-of-bounds in __bpf_get_stack+0x...
Write of size N at addr ... by task syz-executor...
Restore the missing clamp by limiting `trace_nr` to `num_elem` before
computing the copy length. This mirrors the pre-refactor logic and ensures
we never copy more bytes than the destination buffer can hold.
No functional change intended beyond reintroducing the missing bound check.
Reported-by: syzbot+d1b7fa1092def3628bd7@syzkaller.appspotmail.com
Fixes: e17d62fedd10 ("bpf: Refactor stack map trace depth calculation into helper function")
Signed-off-by: Brahmajit Das <listout@listout.xyz>
---
Changes in v3:
Revert back to num_elem based logic for setting trace_nr. This was
suggested by bpf-ci bot, mainly pointing out the chances of underflow
when max_depth < skip.
Quoting the bot's reply:
The stack_map_calculate_max_depth() function can return a value less than
skip when sysctl_perf_event_max_stack is lowered below the skip value:
max_depth = size / elem_size;
max_depth += skip;
if (max_depth > curr_sysctl_max_stack)
return curr_sysctl_max_stack;
If sysctl_perf_event_max_stack = 10 and skip = 20, this returns 10.
Then max_depth - skip = 10 - 20 underflows to 4294967286 (u32 wraps),
causing min_t() to not limit trace_nr at all. This means the original OOB
write is not fixed in cases where skip > max_depth.
With the default sysctl_perf_event_max_stack = 127 and skip up to 255, this
scenario is reachable even without admin changing sysctls.
Changes in v2:
- Use max_depth instead of num_elem logic, this logic is similar to what
we are already using __bpf_get_stackid
Link: https://lore.kernel.org/all/20251111003721.7629-1-listout@listout.xyz/
Changes in v1:
- RFC patch that restores the number of trace entries by setting
trace_nr to trace_nr or num_elem based on whichever is the smallest.
Link: https://lore.kernel.org/all/20251110211640.963-1-listout@listout.xyz/
---
kernel/bpf/stackmap.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
index 2365541c81dd..cef79d9517ab 100644
--- a/kernel/bpf/stackmap.c
+++ b/kernel/bpf/stackmap.c
@@ -426,7 +426,7 @@ static long __bpf_get_stack(struct pt_regs *regs, struct task_struct *task,
struct perf_callchain_entry *trace_in,
void *buf, u32 size, u64 flags, bool may_fault)
{
- u32 trace_nr, copy_len, elem_size, max_depth;
+ u32 trace_nr, copy_len, elem_size, num_elem, max_depth;
bool user_build_id = flags & BPF_F_USER_BUILD_ID;
bool crosstask = task && task != current;
u32 skip = flags & BPF_F_SKIP_FIELD_MASK;
@@ -480,6 +480,8 @@ static long __bpf_get_stack(struct pt_regs *regs, struct task_struct *task,
}
trace_nr = trace->nr - skip;
+ num_elem = size / elem_size;
+ trace_nr = min_t(u32, trace_nr, num_elem);
copy_len = trace_nr * elem_size;
ips = trace->ip + skip;
--
2.51.2
^ permalink raw reply related [flat|nested] 24+ messages in thread* Re: [PATCH bpf-next v3] bpf: Clamp trace length in __bpf_get_stack to fix OOB write
2025-11-11 8:12 ` [PATCH bpf-next v3] " Brahmajit Das
@ 2025-11-12 1:44 ` Yonghong Song
2025-11-12 8:40 ` Lecomte, Arnaud
2025-11-12 13:35 ` David Laight
2 siblings, 0 replies; 24+ messages in thread
From: Yonghong Song @ 2025-11-12 1:44 UTC (permalink / raw)
To: Brahmajit Das, syzbot+d1b7fa1092def3628bd7
Cc: andrii, ast, bpf, contact, daniel, eddyz87, haoluo,
john.fastabend, jolsa, kpsingh, linux-kernel, martin.lau, netdev,
sdf, song, syzkaller-bugs
On 11/11/25 12:12 AM, Brahmajit Das wrote:
> syzbot reported a stack-out-of-bounds write in __bpf_get_stack()
> triggered via bpf_get_stack() when capturing a kernel stack trace.
>
> After the recent refactor that introduced stack_map_calculate_max_depth(),
> the code in stack_map_get_build_id_offset() (and related helpers) stopped
> clamping the number of trace entries (`trace_nr`) to the number of elements
> that fit into the stack map value (`num_elem`).
>
> As a result, if the captured stack contained more frames than the map value
> can hold, the subsequent memcpy() would write past the end of the buffer,
> triggering a KASAN report like:
>
> BUG: KASAN: stack-out-of-bounds in __bpf_get_stack+0x...
> Write of size N at addr ... by task syz-executor...
>
> Restore the missing clamp by limiting `trace_nr` to `num_elem` before
> computing the copy length. This mirrors the pre-refactor logic and ensures
> we never copy more bytes than the destination buffer can hold.
>
> No functional change intended beyond reintroducing the missing bound check.
>
> Reported-by: syzbot+d1b7fa1092def3628bd7@syzkaller.appspotmail.com
> Fixes: e17d62fedd10 ("bpf: Refactor stack map trace depth calculation into helper function")
> Signed-off-by: Brahmajit Das <listout@listout.xyz>
Acked-by: Yonghong Song <yonghong.song@linux.dev>
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH bpf-next v3] bpf: Clamp trace length in __bpf_get_stack to fix OOB write
2025-11-11 8:12 ` [PATCH bpf-next v3] " Brahmajit Das
2025-11-12 1:44 ` Yonghong Song
@ 2025-11-12 8:40 ` Lecomte, Arnaud
2025-11-12 8:58 ` Brahmajit Das
2025-11-13 12:49 ` Brahmajit Das
2025-11-12 13:35 ` David Laight
2 siblings, 2 replies; 24+ messages in thread
From: Lecomte, Arnaud @ 2025-11-12 8:40 UTC (permalink / raw)
To: Brahmajit Das, syzbot+d1b7fa1092def3628bd7
Cc: andrii, ast, bpf, daniel, eddyz87, haoluo, john.fastabend, jolsa,
kpsingh, linux-kernel, martin.lau, netdev, sdf, song,
syzkaller-bugs, yonghong.song
I am a not sure this is the right solution and I am scared that by
forcing this clamping, we are hiding something else.
If we have a look at the code below:
```
|
if (trace_in) {
trace = trace_in;
trace->nr = min_t(u32, trace->nr, max_depth);
} else if (kernel && task) {
trace = get_callchain_entry_for_task(task, max_depth);
} else {
trace = get_perf_callchain(regs, kernel, user, max_depth,
crosstask, false, 0);
} ``` trace should be (if I remember correctly) clamped there. If not,
it might hide something else. I would like to have a look at the return
for each if case through gdb. |
On 11/11/2025 08:12, Brahmajit Das wrote:
> syzbot reported a stack-out-of-bounds write in __bpf_get_stack()
> triggered via bpf_get_stack() when capturing a kernel stack trace.
>
> After the recent refactor that introduced stack_map_calculate_max_depth(),
> the code in stack_map_get_build_id_offset() (and related helpers) stopped
> clamping the number of trace entries (`trace_nr`) to the number of elements
> that fit into the stack map value (`num_elem`).
>
> As a result, if the captured stack contained more frames than the map value
> can hold, the subsequent memcpy() would write past the end of the buffer,
> triggering a KASAN report like:
>
> BUG: KASAN: stack-out-of-bounds in __bpf_get_stack+0x...
> Write of size N at addr ... by task syz-executor...
>
> Restore the missing clamp by limiting `trace_nr` to `num_elem` before
> computing the copy length. This mirrors the pre-refactor logic and ensures
> we never copy more bytes than the destination buffer can hold.
>
> No functional change intended beyond reintroducing the missing bound check.
>
> Reported-by: syzbot+d1b7fa1092def3628bd7@syzkaller.appspotmail.com
> Fixes: e17d62fedd10 ("bpf: Refactor stack map trace depth calculation into helper function")
> Signed-off-by: Brahmajit Das <listout@listout.xyz>
> ---
> Changes in v3:
> Revert back to num_elem based logic for setting trace_nr. This was
> suggested by bpf-ci bot, mainly pointing out the chances of underflow
> when max_depth < skip.
>
> Quoting the bot's reply:
> The stack_map_calculate_max_depth() function can return a value less than
> skip when sysctl_perf_event_max_stack is lowered below the skip value:
>
> max_depth = size / elem_size;
> max_depth += skip;
> if (max_depth > curr_sysctl_max_stack)
> return curr_sysctl_max_stack;
>
> If sysctl_perf_event_max_stack = 10 and skip = 20, this returns 10.
>
> Then max_depth - skip = 10 - 20 underflows to 4294967286 (u32 wraps),
> causing min_t() to not limit trace_nr at all. This means the original OOB
> write is not fixed in cases where skip > max_depth.
>
> With the default sysctl_perf_event_max_stack = 127 and skip up to 255, this
> scenario is reachable even without admin changing sysctls.
>
> Changes in v2:
> - Use max_depth instead of num_elem logic, this logic is similar to what
> we are already using __bpf_get_stackid
> Link: https://lore.kernel.org/all/20251111003721.7629-1-listout@listout.xyz/
>
> Changes in v1:
> - RFC patch that restores the number of trace entries by setting
> trace_nr to trace_nr or num_elem based on whichever is the smallest.
> Link: https://lore.kernel.org/all/20251110211640.963-1-listout@listout.xyz/
> ---
> kernel/bpf/stackmap.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
> index 2365541c81dd..cef79d9517ab 100644
> --- a/kernel/bpf/stackmap.c
> +++ b/kernel/bpf/stackmap.c
> @@ -426,7 +426,7 @@ static long __bpf_get_stack(struct pt_regs *regs, struct task_struct *task,
> struct perf_callchain_entry *trace_in,
> void *buf, u32 size, u64 flags, bool may_fault)
> {
> - u32 trace_nr, copy_len, elem_size, max_depth;
> + u32 trace_nr, copy_len, elem_size, num_elem, max_depth;
> bool user_build_id = flags & BPF_F_USER_BUILD_ID;
> bool crosstask = task && task != current;
> u32 skip = flags & BPF_F_SKIP_FIELD_MASK;
> @@ -480,6 +480,8 @@ static long __bpf_get_stack(struct pt_regs *regs, struct task_struct *task,
> }
>
> trace_nr = trace->nr - skip;
> + num_elem = size / elem_size;
> + trace_nr = min_t(u32, trace_nr, num_elem);
> copy_len = trace_nr * elem_size;
>
> ips = trace->ip + skip;
Thanks,
Arnaud
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH bpf-next v3] bpf: Clamp trace length in __bpf_get_stack to fix OOB write
2025-11-12 8:40 ` Lecomte, Arnaud
@ 2025-11-12 8:58 ` Brahmajit Das
2025-11-13 12:49 ` Brahmajit Das
1 sibling, 0 replies; 24+ messages in thread
From: Brahmajit Das @ 2025-11-12 8:58 UTC (permalink / raw)
To: Lecomte, Arnaud
Cc: syzbot+d1b7fa1092def3628bd7, andrii, ast, bpf, daniel, eddyz87,
haoluo, john.fastabend, jolsa, kpsingh, linux-kernel, martin.lau,
netdev, sdf, song, syzkaller-bugs, yonghong.song
On 12.11.2025 08:40, 'Lecomte, Arnaud' via syzkaller-bugs wrote:
> I am a not sure this is the right solution and I am scared that by
> forcing this clamping, we are hiding something else.
> If we have a look at the code below:
> ```
>
> |
>
> if (trace_in) {
> trace = trace_in;
> trace->nr = min_t(u32, trace->nr, max_depth);
> } else if (kernel && task) {
> trace = get_callchain_entry_for_task(task, max_depth);
> } else {
> trace = get_perf_callchain(regs, kernel, user, max_depth,
> crosstask, false, 0);
> } ``` trace should be (if I remember correctly) clamped there. If not, it
> might hide something else. I would like to have a look at the return for
> each if case through gdb. |
Sure, I can do that.
>
> Thanks,
> Arnaud
--
Regards,
listout
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH bpf-next v3] bpf: Clamp trace length in __bpf_get_stack to fix OOB write
2025-11-12 8:40 ` Lecomte, Arnaud
2025-11-12 8:58 ` Brahmajit Das
@ 2025-11-13 12:49 ` Brahmajit Das
2025-11-13 13:26 ` Lecomte, Arnaud
1 sibling, 1 reply; 24+ messages in thread
From: Brahmajit Das @ 2025-11-13 12:49 UTC (permalink / raw)
To: Lecomte, Arnaud
Cc: syzbot+d1b7fa1092def3628bd7, andrii, ast, bpf, daniel, eddyz87,
haoluo, john.fastabend, jolsa, kpsingh, linux-kernel, martin.lau,
netdev, sdf, song, syzkaller-bugs, yonghong.song
On 12.11.2025 08:40, 'Lecomte, Arnaud' via syzkaller-bugs wrote:
> I am a not sure this is the right solution and I am scared that by
> forcing this clamping, we are hiding something else.
> If we have a look at the code below:
> ```
>
> |
>
> if (trace_in) {
> trace = trace_in;
> trace->nr = min_t(u32, trace->nr, max_depth);
> } else if (kernel && task) {
> trace = get_callchain_entry_for_task(task, max_depth);
> } else {
> trace = get_perf_callchain(regs, kernel, user, max_depth,
> crosstask, false, 0);
> } ``` trace should be (if I remember correctly) clamped there. If not, it
> might hide something else. I would like to have a look at the return for
> each if case through gdb. |
Hi Arnaud,
So I've been debugging this the reproducer always takes the else branch
so trace holds whatever get_perf_callchain returns; in this situation.
I mostly found it to be a value around 4.
In some case the value would exceed to something 27 or 44, just after
the code block
if (unlikely(!trace) || trace->nr < skip) {
if (may_fault)
rcu_read_unlock();
goto err_fault;
}
So I'm assuming there's some race condition that might be going on
somewhere.
I'm still debugging bug I'm open to ideas and definitely I could be
wrong here, please feel free to correct/point out.
--
Regards,
listout
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH bpf-next v3] bpf: Clamp trace length in __bpf_get_stack to fix OOB write
2025-11-13 12:49 ` Brahmajit Das
@ 2025-11-13 13:26 ` Lecomte, Arnaud
2025-11-13 13:49 ` Brahmajit Das
0 siblings, 1 reply; 24+ messages in thread
From: Lecomte, Arnaud @ 2025-11-13 13:26 UTC (permalink / raw)
To: Brahmajit Das
Cc: syzbot+d1b7fa1092def3628bd7, andrii, ast, bpf, daniel, eddyz87,
haoluo, john.fastabend, jolsa, kpsingh, linux-kernel, martin.lau,
netdev, sdf, song, syzkaller-bugs, yonghong.song
On 13/11/2025 12:49, Brahmajit Das wrote:
> On 12.11.2025 08:40, 'Lecomte, Arnaud' via syzkaller-bugs wrote:
>> I am a not sure this is the right solution and I am scared that by
>> forcing this clamping, we are hiding something else.
>> If we have a look at the code below:
>> ```
>>
>> |
>>
>> if (trace_in) {
>> trace = trace_in;
>> trace->nr = min_t(u32, trace->nr, max_depth);
>> } else if (kernel && task) {
>> trace = get_callchain_entry_for_task(task, max_depth);
>> } else {
>> trace = get_perf_callchain(regs, kernel, user, max_depth,
>> crosstask, false, 0);
>> } ``` trace should be (if I remember correctly) clamped there. If not, it
>> might hide something else. I would like to have a look at the return for
>> each if case through gdb. |
> Hi Arnaud,
> So I've been debugging this the reproducer always takes the else branch
> so trace holds whatever get_perf_callchain returns; in this situation.
>
> I mostly found it to be a value around 4.
>
> In some case the value would exceed to something 27 or 44, just after
> the code block
>
> if (unlikely(!trace) || trace->nr < skip) {
> if (may_fault)
> rcu_read_unlock();
> goto err_fault;
> }
>
> So I'm assuming there's some race condition that might be going on
> somewhere.
Which value ? trace->nr ?
> I'm still debugging bug I'm open to ideas and definitely I could be
> wrong here, please feel free to correct/point out.
I should be able to have a look tomorrow evening as I am currently a bit
overloaded
with my work.
Thanks,
Arnaud
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH bpf-next v3] bpf: Clamp trace length in __bpf_get_stack to fix OOB write
2025-11-13 13:26 ` Lecomte, Arnaud
@ 2025-11-13 13:49 ` Brahmajit Das
0 siblings, 0 replies; 24+ messages in thread
From: Brahmajit Das @ 2025-11-13 13:49 UTC (permalink / raw)
To: Lecomte, Arnaud
Cc: syzbot+d1b7fa1092def3628bd7, andrii, ast, bpf, daniel, eddyz87,
haoluo, john.fastabend, jolsa, kpsingh, linux-kernel, martin.lau,
netdev, sdf, song, syzkaller-bugs, yonghong.song
On 13.11.2025 13:26, Lecomte, Arnaud wrote:
>
> On 13/11/2025 12:49, Brahmajit Das wrote:
> > On 12.11.2025 08:40, 'Lecomte, Arnaud' via syzkaller-bugs wrote:
> > > I am a not sure this is the right solution and I am scared that by
> > > forcing this clamping, we are hiding something else.
> > > If we have a look at the code below:
...snip...
> > > might hide something else. I would like to have a look at the return for
> > > each if case through gdb. |
> > Hi Arnaud,
> > So I've been debugging this the reproducer always takes the else branch
> > so trace holds whatever get_perf_callchain returns; in this situation.
> >
> > I mostly found it to be a value around 4.
> >
> > In some case the value would exceed to something 27 or 44, just after
> > the code block
> >
> > if (unlikely(!trace) || trace->nr < skip) {
> > if (may_fault)
> > rcu_read_unlock();
> > goto err_fault;
> > }
> >
> > So I'm assuming there's some race condition that might be going on
> > somewhere.
> Which value ? trace->nr ?
Yep, trace->nr
> > I'm still debugging bug I'm open to ideas and definitely I could be
> > wrong here, please feel free to correct/point out.
>
> I should be able to have a look tomorrow evening as I am currently a bit
> overloaded
> with my work.
Awesome, thank you. I'll try to dig around a bit more meanwhile.
--
Regards,
listout
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH bpf-next v3] bpf: Clamp trace length in __bpf_get_stack to fix OOB write
2025-11-11 8:12 ` [PATCH bpf-next v3] " Brahmajit Das
2025-11-12 1:44 ` Yonghong Song
2025-11-12 8:40 ` Lecomte, Arnaud
@ 2025-11-12 13:35 ` David Laight
2025-11-12 14:47 ` Brahmajit Das
2 siblings, 1 reply; 24+ messages in thread
From: David Laight @ 2025-11-12 13:35 UTC (permalink / raw)
To: Brahmajit Das
Cc: syzbot+d1b7fa1092def3628bd7, andrii, ast, bpf, contact, daniel,
eddyz87, haoluo, john.fastabend, jolsa, kpsingh, linux-kernel,
martin.lau, netdev, sdf, song, syzkaller-bugs, yonghong.song
On Tue, 11 Nov 2025 13:42:54 +0530
Brahmajit Das <listout@listout.xyz> wrote:
> syzbot reported a stack-out-of-bounds write in __bpf_get_stack()
> triggered via bpf_get_stack() when capturing a kernel stack trace.
>
> After the recent refactor that introduced stack_map_calculate_max_depth(),
> the code in stack_map_get_build_id_offset() (and related helpers) stopped
> clamping the number of trace entries (`trace_nr`) to the number of elements
> that fit into the stack map value (`num_elem`).
>
> As a result, if the captured stack contained more frames than the map value
> can hold, the subsequent memcpy() would write past the end of the buffer,
> triggering a KASAN report like:
>
> BUG: KASAN: stack-out-of-bounds in __bpf_get_stack+0x...
> Write of size N at addr ... by task syz-executor...
>
> Restore the missing clamp by limiting `trace_nr` to `num_elem` before
> computing the copy length. This mirrors the pre-refactor logic and ensures
> we never copy more bytes than the destination buffer can hold.
>
> No functional change intended beyond reintroducing the missing bound check.
>
> Reported-by: syzbot+d1b7fa1092def3628bd7@syzkaller.appspotmail.com
> Fixes: e17d62fedd10 ("bpf: Refactor stack map trace depth calculation into helper function")
> Signed-off-by: Brahmajit Das <listout@listout.xyz>
> ---
> Changes in v3:
> Revert back to num_elem based logic for setting trace_nr. This was
> suggested by bpf-ci bot, mainly pointing out the chances of underflow
> when max_depth < skip.
>
> Quoting the bot's reply:
> The stack_map_calculate_max_depth() function can return a value less than
> skip when sysctl_perf_event_max_stack is lowered below the skip value:
>
> max_depth = size / elem_size;
> max_depth += skip;
> if (max_depth > curr_sysctl_max_stack)
> return curr_sysctl_max_stack;
>
> If sysctl_perf_event_max_stack = 10 and skip = 20, this returns 10.
>
> Then max_depth - skip = 10 - 20 underflows to 4294967286 (u32 wraps),
> causing min_t() to not limit trace_nr at all. This means the original OOB
> write is not fixed in cases where skip > max_depth.
>
> With the default sysctl_perf_event_max_stack = 127 and skip up to 255, this
> scenario is reachable even without admin changing sysctls.
>
> Changes in v2:
> - Use max_depth instead of num_elem logic, this logic is similar to what
> we are already using __bpf_get_stackid
> Link: https://lore.kernel.org/all/20251111003721.7629-1-listout@listout.xyz/
>
> Changes in v1:
> - RFC patch that restores the number of trace entries by setting
> trace_nr to trace_nr or num_elem based on whichever is the smallest.
> Link: https://lore.kernel.org/all/20251110211640.963-1-listout@listout.xyz/
> ---
> kernel/bpf/stackmap.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
> index 2365541c81dd..cef79d9517ab 100644
> --- a/kernel/bpf/stackmap.c
> +++ b/kernel/bpf/stackmap.c
> @@ -426,7 +426,7 @@ static long __bpf_get_stack(struct pt_regs *regs, struct task_struct *task,
> struct perf_callchain_entry *trace_in,
> void *buf, u32 size, u64 flags, bool may_fault)
> {
> - u32 trace_nr, copy_len, elem_size, max_depth;
> + u32 trace_nr, copy_len, elem_size, num_elem, max_depth;
> bool user_build_id = flags & BPF_F_USER_BUILD_ID;
> bool crosstask = task && task != current;
> u32 skip = flags & BPF_F_SKIP_FIELD_MASK;
> @@ -480,6 +480,8 @@ static long __bpf_get_stack(struct pt_regs *regs, struct task_struct *task,
> }
>
> trace_nr = trace->nr - skip;
> + num_elem = size / elem_size;
> + trace_nr = min_t(u32, trace_nr, num_elem);
Please can we have no unnecessary min_t().
You wouldn't write:
x = (u32)a < (u32)b ? (u32)a : (u32)b;
David
> copy_len = trace_nr * elem_size;
>
> ips = trace->ip + skip;
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH bpf-next v3] bpf: Clamp trace length in __bpf_get_stack to fix OOB write
2025-11-12 13:35 ` David Laight
@ 2025-11-12 14:47 ` Brahmajit Das
2025-11-12 16:11 ` Lecomte, Arnaud
0 siblings, 1 reply; 24+ messages in thread
From: Brahmajit Das @ 2025-11-12 14:47 UTC (permalink / raw)
To: David Laight
Cc: syzbot+d1b7fa1092def3628bd7, andrii, ast, bpf, contact, daniel,
eddyz87, haoluo, john.fastabend, jolsa, kpsingh, linux-kernel,
martin.lau, netdev, sdf, song, syzkaller-bugs, yonghong.song
On 12.11.2025 13:35, David Laight wrote:
> On Tue, 11 Nov 2025 13:42:54 +0530
> Brahmajit Das <listout@listout.xyz> wrote:
>
...snip...
>
> Please can we have no unnecessary min_t().
> You wouldn't write:
> x = (u32)a < (u32)b ? (u32)a : (u32)b;
>
> David
>
> > copy_len = trace_nr * elem_size;
> >
> > ips = trace->ip + skip;
>
Hi David,
Sorry, I didn't quite get that. Would prefer something like:
trace_nr = (trace_nr <= num_elem) ? trace_nr : num_elem;
The pre-refactor code.
--
Regards,
listout
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH bpf-next v3] bpf: Clamp trace length in __bpf_get_stack to fix OOB write
2025-11-12 14:47 ` Brahmajit Das
@ 2025-11-12 16:11 ` Lecomte, Arnaud
2025-11-12 21:37 ` David Laight
0 siblings, 1 reply; 24+ messages in thread
From: Lecomte, Arnaud @ 2025-11-12 16:11 UTC (permalink / raw)
To: Brahmajit Das, David Laight
Cc: syzbot+d1b7fa1092def3628bd7, andrii, ast, bpf, daniel, eddyz87,
haoluo, john.fastabend, jolsa, kpsingh, linux-kernel, martin.lau,
netdev, sdf, song, syzkaller-bugs, yonghong.song
On 12/11/2025 14:47, Brahmajit Das wrote:
> On 12.11.2025 13:35, David Laight wrote:
>> On Tue, 11 Nov 2025 13:42:54 +0530
>> Brahmajit Das <listout@listout.xyz> wrote:
>>
> ...snip...
>> Please can we have no unnecessary min_t().
>> You wouldn't write:
>> x = (u32)a < (u32)b ? (u32)a : (u32)b;
>>
>> David
>>
>>> copy_len = trace_nr * elem_size;
>>>
>>> ips = trace->ip + skip;
> Hi David,
>
> Sorry, I didn't quite get that. Would prefer something like:
> trace_nr = (trace_nr <= num_elem) ? trace_nr : num_elem;
min_t is a min with casting which is unnecessary in this case as
trace_nr and num_elem
are already u32.
> The pre-refactor code.
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH bpf-next v3] bpf: Clamp trace length in __bpf_get_stack to fix OOB write
2025-11-12 16:11 ` Lecomte, Arnaud
@ 2025-11-12 21:37 ` David Laight
0 siblings, 0 replies; 24+ messages in thread
From: David Laight @ 2025-11-12 21:37 UTC (permalink / raw)
To: Lecomte, Arnaud
Cc: Brahmajit Das, syzbot+d1b7fa1092def3628bd7, andrii, ast, bpf,
daniel, eddyz87, haoluo, john.fastabend, jolsa, kpsingh,
linux-kernel, martin.lau, netdev, sdf, song, syzkaller-bugs,
yonghong.song
On Wed, 12 Nov 2025 16:11:41 +0000
"Lecomte, Arnaud" <contact@arnaud-lcm.com> wrote:
> On 12/11/2025 14:47, Brahmajit Das wrote:
> > On 12.11.2025 13:35, David Laight wrote:
> >> On Tue, 11 Nov 2025 13:42:54 +0530
> >> Brahmajit Das <listout@listout.xyz> wrote:
> >>
> > ...snip...
> >> Please can we have no unnecessary min_t().
> >> You wouldn't write:
> >> x = (u32)a < (u32)b ? (u32)a : (u32)b;
> >>
> >> David
> >>
> >>> copy_len = trace_nr * elem_size;
> >>>
> >>> ips = trace->ip + skip;
> > Hi David,
> >
> > Sorry, I didn't quite get that. Would prefer something like:
> > trace_nr = (trace_nr <= num_elem) ? trace_nr : num_elem;
>
> min_t is a min with casting which is unnecessary in this case as
> trace_nr and num_elem are already u32.
Correct
David
>
> > The pre-refactor code.
> >
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* #syz test
2025-11-10 18:41 [syzbot] [bpf?] KASAN: stack-out-of-bounds Write in __bpf_get_stack syzbot
` (7 preceding siblings ...)
2025-11-11 8:12 ` [PATCH bpf-next v3] " Brahmajit Das
@ 2026-01-04 18:29 ` Arnaud Lecomte
2026-01-04 20:09 ` [syzbot] [bpf?] KASAN: stack-out-of-bounds Write in __bpf_get_stack syzbot
2026-01-04 18:30 ` #syz test Arnaud Lecomte
9 siblings, 1 reply; 24+ messages in thread
From: Arnaud Lecomte @ 2026-01-04 18:29 UTC (permalink / raw)
To: syzbot+d1b7fa1092def3628bd7; +Cc: contact, linux-kernel, syzkaller-bugs
diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
index 2365541c81dd..b8ff4ccae2d6 100644
--- a/kernel/bpf/stackmap.c
+++ b/kernel/bpf/stackmap.c
@@ -465,7 +465,6 @@ static long __bpf_get_stack(struct pt_regs *regs, struct task_struct *task,
if (trace_in) {
trace = trace_in;
- trace->nr = min_t(u32, trace->nr, max_depth);
} else if (kernel && task) {
trace = get_callchain_entry_for_task(task, max_depth);
} else {
@@ -479,7 +478,8 @@ static long __bpf_get_stack(struct pt_regs *regs, struct task_struct *task,
goto err_fault;
}
- trace_nr = trace->nr - skip;
+ trace_nr = min(trace->nr, max_depth);
+ trace_nr = trace_nr - skip;
copy_len = trace_nr * elem_size;
ips = trace->ip + skip;
--
2.43.0
^ permalink raw reply related [flat|nested] 24+ messages in thread* Re: [syzbot] [bpf?] KASAN: stack-out-of-bounds Write in __bpf_get_stack
2026-01-04 18:29 ` #syz test Arnaud Lecomte
@ 2026-01-04 20:09 ` syzbot
0 siblings, 0 replies; 24+ messages in thread
From: syzbot @ 2026-01-04 20:09 UTC (permalink / raw)
To: contact, linux-kernel, syzkaller-bugs
Hello,
syzbot tried to test the proposed patch but the build/boot failed:
SYZFAIL: failed to recv rpc
SYZFAIL: failed to recv rpc
fd=3 want=4 recv=0 n=0 (errno 9: Bad file descriptor)
Warning: Permanently added '10.128.0.125' (ED25519) to the list of known hosts.
2026/01/04 20:08:05 parsed 1 programs
[ 79.730779][ T5830] cgroup: Unknown subsys name 'net'
[ 79.857873][ T5830] cgroup: Unknown subsys name 'cpuset'
[ 79.866524][ T5830] cgroup: Unknown subsys name 'rlimit'
Setting up swapspace version 1, size = 127995904 bytes
[ 81.320295][ T5830] Adding 124996k swap on ./swap-file. Priority:0 extents:1 across:124996k
[ 84.221144][ T5848] soft_limit_in_bytes is deprecated and will be removed. Please report your usecase to linux-mm@kvack.org if you depend on this functionality.
[ 84.415568][ T5850] chnl_net:caif_netlink_parms(): no params data found
[ 84.924026][ T5850] bridge0: port 1(bridge_slave_0) entered blocking state
[ 84.939498][ T5850] bridge0: port 1(bridge_slave_0) entered disabled state
[ 84.954819][ T5850] bridge_slave_0: entered allmulticast mode
[ 84.966272][ T5850] bridge_slave_0: entered promiscuous mode
[ 85.069500][ T5850] bridge0: port 2(bridge_slave_1) entered blocking state
[ 85.083944][ T5850] bridge0: port 2(bridge_slave_1) entered disabled state
[ 85.091552][ T5850] bridge_slave_1: entered allmulticast mode
[ 85.099656][ T5850] bridge_slave_1: entered promiscuous mode
[ 85.261717][ T5850] bond0: (slave bond_slave_0): Enslaving as an active interface with an up link
[ 85.274934][ T5850] bond0: (slave bond_slave_1): Enslaving as an active interface with an up link
[ 85.565286][ T5850] team0: Port device team_slave_0 added
[ 85.646765][ T5850] team0: Port device team_slave_1 added
[ 85.855034][ T5850] batman_adv: batadv0: Adding interface: batadv_slave_0
[ 85.862110][ T5850] batman_adv: batadv0: The MTU of interface batadv_slave_0 is too small (1500) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1532 would solve the problem.
[ 85.890810][ T5850] batman_adv: batadv0: Not using interface batadv_slave_0 (retrying later): interface not active
[ 85.937899][ T5850] batman_adv: batadv0: Adding interface: batadv_slave_1
[ 85.955505][ T5850] batman_adv: batadv0: The MTU of interface batadv_slave_1 is too small (1500) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1532 would solve the problem.
[ 85.983082][ T5850] batman_adv: batadv0: Not using interface batadv_slave_1 (retrying later): interface not active
[ 86.096947][ T3011] wlan0: Created IBSS using preconfigured BSSID 50:50:50:50:50:50
[ 86.119091][ T3011] wlan0: Creating new IBSS network, BSSID 50:50:50:50:50:50
[ 86.222916][ T5850] hsr_slave_0: entered promiscuous mode
[ 86.231976][ T5850] hsr_slave_1: entered promiscuous mode
[ 86.386654][ T3011] wlan1: Created IBSS using preconfigured BSSID 50:50:50:50:50:50
[ 86.408435][ T3011] wlan1: Creating new IBSS network, BSSID 50:50:50:50:50:50
[ 86.852590][ T10] cfg80211: failed to load regulatory.db
[ 86.916761][ T5915] Bluetooth: hci0: unexpected cc 0x0c03 length: 249 > 1
[ 86.926505][ T5915] Bluetooth: hci0: unexpected cc 0x1003 length: 249 > 9
[ 86.934375][ T5915] Bluetooth: hci0: unexpected cc 0x1001 length: 249 > 9
[ 86.942612][ T5915] Bluetooth: hci0: unexpected cc 0x0c23 length: 249 > 4
[ 86.950324][ T5915] Bluetooth: hci0: unexpected cc 0x0c38 length: 249 > 2
[ 87.486879][ T5850] netdevsim netdevsim4 netdevsim0: renamed from eth0
[ 87.547161][ T5850] netdevsim netdevsim4 netdevsim1: renamed from eth1
[ 87.628902][ T5850] netdevsim netdevsim4 netdevsim2: renamed from eth2
[ 87.675708][ T5850] netdevsim netdevsim4 netdevsim3: renamed from eth3
[ 88.020388][ T5850] 8021q: adding VLAN 0 to HW filter on device bond0
[ 88.043725][ T5850] 8021q: adding VLAN 0 to HW filter on device team0
[ 88.072115][ T3011] bridge0: port 1(bridge_slave_0) entered blocking state
[ 88.079410][ T3011] bridge0: port 1(bridge_slave_0) entered forwarding state
[ 88.110616][ T50] bridge0: port 2(bridge_slave_1) entered blocking state
[ 88.117968][ T50] bridge0: port 2(bridge_slave_1) entered forwarding state
[ 88.378710][ T5850] 8021q: adding VLAN 0 to HW filter on device batadv0
[ 88.578669][ T5850] veth0_vlan: entered promiscuous mode
[ 88.590813][ T5850] veth1_vlan: entered promiscuous mode
[ 88.622078][ T5850] veth0_macvtap: entered promiscuous mode
[ 88.632051][ T5850] veth1_macvtap: entered promiscuous mode
[ 88.648977][ T5850] batman_adv: batadv0: Interface activated: batadv_slave_0
[ 88.663182][ T5850] batman_adv: batadv0: Interface activated: batadv_slave_1
[ 88.678972][ T50] netdevsim netdevsim4 netdevsim0: set [1, 0] type 2 family 0 port 6081 - 0
[ 88.690533][ T50] netdevsim netdevsim4 netdevsim1: set [1, 0] type 2 family 0 port 6081 - 0
[ 88.700858][ T50] netdevsim netdevsim4 netdevsim2: set [1, 0] type 2 family 0 port 6081 - 0
[ 88.710553][ T50] netdevsim netdevsim4 netdevsim3: set [1, 0] type 2 family 0 port 6081 - 0
2026/01/04 20:08:16 executed programs: 0
[ 88.865865][ T5915] Bluetooth: hci1: unexpected cc 0x0c03 length: 249 > 1
[ 88.876934][ T5915] Bluetooth: hci1: unexpected cc 0x1003 length: 249 > 9
[ 88.885437][ T5915] Bluetooth: hci1: unexpected cc 0x1001 length: 249 > 9
[ 88.893744][ T5915] Bluetooth: hci1: unexpected cc 0x0c23 length: 249 > 4
[ 88.901576][ T5915] Bluetooth: hci1: unexpected cc 0x0c38 length: 249 > 2
[ 88.995249][ T5151] Bluetooth: hci0: command tx timeout
[ 89.100161][ T5949] chnl_net:caif_netlink_parms(): no params data found
[ 89.177370][ T5949] bridge0: port 1(bridge_slave_0) entered blocking state
[ 89.184801][ T5949] bridge0: port 1(bridge_slave_0) entered disabled state
[ 89.191961][ T5949] bridge_slave_0: entered allmulticast mode
[ 89.199570][ T5949] bridge_slave_0: entered promiscuous mode
[ 89.207774][ T5949] bridge0: port 2(bridge_slave_1) entered blocking state
[ 89.215047][ T5949] bridge0: port 2(bridge_slave_1) entered disabled state
[ 89.222237][ T5949] bridge_slave_1: entered allmulticast mode
[ 89.229908][ T5949] bridge_slave_1: entered promiscuous mode
[ 89.259789][ T5949] bond0: (slave bond_slave_0): Enslaving as an active interface with an up link
[ 89.271299][ T5949] bond0: (slave bond_slave_1): Enslaving as an active interface with an up link
[ 89.302556][ T5949] team0: Port device team_slave_0 added
[ 89.310953][ T5949] team0: Port device team_slave_1 added
[ 89.338706][ T5949] batman_adv: batadv0: Adding interface: batadv_slave_0
[ 89.345761][ T5949] batman_adv: batadv0: The MTU of interface batadv_slave_0 is too small (1500) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1532 would solve the problem.
[ 89.372170][ T5949] batman_adv: batadv0: Not using interface batadv_slave_0 (retrying later): interface not active
[ 89.384318][ T5949] batman_adv: batadv0: Adding interface: batadv_slave_1
[ 89.391316][ T5949] batman_adv: batadv0: The MTU of interface batadv_slave_1 is too small (1500) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1532 would solve the problem.
[ 89.417983][ T5949] batman_adv: batadv0: Not using interface batadv_slave_1 (retrying later): interface not active
[ 89.468539][ T5949] hsr_slave_0: entered promiscuous mode
[ 89.475789][ T5949] hsr_slave_1: entered promiscuous mode
[ 89.481886][ T5949] debugfs: 'hsr0' already exists in 'hsr'
[ 89.488687][ T5949] Cannot create hsr debugfs directory
[ 89.630976][ T5949] netdevsim netdevsim0 netdevsim0: renamed from eth0
[ 89.646717][ T5949] netdevsim netdevsim0 netdevsim1: renamed from eth1
[ 89.657293][ T5949] netdevsim netdevsim0 netdevsim2: renamed from eth2
[ 89.668667][ T5949] netdevsim netdevsim0 netdevsim3: renamed from eth3
[ 89.739310][ T5949] 8021q: adding VLAN 0 to HW filter on device bond0
[ 89.757774][ T5949] 8021q: adding VLAN 0 to HW filter on device team0
[ 89.770803][ T50] bridge0: port 1(bridge_slave_0) entered blocking state
[ 89.778040][ T50] bridge0: port 1(bridge_slave_0) entered forwarding state
[ 89.792156][ T1140] bridge0: port 2(bridge_slave_1) entered blocking state
[ 89.799296][ T1140] bridge0: port 2(bridge_slave_1) entered forwarding state
[ 89.960666][ T5949] 8021q: adding VLAN 0 to HW filter on device batadv0
[ 90.002819][ T5949] veth0_vlan: entered promiscuous mode
[ 90.014073][ T5949] veth1_vlan: entered promiscuous mode
[ 90.043369][ T5949] veth0_macvtap: entered promiscuous mode
[ 90.054407][ T5949] veth1_macvtap: entered promiscuous mode
[ 90.072472][ T5949] batman_adv: batadv0: Interface activated: batadv_slave_0
[ 90.088593][ T5949] batman_adv: batadv0: Interface activated: batadv_slave_1
[ 90.101621][ T50] netdevsim netdevsim0 netdevsim0: set [1, 0] type 2 family 0 port 6081 - 0
[ 90.111812][ T50] netdevsim netdevsim0 netdevsim1: set [1, 0] type 2 family 0 port 6081 - 0
[ 90.124276][ T50] netdevsim netdevsim0 netdevsim2: set [1, 0] type 2 family 0 port 6081 - 0
[ 90.137103][ T50] netdevsim netdevsim0 netdevsim3: set [1, 0] type 2 family 0 port 6081 - 0
[ 90.202203][ T36] wlan0: Created IBSS using preconfigured BSSID 50:50:50:50:50:50
[ 90.210471][ T36] wlan0: Creating new IBSS network, BSSID 50:50:50:50:50:50
[ 90.241519][ T36] wlan1: Created IBSS using preconfigured BSSID 50:50:50:50:50:50
[ 90.250208][ T36] wlan1: Creating new IBSS network, BSSID 50:50:50:50:50:50
SYZFAIL: failed to recv rpc
fd=3 want=4 recv=0 n=0 (errno 9: Bad file descriptor)
[ 90.511972][ T36] netdevsim netdevsim4 netdevsim3 (unregistering): unset [1, 0] type 2 family 0 port 6081 - 0
syzkaller build log:
go env (err=<nil>)
AR='ar'
CC='gcc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='g++'
GCCGO='gccgo'
GO111MODULE='auto'
GOAMD64='v1'
GOARCH='amd64'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/syzkaller/.cache/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/syzkaller/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build2271743110=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMOD='/syzkaller/jobs-2/linux/gopath/src/github.com/google/syzkaller/go.mod'
GOMODCACHE='/syzkaller/jobs-2/linux/gopath/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/syzkaller/jobs-2/linux/gopath'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/syzkaller/.config/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.24.4'
GOWORK=''
PKG_CONFIG='pkg-config'
git status (err=<nil>)
HEAD detached at 4e1406b4d
nothing to commit, working tree clean
tput: No value for $TERM and no -T specified
tput: No value for $TERM and no -T specified
Makefile:31: run command via tools/syz-env for best compatibility, see:
Makefile:32: https://github.com/google/syzkaller/blob/master/docs/contributing.md#using-syz-env
go list -f '{{.Stale}}' -ldflags="-s -w -X github.com/google/syzkaller/prog.GitRevision=4e1406b4defac0e2a9d9424c70706f79a7750cf3 -X github.com/google/syzkaller/prog.gitRevisionDate=20251106-151142" ./sys/syz-sysgen | grep -q false || go install -ldflags="-s -w -X github.com/google/syzkaller/prog.GitRevision=4e1406b4defac0e2a9d9424c70706f79a7750cf3 -X github.com/google/syzkaller/prog.gitRevisionDate=20251106-151142" ./sys/syz-sysgen
make .descriptions
tput: No value for $TERM and no -T specified
tput: No value for $TERM and no -T specified
Makefile:31: run command via tools/syz-env for best compatibility, see:
Makefile:32: https://github.com/google/syzkaller/blob/master/docs/contributing.md#using-syz-env
bin/syz-sysgen
touch .descriptions
GOOS=linux GOARCH=amd64 go build -ldflags="-s -w -X github.com/google/syzkaller/prog.GitRevision=4e1406b4defac0e2a9d9424c70706f79a7750cf3 -X github.com/google/syzkaller/prog.gitRevisionDate=20251106-151142" -o ./bin/linux_amd64/syz-execprog github.com/google/syzkaller/tools/syz-execprog
mkdir -p ./bin/linux_amd64
g++ -o ./bin/linux_amd64/syz-executor executor/executor.cc \
-m64 -O2 -pthread -Wall -Werror -Wparentheses -Wunused-const-variable -Wframe-larger-than=16384 -Wno-stringop-overflow -Wno-array-bounds -Wno-format-overflow -Wno-unused-but-set-variable -Wno-unused-command-line-argument -static-pie -std=c++17 -I. -Iexecutor/_include -DGOOS_linux=1 -DGOARCH_amd64=1 \
-DHOSTGOOS_linux=1 -DGIT_REVISION=\"4e1406b4defac0e2a9d9424c70706f79a7750cf3\"
/usr/bin/ld: /tmp/ccfgb6KF.o: in function `Connection::Connect(char const*, char const*)':
executor.cc:(.text._ZN10Connection7ConnectEPKcS1_[_ZN10Connection7ConnectEPKcS1_]+0x104): warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
./tools/check-syzos.sh 2>/dev/null
Tested on:
commit: a069190b bpf: Replace __opt annotation with __nullable..
git tree: bpf-next
kernel config: https://syzkaller.appspot.com/x/.config?x=9c5e9eccee9bc2fe
dashboard link: https://syzkaller.appspot.com/bug?extid=d1b7fa1092def3628bd7
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
patch: https://syzkaller.appspot.com/x/patch.diff?x=12414f92580000
^ permalink raw reply [flat|nested] 24+ messages in thread
* #syz test
2025-11-10 18:41 [syzbot] [bpf?] KASAN: stack-out-of-bounds Write in __bpf_get_stack syzbot
` (8 preceding siblings ...)
2026-01-04 18:29 ` #syz test Arnaud Lecomte
@ 2026-01-04 18:30 ` Arnaud Lecomte
2026-01-04 20:43 ` [syzbot] [bpf?] KASAN: stack-out-of-bounds Write in __bpf_get_stack syzbot
9 siblings, 1 reply; 24+ messages in thread
From: Arnaud Lecomte @ 2026-01-04 18:30 UTC (permalink / raw)
To: syzbot+d1b7fa1092def3628bd7; +Cc: contact, linux-kernel, syzkaller-bugs
#syz test
diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
index 2365541c81dd..b8ff4ccae2d6 100644
--- a/kernel/bpf/stackmap.c
+++ b/kernel/bpf/stackmap.c
@@ -465,7 +465,6 @@ static long __bpf_get_stack(struct pt_regs *regs, struct task_struct *task,
if (trace_in) {
trace = trace_in;
- trace->nr = min_t(u32, trace->nr, max_depth);
} else if (kernel && task) {
trace = get_callchain_entry_for_task(task, max_depth);
} else {
@@ -479,7 +478,8 @@ static long __bpf_get_stack(struct pt_regs *regs, struct task_struct *task,
goto err_fault;
}
- trace_nr = trace->nr - skip;
+ trace_nr = min(trace->nr, max_depth);
+ trace_nr = trace_nr - skip;
copy_len = trace_nr * elem_size;
ips = trace->ip + skip;
--
2.43.0
^ permalink raw reply related [flat|nested] 24+ messages in thread