linux-kernel - Re: [PATCH stable v6.6] riscv: kprobes: Fix wrong lengths passed to patch_text

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-prev] [day] [month] [year] [list]

Message-ID: <2025042957-dazzler-frying-9051@gregkh>
Date: Tue, 29 Apr 2025 18:51:43 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Nam Cao <namcao@...utronix.de>
Cc: stable@...r.kernel.org, Kai Zhang <zhangkai@...as.ac.cn>,
	Paul Walmsley <paul.walmsley@...ive.com>,
	Palmer Dabbelt <palmer@...belt.com>,
	Albert Ou <aou@...s.berkeley.edu>, Alexandre Ghiti <alex@...ti.fr>,
	Samuel Holland <samuel.holland@...ive.com>,
	linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH stable v6.6] riscv: kprobes: Fix wrong lengths passed to
 patch_text_nosync()

On Tue, Apr 29, 2025 at 06:48:21PM +0200, Nam Cao wrote:
> On Tue, Apr 29, 2025 at 06:31:09PM +0200, Greg Kroah-Hartman wrote:
> > On Tue, Apr 29, 2025 at 06:14:18PM +0200, Nam Cao wrote:
> > > Unlike patch_text(), patch_text_nosync() takes the length in bytes, not
> > > number of instructions. It is therefore wrong for arch_prepare_ss_slot() to
> > > pass length=1 while patching one instruction.
> > > 
> > > This bug was introduced by commit b1756750a397 ("riscv: kprobes: Use
> > > patch_text_nosync() for insn slots"). It has been fixed upstream by commit
> > > 51781ce8f448 ("riscv: Pass patch_text() the length in bytes"). However,
> > > beside fixing this bug, this commit does many other things, making it
> > > unsuitable for backporting.
> > 
> > We would almost always want the original commit, why not just send that
> > instead?  What is wrong with it being in here as-is?
> 
> The original commit is probably fine. But I'm paranoid, because it is not
> completely obvious whether the original commit would break something else
> in v6.6. Because, as mentioned, it does more than just fixing the bug.

You should be more paranoid about creating a one-off change that is NOT
upstream as in our experience, that almost always causes a new problem.

Please just backport the original and submit it after testing it out.

thanks,

greg k-h