[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fa8b6397c285413c83194e471056feea@AcuMS.aculab.com>
Date: Fri, 16 Dec 2022 10:23:02 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Bernard Metzler' <BMT@...ich.ibm.com>,
Linus Walleij <linus.walleij@...aro.org>
CC: Arnd Bergmann <arnd@...nel.org>, Jason Gunthorpe <jgg@...pe.ca>,
"Leon Romanovsky" <leon@...nel.org>, Arnd Bergmann <arnd@...db.de>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: Re: [PATCH] RDMA/siw: fix pointer cast warning
From: Bernard Metzler
> Sent: 16 December 2022 10:01
>
> > -----Original Message-----
> > From: Linus Walleij <linus.walleij@...aro.org>
> > Sent: Friday, 16 December 2022 08:47
> > To: David Laight <David.Laight@...lab.com>
> > Cc: Arnd Bergmann <arnd@...nel.org>; Bernard Metzler <BMT@...ich.ibm.com>;
> > Jason Gunthorpe <jgg@...pe.ca>; Leon Romanovsky <leon@...nel.org>; Arnd
> > Bergmann <arnd@...db.de>; linux-rdma@...r.kernel.org; linux-
> > kernel@...r.kernel.org
> > Subject: [EXTERNAL] Re: [PATCH] RDMA/siw: fix pointer cast warning
> >
> > On Thu, Dec 15, 2022 at 11:20 PM David Laight <David.Laight@...lab.com>
> > wrote:
> >
> > > From: Arnd Bergmann
> > > > Sent: 15 December 2022 17:04
> > > >
> > > > From: Arnd Bergmann <arnd@...db.de>
> > > >
> > > > The previous build fix left a remaining issue in configurations
> > > > with 64-bit dma_addr_t on 32-bit architectures:
> > > >
> > > > drivers/infiniband/sw/siw/siw_qp_tx.c: In function 'siw_get_pblpage':
> > > > drivers/infiniband/sw/siw/siw_qp_tx.c:32:37: error: cast to pointer
> > from integer of different size [-
> > > > Werror=int-to-pointer-cast]
> > > > 32 | return virt_to_page((void *)paddr);
> > > > | ^
> > > >
> > > > Use the same double cast here that the driver uses elsewhere
> > > > to convert between dma_addr_t and void*.
> > > >
> > > > It took me a while to figure out why this driver does it
> > > > like this, as there is no hardware access and it just stores
> > > > kernel pointers in place of device addresses when communicating
> > > > with the rdma core and with user space.
> > >
> > > I hope that doesn't mean it is relying on user space only
> > > giving it back valid values?
> >
> > It looks to me like this driver totally trusts userspace.
> >
>
> Shame on me. Yes, somehow, an access_ok((void __user *)start, len)
> is missing! Let me fix that when I am back at my desk. Seems it needs
> immediate action.
That wasn't the sort of issue I was thinking about.
I was worried that it was putting the addresses of kernel memory
into buffers written to userspace and then later reading the
addresses back from userspace and accessing them.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists