linux-kernel - Re: [PATCH V2] ring-buffer: fix overflow in __rb_map

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20241218082417.701399ad@gandalf.local.home>
Date: Wed, 18 Dec 2024 08:24:17 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Edward Adam Davis <eadavis@...com>
Cc: vdonnefort@...gle.com, aha310510@...il.com, david@...hat.com,
 linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
 mathieu.desnoyers@...icios.com, mhiramat@...nel.org,
 syzbot+345e4443a21200874b18@...kaller.appspotmail.com,
 syzkaller-bugs@...glegroups.com
Subject: Re: [PATCH V2] ring-buffer: fix overflow in __rb_map_vma

On Wed, 18 Dec 2024 19:42:22 +0800
Edward Adam Davis <eadavis@...com> wrote:

> Reported-by: syzbot+345e4443a21200874b18@...kaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=345e4443a21200874b18
> Signed-off-by: Edward Adam Davis <eadavis@...com>
> ---
> V1 -> V2: updated according to Vincent Donnefort's suggestion, to avoid repeating the (nr_subbufs + 1) << subbuf_order
> 
>  kernel/trace/ring_buffer.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)


Also, when sending a new version of a patch, do not reply to the previous
version as that hides the new patch. It should start a new thread.
Otherwise it screws up tooling and also hides patches. I've missed patches
because they were replied to the previous patch. It makes it much harder on
the maintainer when someone does that.

What I usually do to maintain a history chain is have:

Signed-off-by: ...
---
Changes since v1: https://lore.kernel.org/all/tencent_E036A29600368E4A2075A7774D67023CFD09@qq.com/

- Updated according to Vincent Donnefort's suggestion, to avoid repeating
  the (nr_subbufs + 1) << subbuf_order


-- Steve