linux-stable.git/drivers, branch v6.18.40

RDMA/bnxt_re: Avoid repeated requests to allocate WC pages

2026-07-24T14:17:26+00:00

commit 441baa79043431807115fd030d7d0bb14ed441a0 upstream.

Applications can request multiple WC pages for the same ucontext.
As of now, only 1 WC page per ucontext is supported. Add a lock to
avoid concurrent access and a check to fail repeated requests.
Also, if the mmap entry insert fails for the WC, free the Doorbell
page index mapped for the WC page.

Fixes: eee6268421a2 ("RDMA/bnxt_re: Move the UAPI methods to a dedicated file")
Fixes: 360da60d6c6e ("RDMA/bnxt_re: Enable low latency push")
Link: https://patch.msgid.link/r/20260615224751.232802-12-selvin.xavier@broadcom.com
Reviewed-by: Kalesh AP 
Signed-off-by: Selvin Xavier 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Greg Kroah-Hartman

RDMA/bnxt_re: Initialize dpi variable to zero

2026-07-24T14:17:26+00:00

commit 978b27d6ce538bb832ccd69e45802824e4301c4b upstream.

dpi is initialized only for BNXT_RE_ALLOC_WC_PAGE, but copied
for all the cases. So initialize the dpi to 0.

Fixes: eee6268421a2 ("RDMA/bnxt_re: Move the UAPI methods to a dedicated file")
Fixes: 360da60d6c6e ("RDMA/bnxt_re: Enable low latency push")
Link: https://patch.msgid.link/r/20260615224751.232802-2-selvin.xavier@broadcom.com
Reviewed-by: Anantha Prabhu 
Signed-off-by: Kalesh AP 
Signed-off-by: Selvin Xavier 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Greg Kroah-Hartman

PCI: Fix Resizable BAR restore order

2026-07-24T14:17:26+00:00

commit 5528fd38f230c906fcebb202cc94fbb8ed8f122a upstream.

