The current compiler hint annotation is wrong, due to inverted
logic in the previous revision of the relevant code.
Fixes: e468d37118 ("mptcp: implemented OoO queue pruning")
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-14-df1de70348b6@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When sending a DATA_FIN without data, and because the DATA_FIN occupies
1 octet of the connection-level sequence space [1], it is then required
to add a DSS mapping with specific values.
If the checksum has been negotiated, it also needs to be computed, and
included in the outgoing packet, and thus the initial csum data needs to
be reset to 0 as well. This is no longer the case since commit
cfcceb7a39 ("tcp: shrink per-packet memset in __tcp_transmit_skb()"),
because the whole ext_copy structure is no longer zeroed by default.
This seems to be the only case where use_map is changed and set
afterwards, so initialising the csum field only in this case, along with
other fields for this specific case.
Fixes: cfcceb7a39 ("tcp: shrink per-packet memset in __tcp_transmit_skb()")
Cc: stable@vger.kernel.org
Link: https://datatracker.ietf.org/doc/html/rfc8684#section-3.3.3 [1]
Link: https://sashiko.dev/#/patchset/20260812-net-next-mptcp-misc-feat-7-3-v1-0-1905a818f6cb%40kernel.org?part=2
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-13-df1de70348b6@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When the value for a MIB counter is required, mptcp_lib_get_counter is
called. It tries to use the cache, if available. If not it falls back to
calling 'nstat' directly by looking at the absolute counters.
That's an issue for tests that don't recreate the netns for each
subtest. In this case, 'nstat -a' will look at the counters for the
netns.
Instead, it should look at the increment for the current test, by using
the history recorded in /tmp/<ns>.nstat, if available, and not using
'-a' which was dumping the absolute values.
While at it, rename the previous 'hist' variable to 'cache' as it was
used to look at the cache, not the nstat history.
Fixes: 71388a9f33 ("selftests: mptcp: lib: get counters from nstat history")
Cc: stable@vger.kernel.org
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-12-df1de70348b6@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In case of errors, mptcp_lib_pr_nstat is called to dump the nstat
counters, but for some tests, it was dumping the counters for all
subtests, not just the current one.
That's an issue for tests that don't recreate the netns for each
subtest, e.g. mptcp_connect.sh. In this case, 'nstat -a' will look at
the absolute counters since the creation of the netns, making
debugging harder.
Instead, it should dump the counters for the current test, by using the
history recorded in /tmp/<ns>.nstat if available, and not using '-a'
which was dumping the absolute values instead of calculating increments.
While at it, rename the previous 'hist' variable to 'cache' as it was
used to look at the cache, not the nstat history.
Fixes: 658e531417 ("selftests: mptcp: join: dump stats from history")
Cc: stable@vger.kernel.org
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-11-df1de70348b6@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The subflow->fully_established flag is always written under the subflow
socket lock. Reading such value under the same lock does not require any
ONCE annotation.
Fixes: 581c8cbfa9 ("mptcp: annotate data-races around subflow->fully_established")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-10-df1de70348b6@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When all MPTCP address IDs (1-255) are exhausted in the userspace PM,
find_next_zero_bit() returns MPTCP_PM_MAX_ADDR_ID + 1 (256). This value
overflows when stored in the u8 field e->addr.id, resulting in ID 0
being stored and the entry being incorrectly added to the list.
ID 0 is reserved for the initial connection in MPTCP, so this overflow
can cause address conflicts.
Note: the in-kernel PM already has an 'endpoints == MPTCP_PM_MAX_ADDR_ID'
check in mptcp_pm_nl_append_new_local_addr() that returns -ERANGE before
reaching find_next_zero_bit(), preventing this overflow. So this fix only
addresses the userspace PM path.
Check the find_next_zero_bit() result against MPTCP_PM_MAX_ADDR_ID and
return -ENOSPC if all IDs are truly exhausted. Move the ID allocation
check before the memory allocation so that the error path does not need
to free the allocated entry.
Fixes: 4638de5aef ("mptcp: handle local addrs announced by userspace PMs")
Cc: stable@vger.kernel.org
Signed-off-by: Qing Luo <luoqing@kylinos.cn>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-8-df1de70348b6@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
At the end of 'sock_connect_mptcp()', it calls 'freeaddrinfo(addr)',
the 'peer' pointer (which points into 'addr') remains. Later, the main
loop uses this peer pointer for reconnection attempts. If the memory has
been freed and reused, the address data could be overwritten, resulting
in an invalid remote address.
This patch keeps the addrinfo list allocated for the whole process
lifetime so "peer" remains valid across reconnects; the memory will be
released at exit() time.
Fixes: 05be5e273c ("selftests: mptcp: add disconnect tests")
Cc: stable@vger.kernel.org
Suggested-by: Paolo Abeni <pabeni@redhat.com>
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/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-7-df1de70348b6@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Sashiko noted that the two event can race, leading to inconsistent
status. Prevent the race using the synchronous timer stop operation.
Cc: stable@vger.kernel.org
Fixes: b29fcfb54c ("mptcp: full disconnect implementation")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-6-df1de70348b6@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Before this modification, a remote peer could send an MP_CAPABLE with
data, with the checksum flag set, but without adding the actual 2 bytes
of checksum. As a result, uninitialised bytes could be used for the
'csum' field.
That was not a critical issue, because this 'csum' field is only used to
compare with the expected one, if previously negotiated in the 3WHS.
Worst case, the checksum is likely wrong, a fallback is done without a
reject if the negotiation was done earlier. That's OK.
Yet, better to take the expected path with this case: only look at the
checksum flag for MP_CAPABLEs not carrying a data-len.
Such packet can be seen as a 3rd or 4th ACK. The RFC8684 mentions [1]
that the 3rd packet should have the checksum flag set. When an MPC + ACK
contains data, the checksum flag is redundant with the checksum field.
It is not clear what should be done for the 4th ACK, nor if the flag has
to be set if the checksum field is set.
Therefore, it seems fine to only look at the presence of the checksum
field, not to break the interaction with stacks that were not setting
both.
Note that linked to this checksum flag on the 3rd ACK, with the current
implementation, we can have a situation where the SYN packets have no
checksum flag, but the 3rd ACK has one, and this is the one that will be
taken into account. First, that's clearly not directly linked to this
patch, but Clashiko forced us to look at that. At the end, that seems
fine to act like that: yes that's not how the negotiation should work,
but being flexible without introducing side effects is also fine: fixing
this would mean increasing the complexity, and that's not worth it.
Fixes: 208e8f6692 ("mptcp: receive checksum for MP_CAPABLE with data")
Cc: stable@vger.kernel.org
Link: https://datatracker.ietf.org/doc/html/rfc8684#section-3.1-23 [1]
Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-0-b8f496d71664%40kernel.org?part=1
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-5-df1de70348b6@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The in-kernel MPTCP path manager can leave a stale ADD_ADDR announcement
entry alive when removing the id 0 endpoint. This happens because the id 0
removal path does not tear down pending announcements, unlike the non-zero
id path.
When the PM later reselects id 0 after adding another signal endpoint, it
finds the stale anno_list entry and hits WARN_ON_ONCE(mptcp_pm_is_kernel())
in mptcp_pm_announced_alloc().
Root cause: asymmetry between removal paths.
- Non-zero id path: mptcp_nl_remove_subflow_and_signal_addr() calls
mptcp_pm_remove_announced() to clean up.
- Id 0 path: mptcp_nl_remove_id_zero_address() skips cleanup entirely.
Fix by making the id 0 path symmetric: call mptcp_pm_announced_remove()
and decrement add_addr_signaled before queuing the RM_ADDR.
Subtle detail: signal endpoints are stored in anno_list with port 0, but
msk_local carries the connection's local port. In other words, entries
linked to ID0 paths should have port == 0. A follow-up patch will ensure
that. mptcp_pm_announced_remove() uses use_port=true for comparison. So
clear the port before the lookup.
Fixes: 740d798e87 ("mptcp: remove id 0 address")
Cc: stable@vger.kernel.org
Reported-by: syzbot+55c2a5c871441261ed14@syzkaller.appspotmail.com
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/620
Suggested-by: Tao Cui <cuitao@kylinos.cn>
Signed-off-by: Kalpan Jani <kalpan.jani@mpiricsoftware.com>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-4-df1de70348b6@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Instead of using an uninitialised bit when copying the info in
subflow_ulp_clone().
To fix this, no need to extend the join_entry structure: backup is
coming from struct mptcp_subflow_request_sock, only one bit. Do the same
here by using one bit for both.
Fixes: efd340bf3d ("mptcp: distinguish rcv vs sent backup flag in requests")
Cc: stable@vger.kernel.org
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-3-df1de70348b6@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
'thmac' is not used after that point.
Indeed, subflow_ulp_clone() is called when the request on the passive
side is over, so when the truncated HMAC is no longer needed.
Note that in case of SYN cookies, thmac will not be initialised. So
better to remove it to avoid a warning from debug tools like KMSAN for
reading uninitialised data.
Fixes: f296234c98 ("mptcp: Add handling of incoming MP_JOIN requests")
Cc: stable@vger.kernel.org
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-2-df1de70348b6@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
On fallback socket the retrans timer is a quite convoluted no-op, but
currently nothing prevents the MPTCP core to keep rescheduling it.
Additionally gate RTX timer reset to the msk not being fallen back to
TCP yet. To avoid adding multiple tests in fast-path, use a new flags
bit for such condition.
The RTX enable bit is clear at close time and set before the msk could
start retransmitting, with a couple of caveats:
- passive sockets inherit the bit from the listener msk; set the bit on
such socket to avoid flipping it in the fast-path, even if the
listener will obviously never retransmit.
- while fastopening (MPTFO), mptcp_sendmsg_fastopen still ends-up
calling mptcp_connect via tcp_sendmsg_fastopen ->
__inet_stream_connect(ssk->sk_socket), and the first subflow's
sk_socket points to the msk one.
Fixes: b51f9b80c0 ("mptcp: introduce MPTCP retransmission timer")
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-1-df1de70348b6@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The legacy FCS tagger calculates the CRC over skb->len bytes starting at
skb->data. When a nonlinear skb reaches the tagger, this reads past the
linear head into unrelated slab memory.
The tagger appends an Ethernet FCS but does not declare that tailroom. As a
result, DSA leaves NETIF_F_SG and NETIF_F_FRAGLIST enabled on the user
port, and nonlinear skbs can reach the CRC calculation.
Declare the required tailroom. DSA will then clear those features and the
networking core will linearize skbs before the tagger runs.
A KASAN-enabled dsa_loop test using this tagger reports:
BUG: KASAN: slab-out-of-bounds in crc32_le
Read of size 1 at addr ffff8880397086c0 by task exp/135
Call Trace:
crc32_le (lib/crc/crc32-main.c:38)
brcm_leg_fcs_tag_xmit (net/dsa/tag_brcm.c:343)
dsa_user_xmit (net/dsa/user.c:942)
dev_hard_start_xmit (net/core/dev.c:3937)
__dev_queue_xmit (net/core/dev.c:4926)
packet_sendmsg (net/packet/af_packet.c:3110)
__sys_sendto (net/socket.c:2281)
The buggy address belongs to the object at ffff888039708400
which belongs to the cache skbuff_small_head of size 704
The buggy address is located 0 bytes to the right of
allocated 704-byte region [ffff888039708400, ffff8880397086c0)
Fixes: ef07df397a ("net: dsa: tag_brcm: add support for legacy FCS tags")
Cc: stable@vger.kernel.org
Reported-by: co+28eef7d8af9428e6@bugs.sh
Closes: https://lore.kernel.org/all/jH6u350kaBRuqklDjd3k3BW4nWzp0tYRjq3p%40bugs.sh/
Signed-off-by: Weiming Shi <bestswngs@gmail.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://patch.msgid.link/20260908165047.2786340-1-bestswngs@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
napi_id.py intermittently fails to start its helper on Intel and Google
HW runners:
CMD: /srv/netdev/drivers/net/napi_id_helper 3001::1 37569
EXIT: 1
STDERR: bind failed: Cannot assign requested address
Either keep_addr_on_down is not set or more likely the address is
configured without nodad. Having to make sure that all tests
always wait for DAD after impacting the link would be a whack-a-mole
so we expect the env to have nodad and keep_addr_on_down set.
Warn about both while validating the environment, and document this.
We could fail completely but most tests don't impact the link so for
quick local testing it'd be annoying to have to apply the settings.
I hope the warninging stikes the right balance.
Link: https://patch.msgid.link/20260908181956.1357684-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add source address and port verification in recv_verify_packet_* and
recv_udp: non-matching packets are skipped.
The receiver reads from PF_PACKET and UDP sockets to verify incoming
packets to test hardware checksum offload. It did not validate the
packet source address or source port.
During tests expecting an invalid checksum (-E) or zero checksum (-Z),
background packets can fail the test.
For -Z, build_packet_udp chooses a specific source port that causes
the checksum to sum to zero. When running in receive-only mode (-R),
call build_packet in do_rx to compute the expected source port so
that source port filtering can be applied to -Z as well.
Also
- add an inter-packet delay to avoid drops from bursts.
- remove a comment that is no longer correct.
Fixes: 91a7de8560 ("selftests/net: add csum offload test")
Signed-off-by: Willem de Bruijn <willemb@google.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260908155537.813889-1-willemdebruijn.kernel@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
An LWT_SEG6LOCAL program can invalidate its cached SRH with
bpf_lwt_seg6_adjust_srh() and then call bpf_skb_pull_data(). The latter
may reallocate skb->head, leaving the per-CPU SRH pointer dangling.
Post-program SRH validation then writes through that pointer.
Disallow bpf_skb_pull_data() for LWT_SEG6LOCAL programs so the verifier
rejects this unsafe helper combination. Other LWT program types continue
to expose the helper through lwt_out_func_proto().
Fixes: 004d4b274e ("ipv6: sr: Add seg6local action End.BPF")
Reported-by: co+adfca3e91be95776@bugs.sh
Suggested-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Signed-off-by: Weiming Shi <bestswngs@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>
Closes: https://lore.kernel.org/all/GCy0KRM2IcQGoJQTjJEU9D0maBxXzEDHuQpq@bugs.sh/
Link: https://lore.kernel.org/bpf/DL9COXZQXX4V.1FN45QO2Q77ZH@gmail.com/
Link: https://lore.kernel.org/bpf/20260909040807.3885815-2-bestswngs@gmail.com
-----BEGIN PGP SIGNATURE-----
iIYEABYKAC4WIQSVyBthFV4iTW/VU1/l49DojIL20gUCaqF0GxAcbWljQGRpZ2lr
b2QubmV0AAoJEOXj0OiMgvbSs+YBALj3Ttl+T8cnEmxExfOYnPt6eL+oIsZFo6HU
zSXUqyiNAQDxtpucp/JgwBNbuk0XA+BfLSVWuw94jdqbPpCrjUW0BA==
=egGv
-----END PGP SIGNATURE-----
Merge tag 'landlock-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/mic/linux
Pull Landlock fixes from Mickaël Salaün:
"This fixes a use-after-free and a lockdep assert NULL dereferencing,
and properly truncates too-long strings printed by a Landlock
tracepoint. Most of the changes are brought by new tests"
* tag 'landlock-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/mic/linux:
landlock: Test trace path output boundaries
landlock: Bound escaped trace path output
landlock: Clean up ruleset validation checks
selftests/landlock: Test abstract socket trace name limits
landlock: Fix use-after-free of the source's parent directory
A monitor PPDU may span multiple status buffers. However,
__ath12k_wifi7_dp_mon_process_ring() clears mon_ppdu_info before
processing every buffer.
As a result, continuation buffers lose PPDU state collected from
earlier buffers, including ppdu_id and PHY metadata.
This can cause monitor RX processing to fail when
ath12k_wifi7_dp_rx_mon_dest_process() observes a PPDU ID mismatch
between status and destination rings, preventing MSDUs from being
delivered. It can also produce incomplete EHT metadata that triggers
warnings from mac80211:
Rate marked as an EHT rate but data is invalid: MCS:0, NSS:0
ath12k_wifi7_dp_mon_srng_process() already tracks status TLV
continuations via ppdu_continuation. Apply the same logic here and
only reinitialize mon_ppdu_info when starting a new PPDU.
mon_ppdu_info persists across ar->monitor_started transitions. If
monitor mode stops while a PPDU is mid-continuation, ppdu_continuation
stays set and could leak into the next monitor session. Reset it
when monitor mode starts.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3
Fixes: 78d3d907d0 ("wifi: ath12k: add support to reap and process monitor status ring")
Signed-off-by: Kang Yang <kang.yang@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Tamizh Chelvam Raja <tamizh.raja@oss.qualcomm.com>
Link: https://patch.msgid.link/20260828065534.1537-1-kang.yang@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
When external IRQ configuration fails, the driver does not release all
IRQs that were successfully requested before the failure. This can leak
IRQ resources during probe failure.
Free previously requested external IRQs when external IRQ configuration
fails.
Also remove the NAPI instance with netif_napi_del() before freeing the
associated netdev to properly clean up the NAPI resources.
Store the IRQ number only after request_irq() succeeds to avoid recording
an IRQ that was not successfully requested.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
Fixes: d889913205 ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260819110215.2485514-3-aaradhana.sahu@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
When CE IRQ configuration fails, the driver does not release all IRQs
that were successfully requested before the failure. This can leak IRQ
resources during probe failure.
Free the previously requested CE IRQs before returning from the error
path to ensure that partially initialized IRQ resources are properly
cleaned up during probe failure.
Factor out the CE IRQ cleanup into a helper to reuse the cleanup logic
during both error handling and driver teardown.
Also free CE IRQs when external IRQ configuration fails, before
returning from the error path.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
Fixes: d889913205 ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260819110215.2485514-2-aaradhana.sahu@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
ath12k_wifi7_hal_tx_cmd_ext_desc_setup() programs the low 32 bits of the
TX buffer physical address into HAL_TX_MSDU_EXT_INFO0_BUF_PTR_LO but
hardcodes the high bits field HAL_TX_MSDU_EXT_INFO1_BUF_PTR_HI to 0x0.
dma_addr_t is 64-bit on platforms with CONFIG_ARCH_DMA_ADDR_T_64BIT, so
whenever a TX buffer is mapped above the 4 GB boundary the upper bits of
paddr are dropped and the firmware is handed a truncated address,
leading to potential TX failures.
Write the upper bits of paddr into BUF_PTR_HI to fix this issue.
Issue found during code review, compile tested only.
Fixes: d889913205 ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Link: https://patch.msgid.link/20260818-ath12k-truncated-tx-dma-addr-v1-1-ead978969371@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
ath12k_wifi7_dp_tx() caches hdr, eth, and skb_cb from the skb before
calling ath12k_dp_tx_align_payload(). That function may shift skb->data
in place (when headroom or tailroom is sufficient) or reallocate the
buffer entirely via skb_realloc_headroom(), freeing the original skb.
In either case hdr, eth, and skb_cb are left pointing into stale memory.
After alignment, only hdr is refreshed, leaving eth and skb_cb stale.
skb_cb is written immediately after (storing DMA addresses), and eth is
re-read on every TCL ring retry via the tcl_ring_sel goto, so both
accesses are use-after-free or stale-pointer bugs depending on which
alignment path was taken.
Refresh eth (conditionally, to preserve the encap-mode distinction) and
skb_cb alongside hdr after ath12k_dp_tx_align_payload() returns, so all
three point into the live skb for all subsequent accesses.
Issue found during code review, compile tested only.
Fixes: 38055789d1 ("wifi: ath12k: use 128 bytes aligned iova in transmit path for WCN7850")
Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Link: https://patch.msgid.link/20260818-ath12k-uaf-for-aligned-tx-v1-1-d6ae195b15e7@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
ath12k_wifi7_dp_tx() maps the original MSDU into ti.paddr and
stores the address in skb_cb->paddr. When an extended MSDU descriptor
is used, the function later maps the ext descriptor and overwrites
ti.paddr and ti.data_len with the ext-desc DMA address and length.
If TCL ring allocation then fails, the error path first unmaps the
ext-desc DMA address from skb_cb->paddr_ext_desc. It then falls through
to fail_unmap_dma, which uses ti.paddr/ti.data_len for the original
MSDU unmap. At that point ti.paddr still refers to the ext-desc
mapping, so the ext descriptor is unmapped twice and the original MSDU
mapping is left mapped.
Fix the original MSDU unwind to use skb_cb->paddr and skb->len instead
of ti.paddr/ti.data_len. The ti fields cannot be used after the ext
descriptor is mapped because they are intentionally reused for the
buffer submitted to TCL. Also clear skb_cb->paddr_ext_desc after the
ext-desc unmap so a TCL ring retry cannot observe stale ext-desc DMA
state from the previous attempt.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
Fixes: 37a068fc9d ("wifi: ath12k: Handle error cases during extended skb allocation")
Signed-off-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260813-ext-msdu-fix-v1-1-c5e80ccd061a@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
On failure, ath12k_mac_setup_channels_rates() frees band channel
arrays but leaves the pointers set, or clears the wrong band after a
copy-paste typo (6 GHz free paired with a 2 GHz NULL). Clear the
matching sbands[].channels pointer after each kfree().
Compile tested only.
Signed-off-by: Linkai Gong <gonglinkai@kylinos.cn>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260811020523.387433-1-gonglinkai@kylinos.cn
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Replace the userspace stdint types uint64_t/uint8_t with the kernel
types u64/u8 to conform to the surrounding ath12k code, which uses the
kernel types everywhere else.
No functional changes, compile tested only.
Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Link: https://patch.msgid.link/20260819-ath12k-cleanup-userspace-types-v1-1-161a1e8910f5@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Only the two QCN9274 hw_params advertise NL80211_IFTYPE_AP_VLAN; the
IPQ5332 entry does not. ath12k sets SW_CRYPTO_CONTROL, so mac80211 does
not add the mode on the driver's behalf either -- ieee80211_alloc_hw_nm()
only does that for drivers that leave SW_CRYPTO_CONTROL clear, leaving
the declaration to drivers that can transmit software-encrypted frames.
AP/VLAN is therefore absent from the wiphy, and creating an AP_VLAN
interface without NL80211_ATTR_4ADDR is rejected by
cfg80211_iftype_allowed():
nl80211: Failed to create interface <name>: -95 (Operation not supported)
That is the path hostapd uses for dynamic per-station VLANs, in
hostapd_vlan_if_add(). The 4-address (WDS) case is not affected, as
cfg80211_iftype_allowed() short-circuits it on WIPHY_FLAG_4ADDR_AP,
which mac80211 sets unconditionally at alloc time.
The QCN9274 entries already declare AP_VLAN, and the transmit path is
shared Wi-Fi 7 code with no per-chip or per-bus gating, so IPQ5332 can
deliver it as well. AP_VLAN is a software interface type, so no
interface combination changes are needed.
On a mixed-bus single-wiphy group the effect is wider still, since
ath12k_mac_get_ifmodes() intersects interface_modes across all radios:
one IPQ5332 masks AP_VLAN for the QCN9274 radios too.
Advertise AP_VLAN on IPQ5332 as QCN9274 does. With the mode advertised,
a non-4addr AP_VLAN interface can be created on an AP interface of an
IPQ5332 + 2x QCN9274 single-wiphy group:
# iw dev phy0.0-ap0 interface add tvlan0 type __ap_vlan
# iw dev tvlan0 info
Interface tvlan0
ifindex 19
wdev 0x9
addr 00:03:7f:12:0b:0b
type AP/VLAN
wiphy 0
Radios: 0 1 2
RADIUS-assigned dynamic VLANs were not exercised end to end.
Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01270-QCAHKSWPL_SILICONZ-1
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
Signed-off-by: Kamil Bienkiewicz <perceivalpercy@gmail.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Link: https://patch.msgid.link/20260828005126.1685832-1-perceivalpercy@gmail.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
In this function, we iterate over dp->reo_cmd_cache_flush_list using
list_for_each_entry_safe(), under dp->reo_cmd_lock for concurrent access,
and for each expired entries we :
- drop the lock
- call ath11k_dp_reo_cache_flush()
- kfree() the entry
- retake the lock to keep on iterating
list_for_each_entry_safe() protects us from deleting the entry during
iteration but doesn't protect for concurrent access. So another thread can
take the lock and modify the list in between and crash like below.
To fix the issue, move all entries that needs to be freed to a local list
while under the lock and then iterate over the list to free the entries
without holding the lock.
BUG: Unable to handle kernel paging request at virtual address 00000010ddbeef8c
Call trace:
ath11k_dp_rx_tid_del_func+0x164/0x3c8
ath11k_dp_process_reo_status+0x1d4/0x2fc
ath11k_dp_service_srng+0x334/0x338
ath11k_pcic_ext_grp_napi_poll+0x30/0xc0
__napi_poll+0x34/0x184
napi_threaded_poll+0xb4/0x1d8
kthread+0xdc/0xe0
ret_from_fork+0x10/0x20
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.9.0.1-01977-QCAHKSWPL_SILICONZ-1
Fixes: d5c65159f2 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Suggested-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Signed-off-by: Nicolas Escande <nico.escande@gmail.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Link: https://patch.msgid.link/20260813-ath11k-locking-v2-1-f4113a0bd0f4@gmail.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
The previous logic in ath11k_ce_rx_post_pipe() incorrectly required both
dest_ring and status_ring to be NULL in order to exit the function.
This caused the function to continue even if only one of the pointers
was NULL, potentially leading to null pointer dereferences in
ath11k_ce_rx_buf_enqueue_pipe().
Fix the condition by modifying the logic so that the function returns
early if either dest_ring or status_ring is NULL.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: d5c65159f2 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Signed-off-by: Mikhail Lobanov <m.lobanov@rosalinux.ru>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Link: https://patch.msgid.link/20240909150824.28195-1-m.lobanov@rosalinux.ru
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Commit 493f349e38 ("memblock: Add flags and nid info in memblock
debugfs") made memblock_debug_show() stop after finding the first set
flag. A memblock region can carry multiple flags, so the remaining flags
are hidden from debugfs.
Walk all bits in the region flags and print every set flag separated by
"|". Keep walking beyond flagname[] so that a set flag without a known
name is reported as UNKNOWN rather than silently ignored.
Fixes: 493f349e38 ("memblock: Add flags and nid info in memblock debugfs")
Signed-off-by: Meijing Zhao <zhaomeijing@lixiang.com>
Link: https://patch.msgid.link/20260902075944.3742866-1-zhaomeijing100@gmail.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
- Fix potential multiplication overflow when calculating freq in OPP
core (Colin Ian King).
- Fix use after free in _update_opp_table_clk() (Peter Griffin).
- Use %pe to print symbolic error name (Sumeet Pawnikar).
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEx73Crsp7f6M6scA70rkcPK6BEhwFAmqg6SAACgkQ0rkcPK6B
EhxfIhAAiZ1MRiCnpxWJXo3dt37MGjzB6UrZ/S+PR51i4EyV1aLkU9gfgQA3T+Tz
pnPTGzvTRUYNf0ASNXR0faDUYffbfgW9k4RhZB5WKa/gmYOlgvkDRkNIH5WhSBr7
wmoSKjL93FrEiwdDHbOqacQUqdAyZS0t4HsDSmDGaHvAzuR9jyHyvEg448nZ3leA
+saVPt/PMyhid9v/DqEOfz4WLCfMAhrEvbbIl0qn0ySut8PLP95u+sXVpbUi3x1d
cKeNfwXjjEyFhqLptByr8dr6G9GUu2GY8jvwPRLKN9gLglq+lKo8ZMm1vWOSQ+Qt
D+vbXShKz33ijNhRy/acAsYGuz6aWqLQirlqq1l3+XQLdAOaHN5s/8cnXfUcieBJ
e3oXDJA6bwFMMi0LA15TMgfUn5S9Fx3Cr4PVctdhjgbFfyATDDSgXSGEP0GJr3xI
ChoYTSXDn7vnBb1jo+HWBfw4nqrMScBTksU70e6dKlvk1SyHWI2MM2k3qoSCgh4j
/s3FtLj31nstDuyDOvxGkhBW5qpnX+iiLwq6TzKLL6Sr/9AqoV8TcrOpTLizqzXW
0hkb/fUJEgtwN1gTm3Un7jStpjE5Gki6HWeCRPV+ybo+TbxfFBwemDE1TqCZ8GHY
7jhaa/ioxR6qPEH8LdQ9lTCrxma9eXzP814M3xXaqgAD/mjr6S8=
=78fU
-----END PGP SIGNATURE-----
Merge tag 'opp-updates-7.3.rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm
Merge OPP updates for 7.3-rc3 from Viresh Kumar:
"- Fix potential multiplication overflow when calculating freq in OPP
core (Colin Ian King).
- Fix use after free in _update_opp_table_clk() (Peter Griffin).
- Use %pe to print symbolic error name (Sumeet Pawnikar)."
* tag 'opp-updates-7.3.rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm:
opp: fix use after free in _update_opp_table_clk()
opp: Use %pe to print symbolic error name
OPP: of: Fix potential multiplication overflow when calculating freq
These four started failing with some change not merged thru the msm tree.
Update xfails to reflect reality.
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Please consider pulling these changes from the signed vfs-7.3-rc3.fixes tag.
Thanks!
Christian
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQRAhzRXHqcMeLMyaSiRxhvAZXjcogUCaqFWOQAKCRCRxhvAZXjc
otLlAP9X02ybdUt9NndBK8LjslDWwB9hOXzPgYsOKYODEqODjQD/aLpbXVEsA1yy
SLdSDtbtpf+01z4KHorvAakBzk/jrw4=
=OzBX
-----END PGP SIGNATURE-----
Merge tag 'vfs-7.3-rc3.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs
Pull vfs fixes from Christian Brauner:
- netfs:
- Fix an uninitialized return value in netfs_unbuffered_write()
when preparing the first subrequest fails
- For partial unbuffered/DIO writes return the amount transferred
rather than an error
- Update i_size with the amount actually written when a partial
transfer ends in an error
- Fix a subrequest reference leak when the io_iter ends up empty
- Handle netfs_alloc_subrequest() failure during unbuffered writes
- Load all readahead folios into the rolling buffer upfront and
drop the readahead references once the first subrequest is
dispatched
- Mark folios for copy-to-cache while issuing subrequests
- Fix read progress reporting
- afs:
- Add the missing kunmap in the error path of afs_dir_search_bucket()
- Fix a double kunmap in afs_edit_dir_remove()
- Don't free an existing server's endpoint state when cleaning up a
candidate server in afs_lookup_server()
- Unbind peers removed from a server's address list
- ufs:
- Load the cylinder group metadata before creating the root dentry
- Validate the cylinder group index and rotor positions before
caching them
- Treat an unreadable directory block as not empty
- exec:
- Close the close-on-exec files before taking exec_update_lock
Closing a file can block on the filesystem, so a hung filesystem
blocked everything that takes exec_update_lock and a FUSE server
inspecting the calling process could deadlock
- Drop the bprm loader before closing bprm->file in free_bprm()
- exit: Hold a reference to thread_pid across proc_flush_pid()
- reboot: Fix a use-after-free on cad_pid
- nsfs: Keep the namespace tree fields out of the rcu_head used by
kfree_rcu()
- nstree: Check listing permission before taking a namespace
reference in listns()
- super: Return 0 when a nested thaw drops its hold while other
freezers remain
- ext4: Don't set I_METADATA_WRITEBACK during fastcommit replay
- adfs: Free s_fs_info in ->kill_sb()
- autofs: Free the inode info allocated in autofs_fill_super() when
the root inode allocation fails
- ovl: Return EINVAL instead of EIO on a user namespace mismatch now
that it's a plain refusal and not an internal error
- cachefiles: Don't cast the variable-length coherency data to a
__be64 in the coherency tracepoint
* tag 'vfs-7.3-rc3.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: (28 commits)
nstree: check listing permission before taking a namespace reference
exec: do_close_on_exec() before taking exec_update_lock
exit: hold a reference to thread_pid across proc_flush_pid
fs: autofs: fix memory leak in autofs_fill_super()
exec: Drop bprm loader before closing bprm->file
afs: Clear stale peer app data after address list changes
afs: Fix incorrect free in candidate cleanup in afs_lookup_server()
afs: Fix double-unmap of directory block
afs: Fix missing kunmap in afs_dir_search_bucket()
ovl: return EINVAL instead of EIO in case of mismatched user_ns
reboot: fix cad_pid use-after-free race
cachefiles: Fix potential UAF/KASAN warning
netfs: Fix read progress reporting
netfs: Mark folios with COPY_TO_CACHE whilst issuing subreqs
netfs: Fix readahead synchronisation issues by loading all folios upfront
netfs: break unbuffered write when netfs_alloc_subrequest() fails
netfs: Fix subreq ref leak
netfs: Fix i_size update for partial transfer
netfs: Fix error vs transferred passed to ->ki_complete()
netfs: Fix unbuffered/DIO write partial transfer error return
...
io_do_iopoll() assigns the result of io_put_kbuf() to the request's CQE
flags upon completion. This overwrites any CQE flags that may have been
set by the opcode-specific layer. (For example, if __io_uring_cmd_done()
had set IORING_CQE_F_32, it would be cleared.) Switch the = to an |= so
the kbuf flags are added to the existing CQE flags rather than replacing
them. io_req_rw_complete() does the same with the io_put_kbuf() result.
Fixes: e26dca67fd ("io_uring: add support for IORING_SETUP_CQE_MIXED")
Reported-by: sashiko-bot@kernel.org
Link: https://sashiko.dev/#/message/20260827191705.D53C91F000E9%40smtp.kernel.org
Signed-off-by: Caleb Sander Mateos <csander@purestorage.com>
Reviewed-by: Anuj Gupta <anuj20.g@samsung.com>
Link: https://patch.msgid.link/20260902210200.2336720-1-csander@purestorage.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
When a recv/recvmsg is issued with MSG_TRUNC and the incoming packet is
larger than the provided buffer, the net layer returns the full length
of the packet rather than the number of bytes actually copied into the
buffer. As a result, io_uring advances more of the provided buffer ring
than was actually filled. Use the actual filled region size to consume
the buffer, but still return the full size to preserve MSG_TRUNC
semantics.
Take care with multishot, because that seems to already truncate the
consumption based on the available payload size.
This was reported in https://github.com/axboe/liburing/issues/1619.
Fixes: ae98dbf43d ("io_uring/kbuf: add support for incremental buffer consumption")
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260728191454.1850326-1-krisman@suse.de
Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de>
Link: https://patch.msgid.link/20260902230041.1320658-3-krisman@suse.de
[axboe: fold in size_t unsigned fix]
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Just a ton of small fixes all over the place.
Also includes virtio and virtio-rng MAINTAINERS updates.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
-----BEGIN PGP SIGNATURE-----
iQFDBAABCgAtFiEEXQn9CHHI+FuUyooNKB8NuNKNVGkFAmqhKYcPHG1zdEByZWRo
YXQuY29tAAoJECgfDbjSjVRppBUIAK/QswxhFU0fUQPFQ4YU5xB8/ANGBBpaE1D0
D6g7LYJsB9SguzdiSWOK8BV9/2h8A485yoU98kQBHLCM/Qraclr/t8sNel0Vq3V/
FZmCW21EQZnbcsEbct5WlBlU2veUP2mAhBlRruHEFdMil/W2k4ifF26jFnKAgS8y
ixirBte0LRCo/Ho42D2mZrY40Z1viRKL03Uhl4jiJz+16bx8uRWGd0UELjr7fMT0
095HUYvOdCFLLedhFe9LFN5VFb+gy/iQjv/wOBAcwjjwHNIIAF40gedu8bRh8ovu
ZA17syGe5DjLnp/C1nnEwZhGSDngVEC/aBogKXKJ1MHtVbVZn+A=
=3WXI
-----END PGP SIGNATURE-----
Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost
Pull virtio fixes from Michael Tsirkin:
"Just a ton of small fixes all over the place.
Also includes virtio and virtio-rng MAINTAINERS updates"
* tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost: (27 commits)
vduse: return compat ioctl results directly
virtio_input: stop callbacks before unregistering input device
virtio_input: reset device if input_register_device() fails
vhost: invalidate vring access on IOTLB transitions
vduse: validate virtqueue alignment
vduse: do not take dev->rwsem in the virtqueue kick path
vhost-scsi: clamp max_io_vqs module parameter
vhost-scsi: use kvzalloc for vq array allocation
virtio-pci: return IRQ_HANDLED after non-zero ISR
virtio: add Eugenio Pérez as Maintainer
vhost: limit outstanding IOTLB misses per virtqueue
MAINTAINERS: Add a section for virtio-rng
vdpa_sim_net: check TX pull result before RX copy
vdpa_sim_blk: reject out-of-range sector starts
virtio-vdpa: Use queue id when setting vq affinity
vdpa: octeon_ep: Check dev_set_name() in dev add
vdpa: ifcvf: Put device on unsupported feature error
vdpa: solidrun: Free IRQs after request failure
vdpa: alibaba: Keep DRIVER_OK clear if IRQ setup fails
vdpa/pds: check virtqueue notify mapping
...
emit_render_cache_flush() sets PIPE_CONTROL0_HDC_PIPELINE_FLUSH to
flush the L2/HDC data cache before fence signalling, but it never
requests a flush of the LSC untyped L1 data cache via the 'Untyped
Data-Port Cache Flush Enable' bit in PIPE_CONTROL DWord0[11].
Per the Bspec, in 3D pipeline mode HDC Pipeline Flush is documented to
also flush/invalidate the untyped L1 cache, but only depending on how
HDC_CHICKEN0[13:11] is programmed. Starting with MTL, this coupling
between HDC Pipeline Flush and the untyped L1 cache flush no longer
holds in practice, regardless of how HDC_CHICKEN0 is programmed, so
relying on it is not safe on newer platforms such as BMG. Mesa's Vulkan
driver (anv) has been assuming the kernel flushes both caches between
submissions, and hit user-visible corruption in apps such as Llama.cpp
because of this gap; it now works around it by flushing both caches
again from userspace at the end of every command buffer.
Correctness between submissions on the same queue is userspace's
responsibility and belongs in Mesa, not the kernel. However, for
security we must ensure stale data can't leak through the untyped L1
dataport cache once memory is reclaimed or evicted, which requires the
KMD to flush it before releasing memory for reuse.
Prior to MTL, HDC_CHICKEN0 could be programmed (as already done for
DG2 via Wa_22010960976/Wa_14013347512) to reliably keep HDC Pipeline
Flush coupled to the untyped L1 cache flush, so those platforms are
unaffected. Mesa's own anv driver found that on MTL the HW
disconnected the two independently of how HDC_CHICKEN0 is programmed,
and could not bring the old behavior back even by writing the register
by hand; see Mesa commit 7c2ff46a4fc3 ("anv: don't prevent L1 untyped
cache flush in 3D mode"). The kernel can't reliably request the flush
from the CS on MTL either, so restrict the new PIPE_CONTROL bit to
GRAPHICS_VERx100 >= 2000 (Xe2 and later), where it can be relied on.
Explicitly set PIPE_CONTROL0_UNTYPED_DATAPORT_CACHE_FLUSH together
with PIPE_CONTROL0_HDC_PIPELINE_FLUSH in emit_render_cache_flush() on
Xe2 and later, so the L1 data cache is known clean before memory is
released for reuse, without depending on undocumented
platform-specific HDC_CHICKEN0 behavior.
Bspec: 56551
Link: 7c2ff46a4f
Fixes: 9f8f93bee3 ("drm/xe: Emit a render cache flush after each rcs/ccs batch")
Reported-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/8909
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: intel-xe@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v6.8+
Assisted-by: GitHub_Copilot:claude-sonnet-5
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patch.msgid.link/20260903114552.48634-1-thomas.hellstrom@linux.intel.com
(cherry picked from commit 434514b6fe)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
During VM teardown, the VM's runtime PM reference is dropped
asynchronously, allowing the device to autosuspend while stale page
faults belonging to the now-dead VM are still queued. When the
page-fault worker later tries to ack one of these, it calls into
guc_ct_send_locked() on an already-suspended device, tripping:
Assertion `!xe_pm_runtime_suspended(xe)` failed!
WARNING at xe_device.c:1267 xe_device_assert_mem_access+0x11c/0x140 [xe]
A live VM/exec queue always holds a PM reference while it has
outstanding work, so if the device is suspended at ack time, the
owning context is already gone and the fault is stale.
Take a runtime PM reference across the entire pagefault
queue worker to safely deliver acks for torn-down VMs.
v3:
- Move PM ref to the generic xe_pagefault_queue_work using
guard(xe_pm_runtime)(xe) instead of tracking it in the GuC
backend(Matt Brost).
v2:
- Hold PM ref across the entire batch (begin/end) instead of per-ack.
This prevents the device from autosuspending mid-batch, which would
leave write_only acks written but the end flush skipped, and skip
counter++, desyncing the cadence check.(Himal)
- Add a comment explaining stale faults.(Himal)
Fixes: f289f78071 ("drm/xe: Add xe_guc_pagefault layer")
Signed-off-by: Varun Gupta <varun.gupta@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
Link: https://patch.msgid.link/20260907050011.497181-2-varun.gupta@intel.com
Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
(cherry picked from commit fcc2431d22)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
[Rodrigo: Added xe_device struct for compatibility while cherry-picking]
The error handling of sn65dsi83_reset_pipe() in sn65dsi83_reset_work() has
seen a couple of changes that seems to cause a bit of confusion.
While sn65dsi83_reset_work() has implemented an early exit if
sn65dsi83_reset_pipe() fails since it was added, when a commit from Maxime
Ripard switched to use drm_bridge_helper_reset_crtc() [1] the
sn65dsi83_reset_pipe() function would no longer return an error code, so
the early exit was then a no-op, and even on sn65dsi83_reset_pipe()
failure, enable_irq() has been called.
When drm_bridge_enter()/drm_bridge_exit() resource protection was added,
the drm_bridge_exit() incidentally was always called, which is the correct
approach. But only because the early exit in sn65dsi83_reset_pipe() was
never hit because sn65dsi83_reset_pipe() always returns 0.
In order get back to a situation where enable_irq() is not called on
sn65dsi83_reset_pipe() failure, which should help protect against irq
storms, we need to reintroduce a non-zero return value from
sn65dsi83_reset_pipe() on error, and fix sn65dsi83_reset_work() so that we
always exit the DRM bridge critical section with drm_bridge_exit().
[1] commit e17fadff7a ("drm/bridge: ti-sn65dsi83: Switch to drm_bridge_helper_reset_crtc")
[2] commit d2e8d1bc84 ("drm/bridge: ti-sn65dsi83: protect device resources on unplug")
Fixes: e17fadff7a ("drm/bridge: ti-sn65dsi83: Switch to drm_bridge_helper_reset_crtc")
Cc: stable@vger.kernel.org
Signed-off-by: Esben Haabendal <esben@geanix.com>
Reviewed-by: Herve Codina <herve.codina@bootlin.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Link: https://patch.msgid.link/20260831-ti-sn65dsi83-fixes-v5-1-e712765d6c4f@geanix.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
replace_sids_and_copy_aces() and set_chmod_dacl() accumulate the size of
the DACL they build in a u16. That accumulator can wrap.
validate_dacl() caps num_aces at (dacl_size - sizeof(struct smb_acl)) /
20, i.e. 3276 for a maximally sized DACL, while each rewritten ACE can
grow to sizeof(struct smb_ace) (76 bytes) once its SID is replaced with
one carrying SID_MAX_SUB_AUTHORITIES sub-authorities. The worst case is
therefore sizeof(struct smb_acl) + 3276 * 76 = 248984 bytes, far beyond
what a u16 can hold. A wraparound is reached with 863 ACEs.
After the wraparound, ndacl_ptr->size becomes meaningless and the offset
will point anywhere in the ACE array. As a result, we will see
corruption of the DACL, which then gets sent to the server. This is not
an out-of-bounds write as the allocation now covers the worst-case
expansion, so writes will always go into the buffer.
Adjust the code to use a u32 internally and return -EOVERFLOW in the
overflow case. The operation must be refused, because a DACL can only
hold 2^16-1 bytes on the wire and larger DACLs cannot be represented.
set_chmod_dacl() carries the same pattern and is fixed the same way. It
only wraps once the source DACL comes within roughly 380 bytes of the
64K ceiling, but the failure mode is identical.
Suggested-by: Namjae Jeon <linkinjeon@kernel.org>
Cc: stable@vger.kernel.org
Fixes: f506550889 ("cifs: Retain old ACEs when converting between mode bits and ACL.")
Assisted-by: Kiro:claude-opus-5
Signed-off-by: Bjoern Doebel <doebel@amazon.de>
Reviewed-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Paulo Alcantara <pc@manguebit.org>
When id_mode_to_cifs_acl rewrites an existing DACL, it allocates a
buffer sized according to the on-disk DACL length reported by
dacl_ptr->size. However, replace_sids_and_copy_aces may rewrite each
ACE with a new owner/group SID obtained from the cifs.idmap upcall.
Those SIDs can have up to SID_MAX_SUB_AUTHORITIES (15) sub-authorities,
making each ACE up to 76 bytes (sizeof(struct smb_ace)).
If the original DACL contains short SIDs (e.g., 1 sub-authority) while
the replacement SIDs are long, the rewritten ACEs overflow the
allocation.
Fix this by always budgeting for worst-case SID expansion: allocate
sizeof(struct smb_acl) plus num_aces * sizeof(struct smb_ace), which
covers the smb_acl header and room for every ACE at maximum SID size.
This replaces the previous split logic that used dacl_ptr->size for
cifsacl mounts but num_aces * sizeof(struct smb_ace) for mode_from_sid
mounts: both paths can trigger the same rewrite and need the same
headroom.
KASAN reports this as:
BUG: KASAN: slab-out-of-bounds in build_sec_desc+0x1e8a/0x2680 [cifs]
Write of size 4 at addr ffff8881a5e25374 by task chown/5298
...
The buggy address is located 0 bytes to the right of
allocated 884-byte region [ffff8881a5e25000, ffff8881a5e25374)
Cc: stable@vger.kernel.org
Fixes: bc3e9dd9d1 ("cifs: Change SIDs in ACEs while transferring file ownership.")
Assisted-by: Kiro:claude-opus-4.6
Signed-off-by: Bjoern Doebel <doebel@amazon.de>
Reviewed-by: Namjae Jeon <linkinjeon@kernel.org>
Fixes: 5c3564852c58 ("cifs: Minimize the number of cifs_acl memory allocations")
Signed-off-by: Paulo Alcantara <pc@manguebit.org>
The documentation file for the AYANEO platform EC driver was added as
Documentation/ABI/testing/sysfs-platform-ayaneo-ec, but MAINTAINERS
references it without the '-ec' suffix, causing 'make refcheckdocs'
to report a broken reference.
Update the file entry to point to the correct file name.
Signed-off-by: Gabriel Windlin <gawindlin@gmail.com>
Link: https://patch.msgid.link/20260908203412.608606-1-gawindlin@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
An unusually large batch of fixes here, partly due to me not sending a
pull request last week and partly due to Linus' fixes for the Ericsson
systems. I'm fairly sure he's the only user there so it seemed low risk
to handle as fixes. We also have a batch of error handling fixes from
Cezary and issues with uninitialised stream_config->type from Shuming
both of which had user error reports attached. Otherwise everything is
a fairly normal combination of quirks and device specific fixes.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmqhUAkACgkQJNaLcl1U
h9AeYwf/ZuSXRQJlCkshmJ5qlQDZeYBWs7o0QPW4wA1ZpM0yvq7CP9LExjdsXB+J
wP+H6D99ecoG5aUooecjHg/lemLzYHYNUMyT/Dte+VAXg80CoiY70nsGoz5ocpGp
R0u9wSILanSfD4GeJti1X5A5aqex9hR0ad2nmrdVefd4+pLlcjFxwDLISiVLbXb4
1bIzNjeXnYsLxp7HIZFrWabpdUm3qt4e7/m3MrD2DMlNu9cq6VMuXmeB3NY/Jo6T
wbQpp7EAPox7P/isS4Sl1PiundIzYrOUU55ySYPLltg9BBVt2RDXXPKZ3xCg0UKF
FXOde+WwIa12Ppasl8SQWEMfQ63WFA==
=ye1f
-----END PGP SIGNATURE-----
Merge tag 'asoc-fix-v7.3-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v7.3
An unusually large batch of fixes here, partly due to me not sending a
pull request last week and partly due to Linus' fixes for the Ericsson
systems. I'm fairly sure he's the only user there so it seemed low risk
to handle as fixes. We also have a batch of error handling fixes from
Cezary and issues with uninitialised stream_config->type from Shuming
both of which had user error reports attached. Otherwise everything is
a fairly normal combination of quirks and device specific fixes.
The previous commit 2c51457d93 ("wifi: mac80211: free ack status
frame on TX header build failure") cleaned up the leak, but still
left the code a bit messy and the failed SKB didn't get reported
to userspace.
Fix this up by initialising skb->cb[] earlier, which allows using
ieee80211_free_txskb() and therefore reports it for the failure
in ieee80211_build_hdr(), and unifies the ieee80211_skb_resize()
failure path with it.
Assisted-by: LLM
Fixes: c3e7724b6b ("mac80211: use ieee80211_free_txskb to fix possible skb leaks")
Link: https://patch.msgid.link/20260908122838.201719-22-johannes@sipsolutions.net
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
ieee80211_join_mesh() acquires a channel context and then calls
ieee80211_start_mesh(), which can fail. In that case, the chanctx
isn't released then interface removal will attempt to unassign it
after it's removed from the driver, hitting:
wlan0: Failed check-sdata-in-driver check, flags: 0x0
WARNING: net/mac80211/driver-ops.c:366 at drv_unassign_vif_chanctx
ieee80211_assign_link_chanctx
__ieee80211_link_release_channel
ieee80211_link_release_channel
ieee80211_teardown_sdata
unregister_netdevice_many_notify
_cfg80211_unregister_wdev
ieee80211_remove_interfaces
ieee80211_unregister_hw
mac80211_hwsim_del_radio
hwsim_exit_net
Correctly release the channel on start failures.
Assisted-by: LLM
Reported-by: syzbot+63a84ea9c0f57d6133fa@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=63a84ea9c0f57d6133fa
Fixes: 2b5e196775 ("mac80211: cache mesh beacon")
Link: https://patch.msgid.link/20260908122838.201719-21-johannes@sipsolutions.net
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
ifmsh->csa is allocated in ieee80211_mesh_csa_beacon() and only freed
in ieee80211_mesh_finish_csa(), i.e. when the channel switch completes.
Leaving the mesh while a switch is still pending therefore leaks it.
Additionally, ifmsh->csa_role and ifmsh->chsw_ttl have their state leak
in this case, so things can get mixed up in addition to the memory
leak.
Refactor the reset and call it in ieee80211_stop_mesh() to fix it all.
Assisted-by: LLM
Reported-by: syzbot+f5752cd6b94fe38be666@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=f5752cd6b94fe38be666
Fixes: b8456a14e9 ("{nl,cfg,mac}80211: implement mesh channel switch userspace API")
Link: https://patch.msgid.link/20260908122838.201719-20-johannes@sipsolutions.net
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
