<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/infiniband, branch v5.9.12</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.9.12</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.9.12'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2020-12-02T07:52:00+00:00</updated>
<entry>
<title>RDMA/hns: Bugfix for memory window mtpt configuration</title>
<updated>2020-12-02T07:52:00+00:00</updated>
<author>
<name>Yixian Liu</name>
<email>liuyixian@huawei.com</email>
</author>
<published>2020-11-26T10:26:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a84974f0e712dcf07051ca017bf2fd77ffc1b623'/>
<id>urn:sha1:a84974f0e712dcf07051ca017bf2fd77ffc1b623</id>
<content type='text'>
[ Upstream commit 17475e104dcb74217c282781817f8f52b46130d3 ]

When a memory window is bound to a memory region, the local write access
should be set for its mtpt table.

Fixes: c7c28191408b ("RDMA/hns: Add MW support for hip08")
Link: https://lore.kernel.org/r/1606386372-21094-1-git-send-email-liweihang@huawei.com
Signed-off-by: Yixian Liu &lt;liuyixian@huawei.com&gt;
Signed-off-by: Weihang Li &lt;liweihang@huawei.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>RDMA/hns: Fix retry_cnt and rnr_cnt when querying QP</title>
<updated>2020-12-02T07:52:00+00:00</updated>
<author>
<name>Wenpeng Liang</name>
<email>liangwenpeng@huawei.com</email>
</author>
<published>2020-11-26T09:29:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c16cfa44478bb8738ac3174fb6b893428935881f'/>
<id>urn:sha1:c16cfa44478bb8738ac3174fb6b893428935881f</id>
<content type='text'>
[ Upstream commit ab6f7248cc446b85fe9e31091670ad7c4293d7fd ]

The maximum number of retransmission should be returned when querying QP,
not the value of retransmission counter.

Fixes: 99fcf82521d9 ("RDMA/hns: Fix the wrong value of rnr_retry when querying qp")
Fixes: 926a01dc000d ("RDMA/hns: Add QP operations support for hip08 SoC")
Link: https://lore.kernel.org/r/1606382977-21431-1-git-send-email-liweihang@huawei.com
Signed-off-by: Wenpeng Liang &lt;liangwenpeng@huawei.com&gt;
Signed-off-by: Weihang Li &lt;liweihang@huawei.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>RDMA/hns: Fix wrong field of SRQ number the device supports</title>
<updated>2020-12-02T07:52:00+00:00</updated>
<author>
<name>Wenpeng Liang</name>
<email>liangwenpeng@huawei.com</email>
</author>
<published>2020-11-26T09:26:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=df46336c4ab5e3f0563419e6b0e5cb9c3720f846'/>
<id>urn:sha1:df46336c4ab5e3f0563419e6b0e5cb9c3720f846</id>
<content type='text'>
[ Upstream commit ebed7b7ca47f3aa95ebf2185a526227744616ac1 ]

The SRQ capacity is got from the firmware, whose field should be ended at
bit 19.

Fixes: ba6bb7e97421 ("RDMA/hns: Add interfaces to get pf capabilities from firmware")
Link: https://lore.kernel.org/r/1606382812-23636-1-git-send-email-liweihang@huawei.com
Signed-off-by: Wenpeng Liang &lt;liangwenpeng@huawei.com&gt;
Signed-off-by: Weihang Li &lt;liweihang@huawei.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>IB/mthca: fix return value of error branch in mthca_init_cq()</title>
<updated>2020-12-02T07:51:56+00:00</updated>
<author>
<name>Xiongfeng Wang</name>
<email>wangxiongfeng2@huawei.com</email>
</author>
<published>2020-11-20T01:57:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bf8da8dc44edcb3e4e1c82f84343be2c1d40a5c0'/>
<id>urn:sha1:bf8da8dc44edcb3e4e1c82f84343be2c1d40a5c0</id>
<content type='text'>
[ Upstream commit 6830ff853a5764c75e56750d59d0bbb6b26f1835 ]

We return 'err' in the error branch, but this variable may be set as zero
by the above code. Fix it by setting 'err' as a negative value before we
goto the error label.