The commit 337b1b566db0 ("PCI: Fix restoring BARs on BAR resize rollback
path") changed BAR resize to layer rebar code and resource setup/restore
code cleanly. Unfortunately, it did not consider how the value of the BAR
Size field impacts the read-only bits in the Base Address Register (PCIe7
spec, sec. 7.8.6.3). That is, it very much matters in which order the BAR
Size and Base Address Register are restored.

Post-337b1b566db0 ("PCI: Fix restoring BARs on BAR resize rollback path")
during BAR resize rollback, pci_do_resource_release_and_resize() attempts
to restore the old address to the BAR that was resized, but it can fail to
setup the address correctly if the address has low bits set that collide
with the bits that are still read-only. As a result, kernel's resource and
BAR will be out-of-sync.

Fix this by restoring BAR Size before rolling back the resource changes and
restoring the BAR.

Fixes: 337b1b566db0 ("PCI: Fix restoring BARs on BAR resize rollback path")
Reported-by: Ville Syrjälä 
Link: https://lore.kernel.org/linux-pci/aW_w1oFQCzUxGYtu@intel.com/
Signed-off-by: Ilpo Järvinen 
Signed-off-by: Bjorn Helgaas 
Tested-by: Ville Syrjälä 
Reviewed-by: Ville Syrjälä 
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260121131417.9582-3-ilpo.jarvinen@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

PCI: Fix BAR resize rollback path overwriting ret

2026-07-24T14:17:26+00:00

commit 08d9eae76b85263173f8c833800e3cc409ee1be4 upstream.

The commit 337b1b566db0 ("PCI: Fix restoring BARs on BAR resize rollback
path") added BAR rollback to pci_do_resource_release_and_resize() in case
of resize failure.

On the rollback, pci_claim_resource() is called, which can fail and the
code is prepared for that possibility. pci_claim_resource()'s return value,
however, overwrites the original value of ret so
pci_do_resource_release_and_resize() will return an incorrect value in the
end (as pci_claim_resource() normally succeeds, in practice ret will be 0).

Fix the issue by directly calling pci_claim_resource() inside the if ().

Fixes: 337b1b566db0 ("PCI: Fix restoring BARs on BAR resize rollback path")
Reported-by: Ville Syrjälä 
Link: https://lore.kernel.org/linux-pci/aW_w1oFQCzUxGYtu@intel.com/
Signed-off-by: Ilpo Järvinen 
Signed-off-by: Bjorn Helgaas 
Tested-by: Ville Syrjälä 
Reviewed-by: Ville Syrjälä 
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260121131417.9582-2-ilpo.jarvinen@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

pinctrl: airoha: fix pinctrl function mismatch issue

2026-07-24T14:17:26+00:00

commit f2bd5a0f59d052d16749bccf637690e51947a5d6 upstream.

The blamed commit made the following changes:

-#define PINCTRL_FUNC_DESC(id)...
-		.desc = PINCTRL_PINFUNCTION(#id, ...
+#define PINCTRL_FUNC_DESC(id, table)...
+		.desc = PINCTRL_PINFUNCTION(#id, ...

-	PINCTRL_FUNC_DESC(pon)...
+	PINCTRL_FUNC_DESC("pon", pon)...

It's clear that the id of funcs doesn't match the definition.
Remove redundant #string from the definition to fix this issue:
pinctrl-airoha ...: invalid function mdio in map table

Fixes: 4043b0c45f85 ("pinctrl: airoha: generalize pins/group/function/confs handling")
Signed-off-by: Chukun Pan 
Acked-by: Christian Marangi 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

iommufd: Move vevent memory allocation outside spinlock

2026-07-24T14:17:26+00:00

[ Upstream commit 47443565d10c51366c9382dbc8597cd6c460b8a2 ]

The veventq memory allocation happens inside the spinlock. Given its depth
is decided by the user space, this leaves a vulnerability, where userspace
can allocate large queues to exhaust atomic memory reserves.

Move the allocation outside the spinlock and use GFP_NOWAIT, which can fail
fast under memory pressure without dipping into the GFP_ATOMIC reserves or
direct-reclaiming from the threaded IRQ handler. On allocation failure,
queue the lost_events_header (so userspace learns of the drop) and return
-ENOMEM so the caller learns of the kernel-side memory pressure.

This is intentionally distinct from the queue-overflow path, which also
queues the lost_events_header but returns 0: a full queue is an expected
userspace-pacing condition rather than a kernel error.

A subsequent change will cap the upper bound of the veventq_depth.

Fixes: e36ba5ab808e ("iommufd: Add IOMMUFD_OBJ_VEVENTQ and IOMMUFD_CMD_VEVENTQ_ALLOC")
Link: https://patch.msgid.link/r/5ff36b5d80f7f6299f851be532a5195c1d2f1dae.1779408671.git.nicolinc@nvidia.com
Cc: stable@vger.kernel.org
Reviewed-by: Jason Gunthorpe 
Signed-off-by: Nicolin Chen 
Reviewed-by: Kevin Tian 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

iommufd: Propagate allocation failure in iommufd_veventq_deliver_fetch()

2026-07-24T14:17:26+00:00

[ Upstream commit 489e63dd120bad52eba63f5506c214750cd5bc75 ]

When the kzalloc_obj() fails in iommufd_veventq_deliver_fetch(), it returns
NULL, falsely advertising to userspace that the queue is empty.

Propagate the -ENOMEM properly to the caller.

Fixes: e36ba5ab808e ("iommufd: Add IOMMUFD_OBJ_VEVENTQ and IOMMUFD_CMD_VEVENTQ_ALLOC")
Link: https://patch.msgid.link/r/25d29feac909e36f78c145fa99ef2d4cb7a415da.1780343944.git.nicolinc@nvidia.com
Cc: stable@vger.kernel.org
Signed-off-by: Nicolin Chen 
Reviewed-by: Pranjal Shrivastava 
Reviewed-by: Kevin Tian 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

crypto: qat - fix restarting state leak on allocation failure

2026-07-24T14:17:25+00:00

[ Upstream commit 7d3ed20f7e46b3e991936fedd7a28f3ff4aec8d2 ]

In adf_dev_aer_schedule_reset(), ADF_STATUS_RESTARTING is set before
allocating reset_data. If the allocation fails, the function returns
-ENOMEM without queuing reset work, so nothing ever clears the bit.
This leaves the device permanently stuck in the restarting state,
causing all subsequent reset attempts to be silently skipped.

Fix this by using test_and_set_bit() to atomically claim the
RESTARTING state, preventing duplicate reset scheduling races under
concurrent fatal error reporting. If the subsequent allocation fails,
clear the bit to restore clean state so future reset attempts can
proceed.

Cc: stable@vger.kernel.org
Fixes: d8cba25d2c68 ("crypto: qat - Intel(R) QAT driver framework")
Signed-off-by: Ahsan Atta 
Co-developed-by: Maksim Lukoshkov 
Signed-off-by: Maksim Lukoshkov 
Reviewed-by: Giovanni Cabiddu 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

crypto: atmel-sha204a - fail on hwrng registration error in probe path

2026-07-24T14:17:25+00:00

[ Upstream commit 49e05bb00f2e8168695f7af4d694c39e1423e8a2 ]

Commit 13909a0c8897 ("crypto: atmel-sha204a - provide the otp content")
overwrote the hwrng registration return value when creating the sysfs
group, which allowed atmel_sha204a_probe() to succeed even if
devm_hwrng_register() failed.

Return immediately when devm_hwrng_register() fails, and report both
hwrng and sysfs registration errors with dev_err(). Adjust the sysfs
error log message for consistency.

Fixes: 13909a0c8897 ("crypto: atmel-sha204a - provide the otp content")
Cc: stable@vger.kernel.org
Signed-off-by: Thorsten Blum 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

usb: gadget: f_fs: Tie read_buffer lifetime to ffs_epfile

2026-07-24T14:17:24+00:00

[ Upstream commit 8bdcf96eb135aebacac319667f87db034fb38406 ]

Currently, ffs_epfile_release unconditionally frees the endpoint's
read_buffer when a file descriptor is closed. If userspace explicitly
opens the endpoint multiple times and closes one, the read_buffer is
destroyed. This can lead to silent data loss if other file descriptors
are still actively reading from the endpoint.

By tying the lifetime of the read_buffer to the ffs_epfile structure itself
(which is destroyed when the functionfs instance is torn down in
ffs_epfiles_destroy), we eliminate the brittle dependency on open/release
calls while correctly matching the conceptual lifetime of unread data on
the hardware endpoint.

Fixes: 9353afbbfa7b ("usb: gadget: f_fs: buffer data from ‘oversized’ OUT requests")
Cc: stable 
Assisted-by: Antigravity:gemini-3.1-pro
Signed-off-by: Neill Kapron 
Link: https://patch.msgid.link/20260619040609.4010746-3-nkapron@google.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman