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: <2025123003-ecologist-foothill-09b8@gregkh>
Date: Tue, 30 Dec 2025 14:47:37 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
Cc: Ekansh Gupta <ekansh.gupta@....qualcomm.com>, srini@...nel.org,
	linux-arm-msm@...r.kernel.org, quic_bkumar@...cinc.com,
	linux-kernel@...r.kernel.org, quic_chennak@...cinc.com,
	dri-devel@...ts.freedesktop.org, arnd@...db.de,
	dmitry.baryshkov@....qualcomm.com, stable@...nel.org
Subject: Re: [PATCH v3 1/3] misc: fastrpc: Sanitize address logging and
 remove tabs

On Tue, Dec 30, 2025 at 02:23:55PM +0100, Konrad Dybcio wrote:
> On 12/30/25 12:02 PM, Ekansh Gupta wrote:
> > Avoid printing raw addresses in driver logs by using %p for remote
> > buffer addresses. This reduces the risk of information leaks and
> > conforms to kernel logging guidelines. Remove tabs in dev_*
> > messages.
> > 
> > Fixes: 2419e55e532d ("misc: fastrpc: add mmap/unmap support")
> > Cc: stable@...nel.org
> > Signed-off-by: Ekansh Gupta <ekansh.gupta@....qualcomm.com>
> > ---
> >  drivers/misc/fastrpc.c | 19 ++++++++++---------
> >  1 file changed, 10 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
> > index ee652ef01534..408fe47e9db7 100644
> > --- a/drivers/misc/fastrpc.c
> > +++ b/drivers/misc/fastrpc.c
> > @@ -1830,13 +1830,13 @@ static int fastrpc_req_munmap_impl(struct fastrpc_user *fl, struct fastrpc_buf *
> >  	err = fastrpc_internal_invoke(fl, true, FASTRPC_INIT_HANDLE, sc,
> >  				      &args[0]);
> >  	if (!err) {
> > -		dev_dbg(dev, "unmmap\tpt 0x%09lx OK\n", buf->raddr);
> > +		dev_dbg(dev, "unmap OK: raddr=%p\n", (void *)(unsigned long)buf->raddr);
> 
> Would it be easier if we did away with the uintptr_t, since the protocol
> seems to assume all addresses are u64s anyway?

Why is a pointer being printed at all?  That shouldn't be needed and is,
as always, a potential information leak.

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