Fixes: 74c2174e7be5 ("IB uverbs: add mthca user CQ support")
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Link: https://lore.kernel.org/r/1605837422-42724-1-git-send-email-wangxiongfeng2@huawei.com
Reported-by: Hulk Robot &lt;hulkci@huawei.com&gt;
Signed-off-by: Xiongfeng Wang &lt;wangxiongfeng2@huawei.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>RDMA/i40iw: Address an mmap handler exploit in i40iw</title>
<updated>2020-12-02T07:51:44+00:00</updated>
<author>
<name>Shiraz Saleem</name>
<email>shiraz.saleem@intel.com</email>
</author>
<published>2020-11-25T00:56:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d1f17032763e233c13a013780bead98a7243ba22'/>
<id>urn:sha1:d1f17032763e233c13a013780bead98a7243ba22</id>
<content type='text'>
commit 2ed381439e89fa6d1a0839ef45ccd45d99d8e915 upstream.

i40iw_mmap manipulates the vma-&gt;vm_pgoff to differentiate a push page mmap
vs a doorbell mmap, and uses it to compute the pfn in remap_pfn_range
without any validation. This is vulnerable to an mmap exploit as described
in: https://lore.kernel.org/r/20201119093523.7588-1-zhudi21@huawei.com

The push feature is disabled in the driver currently and therefore no push
mmaps are issued from user-space. The feature does not work as expected in
the x722 product.

Remove the push module parameter and all VMA attribute manipulations for
this feature in i40iw_mmap. Update i40iw_mmap to only allow DB user
mmapings at offset = 0. Check vm_pgoff for zero and if the mmaps are bound
to a single page.

Cc: &lt;stable@kernel.org&gt;
Fixes: d37498417947 ("i40iw: add files for iwarp interface")
Link: https://lore.kernel.org/r/20201125005616.1800-2-shiraz.saleem@intel.com
Reported-by: Di Zhu &lt;zhudi21@huawei.com&gt;
Signed-off-by: Shiraz Saleem &lt;shiraz.saleem@intel.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>IB/hfi1: Ensure correct mm is used at all times</title>
<updated>2020-12-02T07:51:43+00:00</updated>
<author>
<name>Dennis Dalessandro</name>
<email>dennis.dalessandro@cornelisnetworks.com</email>
</author>
<published>2020-11-25T21:01:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5732f83596f8a573f2cde814cc76a54e1a8995c7'/>
<id>urn:sha1:5732f83596f8a573f2cde814cc76a54e1a8995c7</id>
<content type='text'>
commit 3d2a9d642512c21a12d19b9250e7a835dcb41a79 upstream.

Two earlier bug fixes have created a security problem in the hfi1
driver. One fix aimed to solve an issue where current-&gt;mm was not valid
when closing the hfi1 cdev. It attempted to do this by saving a cached
value of the current-&gt;mm pointer at file open time. This is a problem if
another process with access to the FD calls in via write() or ioctl() to
pin pages via the hfi driver. The other fix tried to solve a use after
free by taking a reference on the mm.

To fix this correctly we use the existing cached value of the mm in the
mmu notifier. Now we can check in the insert, evict, etc. routines that
current-&gt;mm matched what the notifier was registered for. If not, then
don't allow access. The register of the mmu notifier will save the mm
pointer.

Since in do_exit() the exit_mm() is called before exit_files(), which
would call our close routine a reference is needed on the mm. We rely on
the mmgrab done by the registration of the notifier, whereas before it was
explicit. The mmu notifier deregistration happens when the user context is
torn down, the creation of which triggered the registration.

Also of note is we do not do any explicit work to protect the interval
tree notifier. It doesn't seem that this is going to be needed since we
aren't actually doing anything with current-&gt;mm. The interval tree
notifier stuff still has a FIXME noted from a previous commit that will be
addressed in a follow on patch.

Cc: &lt;stable@vger.kernel.org&gt;
Fixes: e0cf75deab81 ("IB/hfi1: Fix mm_struct use after free")
Fixes: 3faa3d9a308e ("IB/hfi1: Make use of mm consistent")
Link: https://lore.kernel.org/r/20201125210112.104301.51331.stgit@awfm-01.aw.intel.com
Suggested-by: Jann Horn &lt;jannh@google.com&gt;
Reported-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Reviewed-by: Ira Weiny &lt;ira.weiny@intel.com&gt;
Reviewed-by: Mike Marciniszyn &lt;mike.marciniszyn@cornelisnetworks.com&gt;
Signed-off-by: Dennis Dalessandro &lt;dennis.dalessandro@cornelisnetworks.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>IB/hfi1: Fix error return code in hfi1_init_dd()</title>
<updated>2020-11-24T12:39:00+00:00</updated>
<author>
<name>Zhang Changzhong</name>
<email>zhangchangzhong@huawei.com</email>
</author>
<published>2020-11-13T06:42:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ec6ea95aed5abd1a60ffd8a3eab775ca4603c0cb'/>
<id>urn:sha1:ec6ea95aed5abd1a60ffd8a3eab775ca4603c0cb</id>
<content type='text'>
[ Upstream commit dabbd6abcdbeb1358a53ec28a244429320eb0e3a ]

