--- /dev/null
+From b5c52908d52c6c8eb8933264aa6087a0600fd892 Mon Sep 17 00:00:00 2001
+From: Gang Yan <yangang@kylinos.cn>
+Date: Mon, 27 Apr 2026 21:54:34 +0200
+Subject: mptcp: fix scheduling with atomic in timestamp sockopt
+
+From: Gang Yan <yangang@kylinos.cn>
+
+commit b5c52908d52c6c8eb8933264aa6087a0600fd892 upstream.
+
+Using lock_sock_fast() (atomic context) around sock_set_timestamp()
+and sock_set_timestamping() is unsafe, as both helpers can sleep.
+
+Replace lock_sock_fast() with sleepable lock_sock()/release_sock()
+to avoid scheduling while atomic panic.
+
+Fixes: 9061f24bf82e ("mptcp: sockopt: propagate timestamp request to subflows")
+Cc: stable@vger.kernel.org
+Reported-by: Sashiko <sashiko-bot@kernel.org>
+Closes: https://sashiko.dev/#/patchset/20260420093343.16443-1-gang.yan@linux.dev
+Signed-off-by: Gang Yan <yangang@kylinos.cn>
+Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Link: https://patch.msgid.link/20260427-net-mptcp-misc-fixes-7-1-rc2-v1-2-7432b7f279fa@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/mptcp/sockopt.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/net/mptcp/sockopt.c
++++ b/net/mptcp/sockopt.c
+@@ -155,10 +155,10 @@ static int mptcp_setsockopt_sol_socket_t
+ lock_sock(sk);
+ mptcp_for_each_subflow(msk, subflow) {
+ struct sock *ssk = mptcp_subflow_tcp_sock(subflow);
+- bool slow = lock_sock_fast(ssk);
+
++ lock_sock(ssk);
+ sock_set_timestamp(ssk, optname, !!val);
+- unlock_sock_fast(ssk, slow);
++ release_sock(ssk);
+ }
+
+ release_sock(sk);
+@@ -231,10 +231,10 @@ static int mptcp_setsockopt_sol_socket_t
+
+ mptcp_for_each_subflow(msk, subflow) {
+ struct sock *ssk = mptcp_subflow_tcp_sock(subflow);
+- bool slow = lock_sock_fast(ssk);
+
++ lock_sock(ssk);
+ sock_set_timestamping(ssk, optname, timestamping);
+- unlock_sock_fast(ssk, slow);
++ release_sock(ssk);
+ }
+
+ release_sock(sk);
--- /dev/null
+From 5f95c21fc23a7ef22b4d27d1ed9bb55557ffb926 Mon Sep 17 00:00:00 2001
+From: Gang Yan <yangang@kylinos.cn>
+Date: Mon, 27 Apr 2026 21:54:33 +0200
+Subject: mptcp: sockopt: set timestamp flags on subflow socket, not msk
+
+From: Gang Yan <yangang@kylinos.cn>
+
+commit 5f95c21fc23a7ef22b4d27d1ed9bb55557ffb926 upstream.
+
+Both mptcp_setsockopt_sol_socket_tstamp() and
+mptcp_setsockopt_sol_socket_timestamping() iterate over subflows,
+acquire the subflow socket lock, but then erroneously pass the MPTCP
+msk socket to sock_set_timestamp() / sock_set_timestamping() instead
+of the subflow ssk. As a result, the timestamp flags are set on the
+wrong socket and have no effect on the actual subflows.
+
+Pass ssk instead of sk to both helpers.
+
+Fixes: 9061f24bf82e ("mptcp: sockopt: propagate timestamp request to subflows")
+Cc: stable@vger.kernel.org
+Signed-off-by: Gang Yan <yangang@kylinos.cn>
+Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Link: https://patch.msgid.link/20260427-net-mptcp-misc-fixes-7-1-rc2-v1-1-7432b7f279fa@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/mptcp/sockopt.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/net/mptcp/sockopt.c
++++ b/net/mptcp/sockopt.c
+@@ -157,7 +157,7 @@ static int mptcp_setsockopt_sol_socket_t
+ struct sock *ssk = mptcp_subflow_tcp_sock(subflow);
+ bool slow = lock_sock_fast(ssk);
+
+- sock_set_timestamp(sk, optname, !!val);
++ sock_set_timestamp(ssk, optname, !!val);
+ unlock_sock_fast(ssk, slow);
+ }
+
+@@ -233,7 +233,7 @@ static int mptcp_setsockopt_sol_socket_t
+ struct sock *ssk = mptcp_subflow_tcp_sock(subflow);
+ bool slow = lock_sock_fast(ssk);
+
+- sock_set_timestamping(sk, optname, timestamping);
++ sock_set_timestamping(ssk, optname, timestamping);
+ unlock_sock_fast(ssk, slow);
+ }
+
--- /dev/null
+From c4a99a921949cddc590b22bb14eeb23dffcc3ba6 Mon Sep 17 00:00:00 2001
+From: Shardul Bankar <shardul.b@mpiricsoftware.com>
+Date: Fri, 1 May 2026 21:35:34 +0200
+Subject: mptcp: use MPJoinSynAckHMacFailure for SynAck HMAC failure
+
+From: Shardul Bankar <shardul.b@mpiricsoftware.com>
+
+commit c4a99a921949cddc590b22bb14eeb23dffcc3ba6 upstream.
+
+In subflow_finish_connect(), HMAC validation of the server's HMAC
+in SYN/ACK + MP_JOIN increments MPTCP_MIB_JOINACKMAC ("HMAC was
+wrong on ACK + MP_JOIN") on failure. The function processes the
+SYN/ACK, not the ACK; the matching MPTCP_MIB_JOINSYNACKMAC counter
+("HMAC was wrong on SYN/ACK + MP_JOIN") exists but is not
+incremented anywhere in the tree.
+
+The mirror site on the server, subflow_syn_recv_sock(), already
+uses JOINACKMAC correctly for ACK HMAC failure. Use JOINSYNACKMAC
+at the SYN/ACK validation site so each counter reflects the packet
+whose HMAC actually failed.
+
+Suggested-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Fixes: fc518953bc9c ("mptcp: add and use MIB counter infrastructure")
+Cc: stable@vger.kernel.org
+Signed-off-by: Shardul Bankar <shardul.b@mpiricsoftware.com>
+Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Link: https://patch.msgid.link/20260501-net-mptcp-misc-fixes-7-1-rc3-v1-1-b70118df778e@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/mptcp/subflow.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/mptcp/subflow.c
++++ b/net/mptcp/subflow.c
+@@ -460,7 +460,7 @@ static void subflow_finish_connect(struc
+ subflow->backup);
+
+ if (!subflow_thmac_valid(subflow)) {
+- MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_JOINACKMAC);
++ MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_JOINSYNACKMAC);
+ subflow->reset_reason = MPTCP_RST_EMPTCP;
+ goto do_reset;
+ }
--- /dev/null
+From a6da02d4c00fdda2417e42ad2b762a9209e6cc49 Mon Sep 17 00:00:00 2001
+From: Shardul Bankar <shardul.b@mpiricsoftware.com>
+Date: Fri, 1 May 2026 21:35:35 +0200
+Subject: mptcp: use MPTCP_RST_EMPTCP for ACK HMAC validation failure
+
+From: Shardul Bankar <shardul.b@mpiricsoftware.com>
+
+commit a6da02d4c00fdda2417e42ad2b762a9209e6cc49 upstream.
+
+When HMAC validation fails on a received ACK + MP_JOIN in
+subflow_syn_recv_sock(), the subflow is reset with reason
+MPTCP_RST_EPROHIBIT ("Administratively prohibited"). This is
+incorrect: HMAC validation failure is an MPTCP protocol-level
+error, not an administrative policy denial.
+
+The mirror site on the client, in subflow_finish_connect(), already
+uses MPTCP_RST_EMPTCP ("MPTCP-specific error") for the same kind of
+HMAC failure on the SYN/ACK + MP_JOIN. Use the same reason on the
+server side for symmetry and accuracy.
+
+Suggested-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Fixes: 443041deb5ef ("mptcp: fix NULL pointer in can_accept_new_subflow")
+Cc: stable@vger.kernel.org
+Signed-off-by: Shardul Bankar <shardul.b@mpiricsoftware.com>
+Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Link: https://patch.msgid.link/20260501-net-mptcp-misc-fixes-7-1-rc3-v1-2-b70118df778e@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/mptcp/subflow.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/mptcp/subflow.c
++++ b/net/mptcp/subflow.c
+@@ -787,7 +787,7 @@ create_child:
+
+ if (!subflow_hmac_valid(req, &mp_opt)) {
+ SUBFLOW_REQ_INC_STATS(req, MPTCP_MIB_JOINACKMAC);
+- subflow_add_reset_reason(skb, MPTCP_RST_EPROHIBIT);
++ subflow_add_reset_reason(skb, MPTCP_RST_EMPTCP);
+ goto dispose_child;
+ }
+
--- /dev/null
+From a8aeea1bf3c80cc87983689e0118770e019bd4f3 Mon Sep 17 00:00:00 2001
+From: Shuai Xue <xueshuai@linux.alibaba.com>
+Date: Wed, 11 Feb 2026 20:46:24 +0800
+Subject: PCI/AER: Clear only error bits in PCIe Device Status
+
+From: Shuai Xue <xueshuai@linux.alibaba.com>
+
+commit a8aeea1bf3c80cc87983689e0118770e019bd4f3 upstream.
+
+Currently, pcie_clear_device_status() clears the entire PCIe Device Status
+register (PCI_EXP_DEVSTA) by writing back the value read from the register,
+which affects not only the error status bits but also other writable bits.
+
+According to PCIe r7.0, sec 7.5.3.5, this register contains:
+
+ - RW1C error status bits (CED, NFED, FED, URD at bits 0-3): These are the
+ four error status bits that need to be cleared.
+
+ - Read-only bits (AUXPD at bit 4, TRPND at bit 5): Writing to these has
+ no effect.
+
+ - Emergency Power Reduction Detected (bit 6): A RW1C non-error bit
+ introduced in PCIe r5.0 (2019). This is currently the only writable
+ non-error bit in the Device Status register. Unconditionally clearing
+ this bit can interfere with other software components that rely on this
+ power management indication.
+
+ - Reserved bits (RsvdZ): These bits are required to be written as zero.
+ Writing 1s to them (as the current implementation may do) violates the
+ specification.
+
+To prevent unintended side effects, modify pcie_clear_device_status() to
+only write 1s to the four error status bits (CED, NFED, FED, URD), leaving
+the Emergency Power Reduction Detected bit and reserved bits unaffected.
+
+Fixes: ec752f5d54d7 ("PCI/AER: Clear device status bits during ERR_FATAL and ERR_NONFATAL")
+Suggested-by: Lukas Wunner <lukas@wunner.de>
+Signed-off-by: Shuai Xue <xueshuai@linux.alibaba.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
+Reviewed-by: Lukas Wunner <lukas@wunner.de>
+Cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/20260211124624.49656-1-xueshuai@linux.alibaba.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/pci.c | 7 +++----
+ 1 file changed, 3 insertions(+), 4 deletions(-)
+
+--- a/drivers/pci/pci.c
++++ b/drivers/pci/pci.c
+@@ -2220,10 +2220,9 @@ EXPORT_SYMBOL_GPL(pci_set_pcie_reset_sta
+
+ void pcie_clear_device_status(struct pci_dev *dev)
+ {
+- u16 sta;
+-
+- pcie_capability_read_word(dev, PCI_EXP_DEVSTA, &sta);
+- pcie_capability_write_word(dev, PCI_EXP_DEVSTA, sta);
++ pcie_capability_write_word(dev, PCI_EXP_DEVSTA,
++ PCI_EXP_DEVSTA_CED | PCI_EXP_DEVSTA_NFED |
++ PCI_EXP_DEVSTA_FED | PCI_EXP_DEVSTA_URD);
+ }
+
+ /**
--- /dev/null
+From 1ab4a3c805084d752ec571efc78272295a9f2f74 Mon Sep 17 00:00:00 2001
+From: Lukas Wunner <lukas@wunner.de>
+Date: Fri, 27 Mar 2026 10:56:43 +0100
+Subject: PCI/AER: Stop ruling out unbound devices as error source
+
+From: Lukas Wunner <lukas@wunner.de>
+
+commit 1ab4a3c805084d752ec571efc78272295a9f2f74 upstream.
+
+When searching for the error source, the AER driver rules out devices whose
+enable_cnt is zero. This was introduced in 2009 by commit 28eb27cf0839
+("PCI AER: support invalid error source IDs") without providing a
+rationale.
+
+Drivers typically call pci_enable_device() on probe, hence the enable_cnt
+check essentially filters out unbound devices. At the time of the commit,
+drivers had to opt in to AER by calling pci_enable_pcie_error_reporting()
+and so any AER-enabled device could be assumed to be bound to a driver.
+The check thus made sense because it allowed skipping config space accesses
+to devices which were known not to be the error source.
+
+But since 2022, AER is universally enabled on all devices when they are
+enumerated, cf. commit f26e58bf6f54 ("PCI/AER: Enable error reporting when
+AER is native").
+
+Errors may very well be reported by unbound devices, e.g. due to link
+instability. By ruling them out as error source, errors reported by them
+are neither logged nor cleared. When they do get bound and another error
+occurs, the earlier error is reported together with the new error, which
+may confuse users. Stop doing so.
+
+Fixes: f26e58bf6f54 ("PCI/AER: Enable error reporting when AER is native")
+Signed-off-by: Lukas Wunner <lukas@wunner.de>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Reviewed-by: Stefan Roese <stefan.roese@mailbox.org>
+Cc: stable@vger.kernel.org # v6.0+
+Link: https://patch.msgid.link/734338c2e8b669db5a5a3b45d34131b55ffebfca.1774605029.git.lukas@wunner.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/pcie/aer.c | 2 --
+ 1 file changed, 2 deletions(-)
+
+--- a/drivers/pci/pcie/aer.c
++++ b/drivers/pci/pcie/aer.c
+@@ -852,8 +852,6 @@ static bool is_error_source(struct pci_d
+ * 3) There are multiple errors and prior ID comparing fails;
+ * We check AER status registers to find possible reporter.
+ */
+- if (atomic_read(&dev->enable_cnt) == 0)
+- return false;
+
+ /* Check if AER is enabled */
+ pcie_capability_read_word(dev, PCI_EXP_DEVCTL, ®16);
--- /dev/null
+From 9a44949da669708f19d29141e65b3ac774d08f5a Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Andr=C3=A9=20Draszik?= <andre.draszik@linaro.org>
+Date: Mon, 2 Mar 2026 13:32:05 +0000
+Subject: power: supply: max17042: avoid overflow when determining health
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: André Draszik <andre.draszik@linaro.org>
+
+commit 9a44949da669708f19d29141e65b3ac774d08f5a upstream.
+
+If vmax has the default value of INT_MAX (e.g. because not specified in
+DT), battery health is reported as over-voltage. This is because adding
+any value to vmax (the vmax tolerance in this case) causes it to wrap
+around, making it negative and smaller than the measured battery
+voltage.
+
+Avoid that by using size_add().
+
+Fixes: edd4ab055931 ("power: max17042_battery: add HEALTH and TEMP_* properties support")
+Cc: stable@vger.kernel.org
+Signed-off-by: André Draszik <andre.draszik@linaro.org>
+Link: https://patch.msgid.link/20260302-max77759-fg-v3-6-3c5f01dbda23@linaro.org
+Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/power/supply/max17042_battery.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/power/supply/max17042_battery.c
++++ b/drivers/power/supply/max17042_battery.c
+@@ -198,7 +198,7 @@ static int max17042_get_battery_health(s
+ goto out;
+ }
+
+- if (vbatt > chip->pdata->vmax + MAX17042_VMAX_TOLERANCE) {
++ if (vbatt > size_add(chip->pdata->vmax, MAX17042_VMAX_TOLERANCE)) {
+ *health = POWER_SUPPLY_HEALTH_OVERVOLTAGE;
+ goto out;
+ }
--- /dev/null
+From c54c7e4cb679c0aaa1cb489b9c3f2cd98e63a44c Mon Sep 17 00:00:00 2001
+From: Jason Gunthorpe <jgg@nvidia.com>
+Date: Tue, 28 Apr 2026 13:17:44 -0300
+Subject: RDMA/mlx4: Fix resource leak on error in mlx4_ib_create_srq()
+
+From: Jason Gunthorpe <jgg@nvidia.com>
+
+commit c54c7e4cb679c0aaa1cb489b9c3f2cd98e63a44c upstream.
+
+Sashiko points out that mlx4_srq_alloc() was not undone during error
+unwind, add the missing call to mlx4_srq_free().
+
+Cc: stable@vger.kernel.org
+Fixes: 225c7b1feef1 ("IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters")
+Link: https://sashiko.dev/#/patchset/0-v1-e911b76a94d1%2B65d95-rdma_udata_rep_jgg%40nvidia.com?part=8
+Link: https://patch.msgid.link/r/11-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/infiniband/hw/mlx4/srq.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/infiniband/hw/mlx4/srq.c
++++ b/drivers/infiniband/hw/mlx4/srq.c
+@@ -193,13 +193,15 @@ int mlx4_ib_create_srq(struct ib_srq *ib
+ if (udata)
+ if (ib_copy_to_udata(udata, &srq->msrq.srqn, sizeof (__u32))) {
+ err = -EFAULT;
+- goto err_wrid;
++ goto err_srq;
+ }
+
+ init_attr->attr.max_wr = srq->msrq.max - 1;
+
+ return 0;
+
++err_srq:
++ mlx4_srq_free(dev->dev, &srq->msrq);
+ err_wrid:
+ if (udata)
+ mlx4_ib_db_unmap_user(ucontext, &srq->db);
--- /dev/null
+From 34fbf48cf3b410d2a6e8c586fa952a36331ca5ba Mon Sep 17 00:00:00 2001
+From: Jason Gunthorpe <jgg@nvidia.com>
+Date: Tue, 28 Apr 2026 13:17:42 -0300
+Subject: RDMA/ocrdma: Don't NULL deref uctx on errors in ocrdma_copy_pd_uresp()
+
+From: Jason Gunthorpe <jgg@nvidia.com>
+
+commit 34fbf48cf3b410d2a6e8c586fa952a36331ca5ba upstream.
+
+Sashiko points out that pd->uctx isn't initialized until late in the
+function so all these error flow references are NULL and will crash. Use
+the uctx that isn't NULL.
+
+Cc: stable@vger.kernel.org
+Fixes: fe2caefcdf58 ("RDMA/ocrdma: Add driver for Emulex OneConnect IBoE RDMA adapter")
+Link: https://sashiko.dev/#/patchset/0-v1-e911b76a94d1%2B65d95-rdma_udata_rep_jgg%40nvidia.com?part=4
+Link: https://patch.msgid.link/r/9-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
++++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
+@@ -618,9 +618,9 @@ static int ocrdma_copy_pd_uresp(struct o
+
+ ucopy_err:
+ if (pd->dpp_enabled)
+- ocrdma_del_mmap(pd->uctx, dpp_page_addr, PAGE_SIZE);
++ ocrdma_del_mmap(uctx, dpp_page_addr, PAGE_SIZE);
+ dpp_map_err:
+- ocrdma_del_mmap(pd->uctx, db_page_addr, db_page_size);
++ ocrdma_del_mmap(uctx, db_page_addr, db_page_size);
+ return status;
+ }
+
--- /dev/null
+From 4c6f86d85d03cdb33addce86aa69aa795ca6c47a Mon Sep 17 00:00:00 2001
+From: Michael Bommarito <michael.bommarito@gmail.com>
+Date: Tue, 14 Apr 2026 07:15:55 -0400
+Subject: RDMA/rxe: Reject unknown opcodes before ICRC processing
+
+From: Michael Bommarito <michael.bommarito@gmail.com>
+
+commit 4c6f86d85d03cdb33addce86aa69aa795ca6c47a upstream.
+
+Even after applying commit 7244491dab34 ("RDMA/rxe: Validate pad and ICRC
+before payload_size() in rxe_rcv"), a single unauthenticated UDP packet
+can still trigger panic. That patch handled payload_size() underflow only
+for valid opcodes with short packets, not for packets carrying an unknown
+opcode. The unknown-opcode OOB read described below predates that commit
+and reaches back to the initial Soft RoCE driver.
+
+The check added there reads
+
+ pkt->paylen < header_size(pkt) + bth_pad(pkt) + RXE_ICRC_SIZE
+
+where header_size(pkt) expands to rxe_opcode[pkt->opcode].length. The
+rxe_opcode[] array has 256 entries but is only populated for defined IB
+opcodes; any other entry (for example opcode 0xff) is zero-initialized, so
+length == 0 and the check degenerates to
+
+ pkt->paylen < 0 + bth_pad(pkt) + RXE_ICRC_SIZE
+
+which does not constrain pkt->paylen enough. rxe_icrc_hdr() then computes
+
+ rxe_opcode[pkt->opcode].length - RXE_BTH_BYTES
+
+which underflows when length == 0 and passes a huge value to rxe_crc32(),
+causing an out-of-bounds read of the skb payload.
+
+Reproduced on v7.0-rc7 with that fix applied, QEMU/KVM with
+CONFIG_RDMA_RXE=y and CONFIG_KASAN=y, after
+
+ rdma link add rxe0 type rxe netdev eth0
+
+A single 48-byte UDP packet to port 4791 with BTH opcode=0xff and
+QPN=IB_MULTICAST_QPN triggers:
+
+ BUG: KASAN: slab-out-of-bounds in crc32_le+0x115/0x170
+ Read of size 1 at addr ...
+ The buggy address is located 0 bytes to the right of
+ allocated 704-byte region
+ Call Trace:
+ crc32_le+0x115/0x170
+ rxe_icrc_hdr.isra.0+0x226/0x300
+ rxe_icrc_check+0x13f/0x3a0
+ rxe_rcv+0x6e1/0x16e0
+ rxe_udp_encap_recv+0x20a/0x320
+ udp_queue_rcv_one_skb+0x7ed/0x12c0
+
+Subsequent packets with the same shape fault on unmapped memory and panic
+the kernel. The trigger requires only module load and "rdma link add"; no
+QP, no connection, and no authentication.
+
+Fix this by rejecting packets whose opcode has no rxe_opcode[] entry,
+detected via the zero mask or zero length, before any length arithmetic
+runs.
+
+Cc: stable@vger.kernel.org
+Fixes: 8700e3e7c485 ("Soft RoCE driver")
+Link: https://patch.msgid.link/r/20260414111555.3386793-1-michael.bommarito@gmail.com
+Assisted-by: Claude:claude-opus-4-6
+Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
+Reviewed-by: Zhu Yanjun <yanjun.zhu@linux.dev>
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/infiniband/sw/rxe/rxe_recv.c | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+--- a/drivers/infiniband/sw/rxe/rxe_recv.c
++++ b/drivers/infiniband/sw/rxe/rxe_recv.c
+@@ -375,6 +375,17 @@ void rxe_rcv(struct sk_buff *skb)
+ pkt->qp = NULL;
+ pkt->mask |= rxe_opcode[pkt->opcode].mask;
+
++ /*
++ * Unknown opcodes have a zero-initialized rxe_opcode[] entry, so
++ * both mask and length are 0. Reject them before any length math:
++ * rxe_icrc_hdr() would otherwise compute length - RXE_BTH_BYTES
++ * and pass the underflowed value to rxe_crc32(), producing an
++ * out-of-bounds read.
++ */
++ if (unlikely(!rxe_opcode[pkt->opcode].mask ||
++ !rxe_opcode[pkt->opcode].length))
++ goto drop;
++
+ if (unlikely(pkt->paylen < header_size(pkt) + bth_pad(pkt) +
+ RXE_ICRC_SIZE))
+ goto drop;
--- /dev/null
+From e38e86995df27f1f854063dab1f0c6a513db3faf Mon Sep 17 00:00:00 2001
+From: Jason Gunthorpe <jgg@nvidia.com>
+Date: Tue, 28 Apr 2026 13:17:43 -0300
+Subject: RDMA/vmw_pvrdma: Fix double free on pvrdma_alloc_ucontext() error path
+
+From: Jason Gunthorpe <jgg@nvidia.com>
+
+commit e38e86995df27f1f854063dab1f0c6a513db3faf upstream.
+
+Sashiko points out that pvrdma_uar_free() is already called within
+pvrdma_dealloc_ucontext(), so calling it before triggers a double free.
+
+Cc: stable@vger.kernel.org
+Fixes: 29c8d9eba550 ("IB: Add vmw_pvrdma driver")
+Link: https://sashiko.dev/#/patchset/0-v1-e911b76a94d1%2B65d95-rdma_udata_rep_jgg%40nvidia.com?part=4
+Link: https://patch.msgid.link/r/10-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/infiniband/hw/vmw_pvrdma/pvrdma_verbs.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/infiniband/hw/vmw_pvrdma/pvrdma_verbs.c
++++ b/drivers/infiniband/hw/vmw_pvrdma/pvrdma_verbs.c
+@@ -350,7 +350,7 @@ int pvrdma_alloc_ucontext(struct ib_ucon
+ uresp.qp_tab_size = vdev->dsr->caps.max_qp;
+ ret = ib_copy_to_udata(udata, &uresp, sizeof(uresp));
+ if (ret) {
+- pvrdma_uar_free(vdev, &context->uar);
++ /* pvrdma_dealloc_ucontext() also frees the UAR */
+ pvrdma_dealloc_ucontext(&context->ibucontext);
+ return -EFAULT;
+ }
nvmet-avoid-recursive-nvmet-wq-flush-in-nvmet_ctrl_free.patch
rdma-hns-fix-unlocked-call-to-hns_roce_qp_remove.patch
s390-debug-reject-zero-length-input-in-debug_input_flush_fn.patch
+pci-aer-clear-only-error-bits-in-pcie-device-status.patch
+pci-aer-stop-ruling-out-unbound-devices-as-error-source.patch
+power-supply-max17042-avoid-overflow-when-determining-health.patch
+rdma-mlx4-fix-resource-leak-on-error-in-mlx4_ib_create_srq.patch
+rdma-ocrdma-don-t-null-deref-uctx-on-errors-in-ocrdma_copy_pd_uresp.patch
+rdma-rxe-reject-unknown-opcodes-before-icrc-processing.patch
+rdma-vmw_pvrdma-fix-double-free-on-pvrdma_alloc_ucontext-error-path.patch
+mptcp-use-mpjoinsynackhmacfailure-for-synack-hmac-failure.patch
+mptcp-use-mptcp_rst_emptcp-for-ack-hmac-validation-failure.patch
+mptcp-sockopt-set-timestamp-flags-on-subflow-socket-not-msk.patch
+mptcp-fix-scheduling-with-atomic-in-timestamp-sockopt.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
