Messages in this thread | | | From | David Laight <> | Subject | RE: Re: [PATCH] RDMA/siw: fix pointer cast warning | Date | Fri, 16 Dec 2022 10:23:02 +0000 |
| |
From: Bernard Metzler > Sent: 16 December 2022 10:01 > > > -----Original Message----- > > From: Linus Walleij <linus.walleij@linaro.org> > > Sent: Friday, 16 December 2022 08:47 > > To: David Laight <David.Laight@aculab.com> > > Cc: Arnd Bergmann <arnd@kernel.org>; Bernard Metzler <BMT@zurich.ibm.com>; > > Jason Gunthorpe <jgg@ziepe.ca>; Leon Romanovsky <leon@kernel.org>; Arnd > > Bergmann <arnd@arndb.de>; linux-rdma@vger.kernel.org; linux- > > kernel@vger.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@aculab.com> > > wrote: > > > > > From: Arnd Bergmann > > > > Sent: 15 December 2022 17:04 > > > > > > > > From: Arnd Bergmann <arnd@arndb.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)
| |