linux-stable.git/include, branch linux-rolling-stable

iomap: consolidate bio submission

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

[ Upstream commit 044472d5ee7d71f918fa3f61bd65e4933a0c006e ]

Add a iomap_bio_submit_read_endio helper factored out of
iomap_bio_submit_read to that all ->submit_read implementations for
iomap_read_ops that use iomap_bio_read_folio_range can shared the
logic.

Right now that logic is mostly trivial, but already has a bug for XFS
because the XFS version is too trivial:  file system integrity validation
needs a workqueue context and thus can't happen from the default iomap
bi_end_io I/O handler.  Unfortunately the iomap refactoring just before
fs integrity landed moved code around here and the call go misplaced,
meaning it never got called.  The PI information still is verified by
the block layer, but the offloading is less efficient (and the future
userspace interface can't get at it).

Fixes: 0b10a370529c ("iomap: support T10 protection information")
Cc: stable@vger.kernel.org # v7.1
Signed-off-by: Christoph Hellwig 
Link: https://patch.msgid.link/20260629121750.3392300-2-hch@lst.de
Acked-by: Namjae Jeon 
Reviewed-by: "Darrick J. Wong" 
Reviewed-by: Joanne Koong 
Signed-off-by: Christian Brauner (Amutable) 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()

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

[ Upstream commit 6fef032af0092ed5ccb767239a9ac1bc38c08a40 ]

l2cap_sock_new_connection_cb() returned l2cap_pi(sk)->chan after
release_sock(parent). Once the parent lock is dropped the newly
enqueued child socket sk is reachable via the accept queue, so another
task can accept and free it before the callback dereferences sk,
resulting in a use-after-free.

Rework the ->new_connection() op so the core, rather than the callback,
owns the child channel's lifetime. The op now receives a pre-allocated
new_chan and returns an errno instead of allocating and returning a
channel. l2cap_new_connection() allocates the child channel and links
it into the conn list via __l2cap_chan_add() before invoking the
callback, so the conn-list reference keeps the channel alive once
release_sock(parent) exposes the socket to other tasks.

Channel configuration that was duplicated in l2cap_sock_init() and the
various new_connection callbacks is consolidated into
l2cap_chan_set_defaults(), which now inherits from the parent channel
when one is supplied.

Fixes: 8ffb929098a5 ("Bluetooth: Remove parent socket usage from l2cap_core.c")
Cc: stable@kernel.org
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Siwei Zhang 
Signed-off-by: Luiz Augusto von Dentz 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

firmware_loader: Add cancel helper for async requests

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

[ Upstream commit b9bdd68b8b979c7e9de58b2e7d21e1d7d932c755 ]

request_firmware_nowait() keeps the callback module pinned and holds
a device reference until the firmware work completes.

Callers still have no way to cancel or synchronize the queued callback
before tearing down their driver-private state.

Track scheduled async firmware work in an internal list and add
request_firmware_nowait_cancel(). The helper cancels work matching the
device, callback context and callback function. It cancels work that has
not started yet and waits for an already-running callback to return. If
the request has already completed, it is a no-op.

Keep the existing request_firmware_nowait() lifetime model manual. A
devres-managed variant can be layered on top separately if needed.

Signed-off-by: Cássio Gabriel 
Reviewed-by: Takashi Iwai 
Acked-by: Danilo Krummrich 
Signed-off-by: Takashi Iwai 
Link: https://patch.msgid.link/20260505-alsa-hda-tas2781-fw-callback-teardown-v4-1-e7c4bf930dc8@gmail.com
Stable-dep-of: 5367e2ad14f0 ("ALSA: hda/tas2781: Cancel async firmware request at unbind")
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

device property: initialize the remaining fields of fwnode_handle in fwnode_init()

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

[ Upstream commit 7eba000621fff223dd7bab484d48918c7c77a307 ]

If a firmware node is allocated on the stack (for instance: temporary
software node whose life-time we control) or on the heap - but using a
non-zeroing allocation function - and initialized using fwnode_init(),
its secondary pointer will contain uninitialized memory which likely
will be neither NULL nor IS_ERR() and so may end up being dereferenced
(for example: in dev_to_swnode()). Set fwnode->secondary to NULL on
initialization. While at it: initialize the remaining fields of struct
fwnode_handle too just to be sure.

Cc: stable@vger.kernel.org
Fixes: 01bb86b380a3 ("driver core: Add fwnode_init()")
Reviewed-by: Sakari Ailus 
Reviewed-by: Rafael J. Wysocki (Intel) 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Bartosz Golaszewski 
Link: https://patch.msgid.link/20260511074927.9473-1-bartosz.golaszewski@oss.qualcomm.com
[ Fix typo in commit message. - Danilo ]
Signed-off-by: Danilo Krummrich 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

wifi: ieee80211: validate MLE common info length

2026-07-24T14:21:22+00:00

commit 293baeae9b2434a3e432629d7720b5603db2d77e upstream.

ieee80211_mle_common_size() uses the first common-info octet as the
common information length for all known MLE types. However,
ieee80211_mle_size_ok() only validates that octet for Basic, Probe
Request, and TDLS MLEs.

Reconfiguration MLEs also skipped the length octet when calculating the
minimum common size, and Priority Access MLEs skipped validation of the
advertised common information length.

Account for the Reconfiguration common-info length octet and validate
the advertised common information length for all known MLE types. Keep
unknown-type handling unchanged.

Fixes: 0f48b8b88aa9 ("wifi: ieee80211: add definitions for multi-link element")
Cc: stable@vger.kernel.org
Signed-off-by: Zhao Li 
Link: https://patch.msgid.link/20260611173506.36838-2-enderaoelyther@gmail.com
[remove now misleading comment]
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

ACPICA: Define acpi_ut_safe_strncpy() as strscpy_pad() alias

2026-07-24T14:21:16+00:00

commit 9825cf2cb59fac7480e7fac9eee13ab9af3f1ea8 upstream.

Commit 292db66afd20 ("ACPICA: Unbreak tools build after switching over
to strscpy_pad()") added an #ifdef based on a __KERNEL__ check which is
sort of nasty to the acpi_ut_safe_strncpy() definition to unbreak ACPICA
tools builds broken by commit 97f7d3f9c9ac ("ACPICA: Replace strncpy()
with strscpy_pad() in acpi_ut_safe_strncpy()").  However, that #ifdef
effectively produces dead code when tools are built because they don't
call acpi_ut_safe_strncpy().

Accordingly, drop the existing definition of acpi_ut_safe_strncpy() and
define it as a strscpy_pad() alias.

Fixes: 292db66afd20 ("ACPICA: Unbreak tools build after switching over to strscpy_pad()")
Signed-off-by: Rafael J. Wysocki 
[ rjw: Tweak the changelog ]
Link: https://patch.msgid.link/12941764.O9o76ZdvQC@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

net: mana: Sync page pool RX frags for CPU

2026-07-24T14:21:14+00:00

commit c72a0f09c57f92113df69f9b902d11c9e4b132f5 upstream.

MANA allocates RX buffers from page pool fragments when frag_count is
greater than 1. In that case the buffers remain DMA mapped by page pool
and the RX completion path does not call dma_unmap_single(). As a result,
the implicit sync-for-CPU normally performed by dma_unmap_single() is
missing before the packet data is passed to the networking stack.

This breaks RX on configurations which require explicit DMA syncing, for
example when booted with swiotlb=force.

Fix this by recording the page pool page and DMA sync offset when the RX
buffer is allocated, and syncing the received packet range for CPU access
before handing the RX buffer to the stack.

Fixes: 730ff06d3f5c ("net: mana: Use page pool fragments for RX buffers instead of full pages to improve memory efficiency.")
Cc: stable@vger.kernel.org
Reviewed-by: Haiyang Zhang 
Signed-off-by: Dexuan Cui 
Link: https://patch.msgid.link/20260702041237.617719-3-decui@microsoft.com
Signed-off-by: Paolo Abeni 
Signed-off-by: Greg Kroah-Hartman

remoteproc: xlnx: Check remote core state

2026-07-24T14:20:57+00:00

commit a48df51d23138388900995add2854cda4aa68e55 upstream.

The remote state is set to RPROC_DETACHED if the resource table is found
in the memory. However, this can be wrong if the remote is not started,
but firmware is still loaded in the memory. Use PM_GET_NODE_STATUS call
to the firmware to request the state of the RPU node. If the RPU is
actually out of reset and running, only then move the remote state to
RPROC_DETACHED, otherwise keep the remote state to RPROC_OFFLINE.

Signed-off-by: Tanmay Shah 
Fixes: bca4b02ef92e ("remoteproc: xlnx: Add attach detach support")
Reviewed-by: Beleswar Padhi 
Acked-by: Michal Simek 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20260428221855.313752-1-tanmay.shah@amd.com
Signed-off-by: Mathieu Poirier 
Signed-off-by: Greg Kroah-Hartman

netfilter: flowtable: support IPIP tunnel with direct xmit

2026-07-24T14:20:53+00:00

commit fa7395c02d95e51bad2952325d2d6503bfbad437 upstream.

The combination of IPIP tunnel with direct xmit, eg. bridge device,
breaks because no dst_entry is provided to check the skb headroom and to
set the iph->frag_off field. This leads to invalid dst usage and can
trigger a crash in the tunnel transmit path.

Fix this by moving dst_cache and dst_cookie out of the runtime union so
that they can be shared by neighbour, xfrm, and direct tunnel flows.
For FLOW_OFFLOAD_XMIT_DIRECT tuples carrying tunnel metadata, preserve
route state in these shared fields and release it through the common
dst release path.

Since dst_entry is now available to the three supported xmit modes and
dst_release() already deals with NULL dst, remove the xmit type check
in nft_flow_dst_release(). Moreover, skip the check if the dst entry
is NULL in nf_flow_dst_check() which is now the case for the direct
xmit case.

Based on patch from Rein Wei .

Fixes: d30301ba4b07 ("netfilter: flowtable: Add IPIP tx sw acceleration")
Cc: stable@vger.kernel.org
Reported-by: Yuan Tan 
Reported-by: Xin Liu 
Reported-by: Zhengyang Chen 
Reported-by: Ren Wei 
Signed-off-by: Pablo Neira Ayuso 
Acked-by: Lorenzo Bianconi 
Signed-off-by: Florian Westphal 
Signed-off-by: Greg Kroah-Hartman

netfilter: nf_queue: pin bridge device while NFQUEUE holds fake dst

2026-07-24T14:20:53+00:00

commit c9c9b37f8c5505224e8d206184df3bb668ee00cf upstream.

The br_netfilter fake rtable is embedded in struct net_bridge and is
attached to bridged packets with skb_dst_set_noref(). If such a packet is
queued to NFQUEUE, __nf_queue() upgrades that fake dst with
skb_dst_force().

At that point the queued skb can hold a real dst reference after bridge
teardown has started. The problem is not that every bridged packet needs
its own dst reference. The problem is that NFQUEUE can keep the bridge
private fake dst alive after unregister begins.

Fix this by keeping the bridge fake dst model unchanged and pinning the
bridge master device only while the packet sits in NFQUEUE. Record the
bridge device in nf_queue_entry when the queued skb carries a bridge fake
dst, take a device reference for the queue lifetime, and drop it when the
queue entry is freed.

Also make sure queued entries are reaped when that bridge device goes
down, and drop the redundant nf_bridge_info_exists() test from the fake
dst detection.

This keeps netdev_priv(br->dev) alive until verdict completion, so the
embedded fake rtable and its metrics backing storage cannot be freed out
from under dst_release(). It also avoids the constant refcount bump and
avoids using ipv4-specific dst helpers for IPv6 bridge traffic.

Fixes: 34666d467cbf ("netfilter: bridge: move br_netfilter out of the core")
Cc: stable@kernel.org
Reported-by: Yuan Tan 
Reported-by: Yifan Wu 
Reported-by: Juefei Pu 
Reported-by: Xin Liu 
Signed-off-by: Haoze Xie 
Signed-off-by: Ren Wei 
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Greg Kroah-Hartman