linux-kernel - Re: [PATCH v6 2/6] syscall.h: add syscall_set

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

Message-ID: <alpine.DEB.2.21.2502191855130.65342@angie.orcam.me.uk>
Date: Wed, 19 Feb 2025 19:16:04 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: "Dmitry V. Levin" <ldv@...ace.io>
cc: Thomas Bogendoerfer <tsbogend@...ha.franken.de>, 
    Guo Ren <guoren@...nel.org>, Andrew Morton <akpm@...ux-foundation.org>, 
    Oleg Nesterov <oleg@...hat.com>, Alexey Gladkov <legion@...nel.org>, 
    Eugene Syromyatnikov <evgsyr@...il.com>, strace-devel@...ts.strace.io, 
    linux-mips@...r.kernel.org, linux-csky@...r.kernel.org, 
    linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 2/6] syscall.h: add syscall_set_arguments()

On Wed, 19 Feb 2025, Dmitry V. Levin wrote:

> > -- given MIPS syscall_set_nr() implementation in 3/6 this conditional is 
> > supposed to never be true.  Should it be BUG_ON() or discarded entirely?
> 
> I agree it should be discarded: given that the syscall number read from
> regs[2] after syscall_trace_enter() invocation is not treated in any
> special way with regards to __NR_syscall, it would be incorrect to do
> it here either.  In fact, user space is allowed to set regs[2] to
> __NR_syscall, even though it's pointless, but it's definitely not a
> BUG_ON() situation.

 Right, good point, the conditional indeed can do harm even.  Thanks for 
double-checking.

  Maciej