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: [email protected]
> > Signed-off-by: Ekansh Gupta <[email protected]>
> > ---
> > 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