Fix to return a negative error code from the error handling case instead
of 0, as done elsewhere in this function.

Fixes: 4730f4a6c6b2 ("IB/hfi1: Activate the dummy netdev")
Link: https://lore.kernel.org/r/1605249747-17942-1-git-send-email-zhangchangzhong@huawei.com
Reported-by: Hulk Robot &lt;hulkci@huawei.com&gt;
Signed-off-by: Zhang Changzhong &lt;zhangchangzhong@huawei.com&gt;
Acked-by: Mike Marciniszyn &lt;mike.marciniszyn@cornelisnetworks.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>RMDA/sw: Don't allow drivers using dma_virt_ops on highmem configs</title>
<updated>2020-11-24T12:38:59+00:00</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2020-11-06T18:19:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d499fabd16f91f090c26e79a35663394833beff3'/>
<id>urn:sha1:d499fabd16f91f090c26e79a35663394833beff3</id>
<content type='text'>
[ Upstream commit b1e678bf290db5a76f1b6a9f7c381310e03440d6 ]

dma_virt_ops requires that all pages have a kernel virtual address.
Introduce a INFINIBAND_VIRT_DMA Kconfig symbol that depends on !HIGHMEM
and make all three drivers depend on the new symbol.

Also remove the ARCH_DMA_ADDR_T_64BIT dependency, which has been obsolete
since commit 4965a68780c5 ("arch: define the ARCH_DMA_ADDR_T_64BIT config
symbol in lib/Kconfig")

Fixes: 551199aca1c3 ("lib/dma-virt: Add dma_virt_ops")
Link: https://lore.kernel.org/r/20201106181941.1878556-2-hch@lst.de
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>RDMA/pvrdma: Fix missing kfree() in pvrdma_register_device()</title>
<updated>2020-11-24T12:38:59+00:00</updated>
<author>
<name>Qinglang Miao</name>
<email>miaoqinglang@huawei.com</email>
</author>
<published>2020-11-11T03:22:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=32357644083d94fc69d8125071b25dbf9c642f11'/>
<id>urn:sha1:32357644083d94fc69d8125071b25dbf9c642f11</id>
<content type='text'>
[ Upstream commit d035c3f6cdb8e5d5a17adcbb79d7453417a6077d ]

Fix missing kfree in pvrdma_register_device() when failure from
ib_device_set_netdev().

Fixes: 4b38da75e089 ("RDMA/drivers: Convert easy drivers to use ib_device_set_netdev()")
Link: https://lore.kernel.org/r/20201111032202.17925-1-miaoqinglang@huawei.com
Reported-by: Hulk Robot &lt;hulkci@huawei.com&gt;
Signed-off-by: Qinglang Miao &lt;miaoqinglang@huawei.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>IB/srpt: Fix memory leak in srpt_add_one</title>
<updated>2020-11-18T18:22:03+00:00</updated>
<author>
<name>Maor Gottlieb</name>
<email>maorg@nvidia.com</email>
</author>
<published>2020-10-28T06:50:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c32fe6241edcf00509cadf2bc099de8f6af2e107'/>
<id>urn:sha1:c32fe6241edcf00509cadf2bc099de8f6af2e107</id>
<content type='text'>
[ Upstream commit 372a1786283e50e7cb437ab7fdb1b95597310ad7 ]

Failure in srpt_refresh_port() for the second port will leave MAD
registered for the first one, however, the srpt_add_one() will be marked
as "failed" and SRPT will leak resources for that registered but not used
and released first port.

Unregister the MAD agent for all ports in case of failure.

Fixes: a42d985bd5b2 ("ib_srpt: Initial SRP Target merge for v3.3-rc1")
Link: https://lore.kernel.org/r/20201028065051.112430-1-leon@kernel.org
Signed-off-by: Maor Gottlieb &lt;maorg@nvidia.com&gt;
Signed-off-by: Leon Romanovsky &lt;leonro@nvidia.com&gt;
Reviewed-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
