act_ife encapsulates/decapsulates the original Ethernet header and uses
skb->dev->hard_header_len as the length of that header. That is only
correct for Ethernet devices: on a device where hard_header_len does not
match the L2 header that was actually pulled (PPP reports PPP_HDRLEN
while nothing is stripped on ingress), the ingress skb_push()/skb_pull()
use the wrong length and can hit skb_under_panic when headroom is tight.
IFE is Ethernet-only by design - it builds an outer ethhdr, rewrites
h_source/h_dest/h_proto, and calls eth_type_trans() on decode - so
instead of trying to make the offsets work for arbitrary link types,
simply drop packets that do not carry an Ethernet header.
Checking skb->dev->type alone is not enough. We have to cater for a
corner case where mirred can redirect an skb from a non-Ethernet device
to an Ethernet one, and skb->dev then says nothing about the framing the
skb actually has: an skb redirected from ppp0 reaches the target's ingress
hook with mac_len 0 and no Ethernet header at all. So at ingress also
require mac_len to be ETH_HLEN. On egress mac_len is not maintained, so
the device type is all we have; a bogus redirect there yields a malformed
frame rather than an out-of-bounds push, and it would be malformed with or
without IFE.
That corner case is not theoretical - redirecting from ppp0 into a veth
that has an ife encode action on its ingress hook panics without this
patch:
skbuff: skb_under_panic: len:98 put:14 head:ffff88800e410000
data:ffff88800e40fff5 tail:0x57 end:0x640 dev:veth3
kernel BUG at net/core/skbuff.c:214!
Call Trace:
skb_push (net/core/skbuff.c:224 net/core/skbuff.c:2657)
tcf_ife_act (net/sched/act_ife.c:829 net/sched/act_ife.c:874)
tc_run (net/core/dev.c:4463)
netif_receive_skb (net/core/dev.c:6463 net/core/dev.c:6522)
tcf_mirred_to_dev (net/sched/act_mirred.c:248 net/sched/act_mirred.c:328)
tcf_mirred_act (net/sched/act_mirred.c:489)
tc_run (net/core/dev.c:4463)
process_backlog (net/core/dev.c:6728)
With Ethernet framing guaranteed, use ETH_HLEN instead of
hard_header_len.
Fixes: 295a6e06d2 ("net/sched: act_ife: Change to use ife module")
Reported-by: vega@nebusec.ai
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Victor Nogueira <victor@mojatatu.com>
Link: https://patch.msgid.link/20260821164031.32824-1-victor@mojatatu.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
On an of_property_read_u32() failure, rswitch_get_port_node() set port
to NULL and jumped to the out label before releasing the reference the
for_each_available_child_of_node() iterator was holding on it. Once
port was overwritten with NULL, that reference could never be
released since out: only put "ports", the parent node.
Rework the function around for_each_available_child_of_node_scoped()
instead of adding a manual of_node_put(), so the iterator's reference
is dropped automatically on every exit path. Since port is the
function's return value, take an explicit reference with of_node_get()
on the match before breaking out of the loop.
Signed-off-by: Manush Prajwal <manushprajwal555@gmail.com>
Link: https://patch.msgid.link/6a882352.ee10049a.267d65.7a31@mx.google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Wei Fang says:
====================
net: enetc: restore RX ring congestion mode after ring reconfiguration
The RX BD ring congestion mode (CM) enables the ENETC MAC to generate
PAUSE frames when ingress congestion occurs. It is configured only in
the phylink .mac_link_up() callback, which is invoked when the link
status changes.
However, enetc_reconfigure() tears down and re-creates the RX BD rings
at runtime without any link status change, for example when enabling or
disabling PTP RX hardware timestamping. enetc_setup_rxbdr() rebuilds the
RBMR register from zero, which clears the CM bit, and since the link
status does not change, .mac_link_up() is not called again to restore
it. As a result, flow control silently stops working after such a
reconfiguration.
To solve this issue, track the desired CM state in a software flag
ENETC_RXBDR_CM, which is maintained by the .mac_link_up() /
.mac_link_down() callbacks and consulted by enetc_setup_rxbdr() when the
RX BD rings are (re)configured. Both ENETC v1 and ENETC v4 are affected
and are fixed in the same way.
====================
Link: https://patch.msgid.link/20260821064140.1315611-1-wei.fang@oss.nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
ENETC v4 has the same problem as ENETC v1: the RX BD ring congestion
mode (CM) is only configured in the phylink .mac_link_up() callback, so
it is cleared when enetc_reconfigure() rebuilds the RX BD rings at
runtime (for example when enabling or disabling PTP RX hardware
timestamping) without a link status change, and it is never restored.
As a result, the MAC can no longer generate PAUSE frames on ingress
congestion and flow control stops working.
Fix it in the same way as ENETC v1. Track the desired CM state in the
software flag ENETC_RXBDR_CM. Route enetc4_set_tx_pause() through the
shared helper enetc_set_congestion_mode(), which sets or clears the flag
according to tx_pause and updates the ENETC_RBMR_CM bit under si->gen_lock.
When the RX BD rings are (re)enabled, enetc_enable_rxbdr() consults this
flag and restores the CM bit accordingly, so flow control survives ring
reconfiguration even when the link status does not change.
Fixes: f5b9a1cde0 ("net: enetc: add PTP synchronization support for ENETC v4")
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260821064140.1315611-3-wei.fang@oss.nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The RX ring congestion mode (CM) is only configured in the phylink
.mac_link_up() callback enetc_pl_mac_link_up(), which sets the
ENETC_RBMR_CM bit when tx_pause is enabled. This callback runs only when
the link status changes.
However, enetc_reconfigure() tears down and re-creates the RX BD rings at
runtime without any link status change, for example when attaching or
detaching an XDP program, or when enabling/disabling PTP RX hardware
timestamping. The rings are rebuilt from a cleared RBMR, so the CM bit is
lost. Since the link status does not change, enetc_pl_mac_link_up() is
not called again and the CM bit is never restored.
As a result, the ENETC MAC can no longer generate PAUSE frames on ingress
congestion, and flow control stops working after such a reconfiguration.
Track the desired CM state in a software flag ENETC_RXBDR_CM. Set or clear
this flag in enetc_pl_mac_link_up() according to tx_pause. When the RX BD
rings are (re)enabled, enetc_enable_rxbdr() consults this flag and restores
the ENETC_RBMR_CM bit accordingly, so flow control survives ring
reconfiguration even when the link status does not change.
RBMR is now written as a whole word from enetc_enable_rxbdr() rather than
by read-modify-write from several call sites. Serialize the remaining RBMR
read-modify-write paths, the congestion mode update and the RX VLAN offload
update, with the new si->gen_lock so they cannot race each other.
Fixes: 5093406c78 ("net: enetc: implement ring reconfiguration procedure for PTP RX timestamping")
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260821064140.1315611-2-wei.fang@oss.nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Hidayath Khan says:
====================
net/smc: fix use-after-free in smc_rx_pipe_buf_release()
smc_rx_pipe_buf_release() tests sk_state before taking the socket lock
and then dereferences conn->rmb_desc and conn->lgr. A concurrent close
runs smc_conn_free() in between, which releases those structures. On the
is_reg_err path smcr_buf_unuse() frees the descriptor outright, so this
is a use-after-free.
Patch 2/2 fixes this by taking the socket lock first and testing
conn->freed instead. smc_conn_free() sets that flag before releasing
anything, under the same lock, so the two paths exclude each other.
Patch 1/2 is a prerequisite. conn->freed shares a byte with killed and
out_of_sync as single-bit bitfields. out_of_sync is written from the
receive tasklet without the socket lock, so a concurrent store to freed
from process context can be lost in the read-modify-write. Patch 1/2
gives each flag its own byte so stores do not interfere.
====================
Link: https://patch.msgid.link/20260820074642.966856-1-hidayath@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
smc_rx_splice() hands RMB pages to a pipe and takes a socket reference
per entry so the smc_sock stays alive until the reader finishes. The
connection does not: a concurrent close runs smc_conn_free(), which
releases the receive buffer back to the link group pool.
smc_rx_pipe_buf_release() tests sk_state before taking the socket lock.
The state can change between the test and the lock, and
smc_rx_update_cons() then dereferences conn->rmb_desc and walks
conn->lgr, which smc_conn_free() has already released. On the
is_reg_err path smcr_buf_unuse() frees the descriptor outright, so
this is a use-after-free.
Take the socket lock first and test conn->freed instead.
smc_conn_free() sets that flag before releasing anything, and every
caller holds the socket lock. The two paths exclude each other: either
the pipe release runs first with everything valid, or it sees the flag
and skips the update.
Fixes: 9014db202c ("smc: add support for splice()")
Cc: stable@vger.kernel.org
Reviewed-by: Mahanta Jambigi <mjambigi@linux.ibm.com>
Signed-off-by: Hidayath Khan <hidayath@linux.ibm.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260820074642.966856-3-hidayath@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The three connection state flags are single-bit bitfields, so they occupy
one byte of struct smc_connection and every store to one is a
read-modify-write of the other two:
u8 killed : 1;
u8 freed : 1;
u8 out_of_sync : 1;
They are not written under a common lock. smc_cdc_msg_validate() sets
out_of_sync from the receive tasklet, while smc_conn_kill() sets killed
from process context under lock_sock(), and the receive path does not defer
to the backlog when the socket is owned -- smc_cdc_msg_recv() takes only
bh_lock_sock().
Give each flag its own byte so a store no longer touches its neighbours.
All readers test them as booleans and are unchanged. struct smc_connection
grows by two bytes.
Fixes: b286a0651e ("net/smc: handle incoming CDC validation message")
Cc: stable@vger.kernel.org
Reviewed-by: Mahanta Jambigi <mjambigi@linux.ibm.com>
Signed-off-by: Hidayath Khan <hidayath@linux.ibm.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260820074642.966856-2-hidayath@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
smc_switch_conns() takes a reference on the SMC socket before dropping
lgr->conns_lock, so the connection stays alive while the CDC slot is
fetched:
sock_hold(&smc->sk);
read_unlock_bh(&lgr->conns_lock);
/* pre-fetch buffer outside of send_lock, might sleep */
rc = smc_cdc_get_free_slot(conn, to_lnk, &wr_buf, NULL, &pend);
if (rc)
goto err_out;
The err_out label only drops the wr_tx link reference, so this early exit
returns without the matching sock_put(). The second error exit is not
affected, because sock_put() has already run by then.
A leaked sk_refcnt means the smc_sock is never destroyed. Its send and
receive buffers stay allocated, and for a user socket the reference held
on the network namespace is never released, so the netns can no longer be
torn down.
smc_cdc_get_free_slot() fails when the target link goes down or when the
connection has been killed while the switch is in progress. Both are
reachable during the link failover this function implements, so the leak
is triggered by the same hardware events that make smc_switch_conns() run
in the first place.
Restructure so there is a single sock_put() covering both outcomes,
instead of adding a second one to the error path.
Fixes: 95f7f3e7dc ("net/smc: improved fix wait on already cleared link")
Cc: stable@vger.kernel.org
Reviewed-by: Mahanta Jambigi <mjambigi@linux.ibm.com>
Reviewed-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Hidayath Khan <hidayath@linux.ibm.com>
Link: https://patch.msgid.link/20260820144729.1019399-1-hidayath@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In stmmac_mtl_setup(), q_node is shared across the RX and TX queue
parsing loops. When the RX queue loop breaks early because the number
of parsed queues reaches plat->rx_queues_to_use, q_node retains an
acquired reference count. If the error check passes
(queue == plat->rx_queues_to_use), execution proceeds directly to the
TX queue loop, where of_get_next_child() immediately overwrites q_node
with the first TX child, permanently leaking the retained RX child
device node reference.
Switch both loops to for_each_child_of_node_scoped() so child node
references are automatically dropped upon loop exit or early break,
and remove the now-unnecessary function-scoped q_node variable and
its manual of_node_put() at the exit label.
Signed-off-by: Md Rabbani <rabbanyhmm@gmail.com>
Link: https://patch.msgid.link/20260821055718.57-1-rabbanyhmm@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The tunnel create, tunnel modify, session create, and session modify
netlink handlers send multicast notifications through helpers that can fail
while allocating or encoding a message, or while multicasting it.
For tunnel and session create/modify, a notification is sent after the live
operation has completed. Returning a best-effort notification error as the
command result can therefore report failure for an operation that already
committed and can cause callers to retry and accumulate live objects.
Keep sending notifications for listener visibility, but do not propagate
their best-effort status as the command result. This also keeps the tunnel
modify command consistent with the other notification-only paths.
Fixes: 33f72e6f0c ("l2tp : multicast notification to the registered listeners")
Cc: stable@vger.kernel.org
Reported-by: Vega <vega@nebusec.ai>
Signed-off-by: Zihan Xi <zihanx@nebusec.ai>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/54f48e812ca0424c47ffdb9a8182180921f7e6b2.1787247008.git.zihanx@nebusec.ai
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
rmnet_map_deaggregate() allocates each sub-frame with alloc_skb() and
leaves skb->dev NULL. __rmnet_map_ingress_handler() assigns
skb->dev = ep->egress_dev only on the data path, but a MAP command frame
is dispatched to rmnet_map_command() before that, so rmnet_map_send_ack()
runs netif_tx_lock(skb->dev) on a NULL device. An unprivileged user
reaches this by unsharing a user+net namespace, creating an rmnet link
over a tap device with INGRESS_DEAGGREGATION and INGRESS_MAP_COMMANDS,
and writing an aggregated frame carrying a flow-control command to the
tap fd.
Restore the assignment dropped by 378e25357a, so every skb leaving
rmnet_map_deaggregate() has a valid device.
BUG: KASAN: null-ptr-deref in _raw_spin_lock (kernel/locking/spinlock.c:158)
Write of size 4 at addr 00000000000004b4 by task exploit/144
Call Trace:
_raw_spin_lock (kernel/locking/spinlock.c:158)
netif_tx_lock (net/sched/sch_generic.c:497)
rmnet_map_command (drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c:67)
rmnet_rx_handler (drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:125)
__netif_receive_skb_core.constprop.0 (net/core/dev.c:6103)
...
__netif_receive_skb_one_core (net/core/dev.c:6214)
netif_receive_skb (net/core/dev.c:6474)
tun_get_user (drivers/net/tun.c:1966)
tun_chr_write_iter (drivers/net/tun.c:2012)
vfs_write (fs/read_write.c:687)
ksys_write (fs/read_write.c:739)
do_syscall_64 (arch/x86/entry/syscall_64.c:94)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
Kernel panic - not syncing: Fatal exception in interrupt
Fixes: 378e25357a ("net: qualcomm: rmnet: Remove unnecessary device assignment")
Reported-by: co+4638111fe2a12980@bugs.sh
Closes: https://lore.kernel.org/netdev/ijg79FFMfIvKJbivdJEKvTO90Q9dTvyBkJck@bugs.sh/T/#u
Signed-off-by: Xiang Mei <xmei5@asu.edu>
Reviewed-by: Subash Abhinov Kasiviswanathan <subash.a.kasiviswanathan@oss.qualcomm.com>
Link: https://patch.msgid.link/20260820195240.1631458-1-xmei5@asu.edu
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Qingshuang Fu says:
====================
selftests/net: fixes for fin_ack_lat
This series fixes two bugs in the fin_ack_lat self-test.
Patch 1 fixes the swapped kill() arguments in sig_handler(), so the
server actually forwards SIGTERM to the client. It also makes the
wrapper script's cleanup tolerant of ESRCH, since the client may now
exit before the kill command reaches its PID.
Patch 2 adds a missing fork() error check: on failure the code falls
into server()'s infinite accept loop, producing empty output that the
wrapper script treats as a passing test.
====================
Link: https://patch.msgid.link/20260821030922.1123754-1-fffsqian@163.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
main() never checks fork() for failure. When fork() returns -1
(EAGAIN/ENOMEM/RLIMIT_NPROC), the !child_pid test is false and the
process falls into server()'s infinite accept() loop with no client ever
connecting, producing empty output. The wrapper script treats an
empty log as a passing test, producing a false positive.
Check fork() for failure with error(), as is done for every other
syscall in this file.
Signed-off-by: Qingshuang Fu <fuqingshuang@kylinos.cn>
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260821031442.1124777-2-fffsqian@163.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
sig_handler() passes its arguments to kill() in the wrong order: it sends
signal number child_pid to PID SIGTERM (15) instead of sending SIGTERM
to the client process. The call therefore always fails and the signal
is never forwarded: when only the server process receives SIGTERM, the
client keeps running its infinite connect loop as an orphan process.
Swap the arguments so that the server forwards SIGTERM to the client.
Guard the call with child_pid > 0: the client inherits the handler and
sees child_pid == 0, and a plain argument swap would make it call
kill(0, SIGTERM), signaling the whole process group instead of exiting
quietly.
Now that the server actually terminates the client before the wrapper
script's cleanup runs, kill() may fail with ESRCH for the already-exited
client. The script uses set -e, so make the kill tolerant to avoid
aborting the EXIT trap and leaking temporary files.
Signed-off-by: Qingshuang Fu <fuqingshuang@kylinos.cn>
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260821031442.1124777-1-fffsqian@163.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Packet processing uses CT limit state under RCU, while netns teardown
frees that state under ovs_mutex. The CT limit pointer was neither removed
from readers nor protected by a grace period, allowing packet processing to
dereference the freed state.
An unprivileged user can trigger this bug from a user and network
namespace, causing a slab-use-after-free in ovs_ct_execute() when the
netns is torn down.
Publish the CT limit pointer through RCU, remove it before teardown, and
wait for readers before freeing its contents. Keep ovs_mutex around
individual CT limit updates, and use the RCU read-side lock while GET
traverses the RCU-protected limit lists.
Netns teardown detaches the RCU-protected CT limit state in the pernet
.pre_exit callback while holding ovs_mutex. The pernet core guarantees an
RCU grace period between the .pre_exit and .exit callbacks, so the .exit
callback completes the teardown without adding any extra synchronization.
The netlink command handlers do not need NULL checks because the userspace
netlink socket holds an active reference to its network namespace while a
request is processed. The per-netns exit path therefore cannot run
concurrently with SET, DEL, or GET for that socket's namespace.
Fixes: 11efd5cb04 ("openvswitch: Support conntrack zone limit")
Cc: stable@vger.kernel.org
Reported-by: Vega <vega@nebusec.ai>
Link: https://lore.kernel.org/all/cover.1784711445.git.xuyuqiabc@gmail.com
Co-developed-by: Nan Li <tonanli66@gmail.com>
Signed-off-by: Nan Li <tonanli66@gmail.com>
Signed-off-by: Yuqi Xu <xuyuqiabc@gmail.com>
Reviewed-by: Ren Wei <enjou1224z@gmail.com>
Reviewed-by: Ilya Maximets <i.maximets@ovn.org>
Link: https://patch.msgid.link/288fbd5459d92b9dd0dcc6faf625f04819161ff3.1787280296.git.xuyuqiabc@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
rvu_register_interrupts() walks every MSI-X vector and uses strstr()
to match "Mbox" or "FLR" in irq_name before pinning those interrupts
to CPU 0. irq_name is a per-vector NAME_SIZE buffer, but not every
slot is populated before this loop runs. strstr() keeps scanning until
it finds a NUL terminator, so an uninitialized slot can trigger a KASAN
slab-out-of-bounds read at boot when debug options are enabled.
Use strnstr() with NAME_SIZE to bound the search within each vector's
name buffer.
Fixes: 4e527f1e5c ("octeontx2-af: npc: cn20k: Add new mailboxes for CN20K silicon")
Signed-off-by: Anshumali Gaur <agaur@marvell.com>
Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com>
Link: https://patch.msgid.link/20260820055451.2642358-1-rkannoth@marvell.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
rvu_dbg_nix_tm_tree_display() dereferences pfvf->sq_ctx without
checking whether the SQ context has been allocated. Reading
/sys/kernel/debug/octeontx2/nix/tm_tree for a NIX LF whose transmit
queues are not set up triggers a kernel oops.
Guard the read path the same way rvu_dbg_nix_tm_tree_write() already
does and return -EINVAL with a seq_file message when sq_ctx is NULL.
Fixes: b907194a5d ("octeontx2-af: Add debugfs support to dump NIX TM topology")
Signed-off-by: Anshumali Gaur <agaur@marvell.com>
Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com>
Link: https://patch.msgid.link/20260820050333.2606095-1-rkannoth@marvell.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
gtp_newlink()'s error path frees tid_hash and addr_hash without
waiting for an RCU grace period after clearing sk_user_data. A
concurrent gtp_encap_recv() in softirq may still hold the gtp_dev
pointer obtained via rcu_dereference_sk_user_data() and access the
freed memory.
BUG: KASAN: slab-use-after-free in gtp0_pdp_find+0x1f6/0x200 (gtp.c:152)
Call Trace:
<IRQ>
gtp0_pdp_find+0x1f6/0x200
gtp_encap_recv+0x527/0x24b0
udp_queue_rcv_one_skb+0x75f/0xc10
Add synchronize_net() before the kfree calls in out_hashtable, which
covers all error paths from both gtp_encap_enable() and
gtp_create_sockets().
Fixes: 459aa660eb ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)")
Reported-by: AutonomousCodeSecurity@microsoft.com
Reported-by: Xiang Mei (Microsoft) <xmei5@asu.edu>
Reported-by: Cen Zhang (Microsoft) <blbllhy@gmail.com>
Signed-off-by: Cen Zhang (Microsoft) <blbllhy@gmail.com>
Link: https://patch.msgid.link/20260820020735.59474-1-blbllhy@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Stanislav Fomichev says:
====================
xsk: pre-existing AF_XDP TX metadata fixes from Sashiko
A few fixes to address pre-existing issues from Sashiko review.
Notes on the feedback from net-next v1 posting [0]:
- It correctly complains about ABI breakage for 32 bit systems, added
an explanation why I think we unlikely to have any 32 bit users with
launch time
- mlx5 batching (pre existing) - I think my point in the comment still
stays (that we do not make it worse)
0: from https://netdev-ai.bots.linux.dev/sashiko/#/message/20260810184753.135756-1-sdf%40fomichev.me
====================
Link: https://patch.msgid.link/20260819160535.1472459-1-sdf@fomichev.me
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The zero-copy path reads TX metadata whenever the UMEM has metadata space,
even if the descriptor does not set XDP_TX_METADATA. Pass descriptor
options through the metadata helpers and ignore metadata unless the option
is set.
This does not fix the existing per-WQE metadata handling for mlx5 MPWQEs.
Only the descriptor that starts a session passes through
xsk_tx_metadata_request() and configures offload state shared by the batch.
Metadata on descriptors joining an open session is therefore not validated
and does not configure its requested offloads. In addition, a non-NULL
metadata pointer from such a descriptor is treated as a timestamp
completion request even when XDP_TXMD_FLAGS_TIMESTAMP is not set, so its
metadata union can be overwritten with an unrequested timestamp. Fixing
mixed metadata states within one MPWQE requires a separate change.
Fixes: 48eb03dd26 ("xsk: Add TX timestamp and TX checksum offload support")
Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com>
Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Link: https://patch.msgid.link/20260819160535.1472459-3-sdf@fomichev.me
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add explicit padding before launch_time so xsk_tx_metadata has the same
layout on 32-bit and 64-bit systems.
On several architectures (csky, i386, nios2, m65k, openrisc, sh), the old
native 32-bit layout put launch_time at offset 12 and had a natural size of
20 bytes. Using sizeof(struct xsk_tx_metadata) as tx_metadata_len was already
rejected because the length must be a multiple of eight, so the
straightforward use of the interface was broken on those ABIs. Userspace
could still register a padded length of 24 bytes, though; mixing the old and
new layouts then silently reads launch_time from the wrong offset and
misprograms packet launch times. This intentionally replaces that
incompatible layout because the affected architectures are unlikely to
have any notable users. (x86_64 and arm64 have the most users and are _not_
affected)
Fixes: ca4419f15a ("xsk: Add launch time hardware offload support to XDP Tx metadata")
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20260819160535.1472459-2-sdf@fomichev.me
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
CAKE's autorate-ingress path intends to limit shaper reconfiguration to
once per 250 ms, but last_reconfig_time is only checked and never updated.
Since the field stays zero, every qualifying capacity-estimate window can
call cake_reconfigure(), causing avoidable rate churn and scheduler work
under bursty traffic.
Store the current timestamp when autorate actually reconfigures the qdisc
so the guard enforces the intended interval.
Fixes: 7298de9cd7 ("sch_cake: Add ingress mode")
Signed-off-by: Giuseppe Piscitelli <ooonea@gmail.com>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
Link: https://patch.msgid.link/20260820154503.892214-1-ooonea@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The driver memsets the RX buffer page head to zero before
submitting it to hardware, then calls dma_sync_single_for_device()
with DMA_TO_DEVICE. This sync direction does not match the pool
dma_dir which is DMA_FROM_DEVICE, violating the DMA API contract
that the sync direction must match the mapping direction.
On swiotlb platforms the mismatch can cause incorrect bounce-buffer
behaviour, and CONFIG_DMA_API_DEBUG emits a warning.
Switch the page_pool dma_dir to DMA_BIDIRECTIONAL so that the
CPU-to-device memset sync becomes legal.
Fixes: c305959175 ("net: hibmcge: add support for pagepool on rx")
Signed-off-by: Jian Shen <shenjian15@huawei.com>
Signed-off-by: Jijie Shao <shaojijie@huawei.com>
Link: https://patch.msgid.link/20260820124346.4097115-1-shaojijie@huawei.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Net drivers request GFP flags according to both the current context and
the device constraints, but the XArray entry itself is by no mean used
by the device. Passing though device constraints to XArray allocation is
a bug and will be warned and fixed up by slab, e.g.:
Unexpected gfp: 0x4 (GFP_DMA32). Fixing up to gfp: 0x82820 (GFP_ATOMIC|__GFP_NOWARN|__GFP_NOMEMALLOC). Fix your code!
CPU: 2 UID: 0 PID: 1071629 Comm: kworker/u80:1 Not tainted 7.2.0-rc7+ #1 PREEMPT(lazy)
Hardware name: LENOVO 21Q4/LNVNB161216, BIOS PXCN27WW 10/20/2025
Workqueue: mt76 mt792x_pm_wake_work [mt792x_lib]
Call Trace:
<TASK>
dump_stack_lvl+0x6e/0x90
kmalloc_fix_flags+0x4d/0x6a
refill_objects+0x10a/0x330
__pcs_replace_empty_main+0x292/0x5c0
kmem_cache_alloc_lru_noprof+0x4c2/0x680
? __xas_nomem+0x3a/0x120
__xas_nomem+0x3a/0x120
__xa_alloc+0xd4/0x190
page_pool_dma_map+0xef/0x400
__page_pool_alloc_netmems_slow+0xed/0x480
? lock_release+0x280/0x490
page_pool_alloc_frag_netmem+0xe0/0x3a0
page_pool_alloc_frag+0xe/0x20
mt76_dma_rx_fill_buf+0x1f6/0x580 [mt76]
mt76_dma_rx_reset+0x1cf/0x230 [mt76]
mt792x_wpdma_reset+0x183/0x1b0 [mt792x_lib]
mt792x_wpdma_reinit_cond+0x5e/0xa0 [mt792x_lib]
mt792xe_mcu_drv_pmctrl+0x28/0x60 [mt792x_lib]
mt792x_mcu_drv_pmctrl+0x3e/0x90 [mt792x_lib]
mt792x_pm_wake_work+0x2d/0x1d0 [mt792x_lib]
? process_one_work+0x20e/0x600
process_one_work+0x230/0x600
? process_one_work+0x256/0x600
worker_thread+0x1ec/0x3c0
? rescuer_thread+0x610/0x610
kthread+0xf2/0x130
? kthread_affine_node+0x140/0x140
ret_from_fork+0x2a5/0x380
? kthread_affine_node+0x140/0x140
ret_from_fork_asm+0x11/0x20
</TASK>
Currently mt76 and stmmac may allocate page pool pages with GFP_DMA32.
Fix it by removing zone/policy GFP flags when allocating XArray entries.
This is inspired by commit 96d5780880 ("iommu/dma: Use the gfp
parameter in __iommu_dma_alloc_noncontiguous()").
Fixes: ee62ce7a1d ("page_pool: Track DMA-mapped pages and unmap them when destroying the pool")
Signed-off-by: Rong Zhang <i@rong.moe>
Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com>
Link: https://patch.msgid.link/20260821-page-pool-xa-drop-dma32-v1-1-6eab295c3478@rong.moe
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Yehyeong Lee says:
====================
net/smc: fix out-of-bounds and use-after-free in SMC-Rv2 LLC processing
Patch 1 fixes a use-after-free of the LLC queue entry in
smc_llc_srv_add_link(), patch 2 bounds the peer's rkey counts, and patch 3
carries the tail of an oversized v2 message in the queue entry so that both
readers are bounded by what arrived. All three are tagged for stable: a
tree that takes 1 and 2 without 3 still deletes rkeys read from whatever an
earlier message left in the shared receive buffer.
====================
Link: https://patch.msgid.link/20260819023306.644849-1-yhlee@isslab.korea.ac.kr
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
smc_llc_rmt_delete_rkey() and smc_llc_save_add_link_rkeys() read the part
of a v2 message that does not fit into the 44-byte union smc_llc_msg, and
both bound themselves by the size of the buffer it landed in, not by what
arrived. On a link with a shared v2 receive buffer a 44-byte
DELETE_RKEY_V2 declaring 255 rkeys reaches rkey[9..254] in whatever an
earlier message left in lgr->wr_rx_buf_v2, and passes each of them to
smc_rtoken_delete(). One of those 255 matched a registered rtoken and
deleted it. An ADD_LINK on such a link installs up to 255 rtokens from
the same bytes.
Copy the tail into the queue entry, so its length is the length of the
message that arrived, and declare the rkeys that fit inline as a member of
the union instead of reaching them through a cast. The same
DELETE_RKEY_V2 now processes the 9 rkeys it carries. The copy is limited
to the longest tail the two functions can read, so the peer does not pick
the size of the entry.
The bound the previous patch placed on links without a shared v2 receive
buffer is no longer needed.
Fixes: 27ef6a9981 ("net/smc: support SMC-R V2 for rdma devices with max_recv_sge equals to 1")
Cc: stable@vger.kernel.org
Suggested-by: D. Wythe <alibuda@linux.alibaba.com>
Reviewed-by: Sidraya Jayagond <sidraya@linux.ibm.com>
Signed-off-by: Yehyeong Lee <yhlee@isslab.korea.ac.kr>
Link: https://patch.msgid.link/20260819023306.644849-4-yhlee@isslab.korea.ac.kr
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
smc_llc_srv_add_link() keeps add_llc pointing into the queue entry:
add_llc = &qentry->msg.add_link; smc_llc.c:1482
...
smc_llc_save_add_link_info(link_new, add_llc); smc_llc.c:1494
smc_llc_flow_qentry_del(&lgr->llc_flow_lcl); smc_llc.c:1495
...
u8 *llc_msg = smc_link_shared_v2_rxbuf(link) ?
(u8 *)lgr->wr_rx_buf_v2 : (u8 *)add_llc; smc_llc.c:1504
smc_llc_save_add_link_rkeys(link, link_new, llc_msg); smc_llc.c:1506
smc_llc_flow_qentry_del() kfree()s the entry, so on a link without a shared
v2 receive buffer the pointer handed to smc_llc_save_add_link_rkeys() is
already freed. Before the Fixes: commit that branch always used
lgr->wr_rx_buf_v2 and add_llc was not used after the free.
Reproduced on an unpatched tree over rxe, with KASAN, kasan_multi_shot
and a link forced to max_recv_sge == 1: the entry is freed and read by
the same call, and the freeing frame is smc_llc_srv_add_link() itself.
[ 2.523161] BUG: KASAN: slab-use-after-free in smc_llc_save_add_link_rkeys+0x333/0x350
[ 2.523499] Read of size 2 at addr ffff8880052194de by task kworker/0:1/11
[ 2.523789]
[ 2.523862] CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 7.2.0-rc5-p0-g2c9dd296545d #35 PREEMPT(lazy)
[ 2.523865] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 2.523866] Workqueue: smc_hs_wq smc_listen_work
[ 2.523869] Call Trace:
[ 2.523870] <TASK>
[ 2.523871] dump_stack_lvl+0x53/0x70
[ 2.523872] print_report+0xd0/0x630
[ 2.523874] ? __pfx__raw_spin_lock_irqsave+0x10/0x10
[ 2.523876] ? smc_llc_save_add_link_rkeys+0x333/0x350
[ 2.523878] kasan_report+0xce/0x100
[ 2.523879] ? smc_llc_save_add_link_rkeys+0x333/0x350
[ 2.523881] smc_llc_save_add_link_rkeys+0x333/0x350
[ 2.523883] ? smcr_buf_reg_lgr+0x2a4/0x660
[ 2.523885] smc_llc_srv_add_link+0xaa2/0x1e50
[ 2.523888] ? _printk+0xba/0xf0
[ 2.523897] ? __pfx_smc_llc_srv_add_link+0x10/0x10
[ 2.523899] ? down_write+0xb0/0x130
[ 2.523903] ? __pfx_down_write+0x10/0x10
[ 2.523905] smc_listen_work+0x489e/0x4d00
[ 2.523907] ? kmem_cache_free+0x1c6/0x3a0
[ 2.523911] ? __pfx_smc_listen_work+0x10/0x10
[ 2.523913] ? release_sock+0x148/0x1d0
[ 2.523915] ? smc_tcp_listen_work+0xb4f/0xfc0
[ 2.523917] ? _raw_spin_lock_irq+0x80/0xe0
[ 2.523918] ? __pfx__raw_spin_lock_irq+0x10/0x10
[ 2.523920] process_one_work+0x633/0x1030
[ 2.523922] ? assign_work+0x11d/0x370
[ 2.523924] worker_thread+0x45b/0xd10
[ 2.523926] ? __pfx_worker_thread+0x10/0x10
[ 2.523928] ? __pfx_worker_thread+0x10/0x10
[ 2.523929] kthread+0x2c6/0x3b0
[ 2.523931] ? recalc_sigpending+0x15c/0x1e0
[ 2.523934] ? __pfx_kthread+0x10/0x10
[ 2.523935] ret_from_fork+0x36e/0x5a0
[ 2.523937] ? __pfx_ret_from_fork+0x10/0x10
[ 2.523938] ? __switch_to+0x572/0xdd0
[ 2.523943] ? __pfx_kthread+0x10/0x10
[ 2.523944] ret_from_fork_asm+0x1a/0x30
[ 2.523947] </TASK>
[ 2.523948]
[ 2.531253] Allocated by task 48:
[ 2.531399] kasan_save_stack+0x33/0x60
[ 2.531570] kasan_save_track+0x14/0x30
[ 2.531737] __kasan_kmalloc+0x8f/0xa0
[ 2.531905] __kmalloc_cache_noprof+0x158/0x370
[ 2.532100] smc_llc_enqueue+0x72/0x560
[ 2.532268] smc_wr_rx_tasklet_fn+0x474/0xa80
[ 2.532491] tasklet_action_common+0x20f/0x8a0
[ 2.532714] handle_softirqs+0x18e/0x590
[ 2.532886] do_softirq+0x3b/0x60
[ 2.533036] __local_bh_enable_ip+0x61/0x70
[ 2.533221] __alloc_skb+0x732/0x890
[ 2.533384] rxe_init_packet+0x16b/0x4f0
[ 2.533567] prepare_ack_packet+0xb8/0x830
[ 2.533760] rxe_receiver+0x495/0x96e0
[ 2.533933] do_work+0x144/0x470
[ 2.534078] process_one_work+0x633/0x1030
[ 2.534257] worker_thread+0x45b/0xd10
[ 2.534424] kthread+0x2c6/0x3b0
[ 2.534569] ret_from_fork+0x36e/0x5a0
[ 2.534737] ret_from_fork_asm+0x1a/0x30
[ 2.534907]
[ 2.534980] Freed by task 11:
[ 2.535112] kasan_save_stack+0x33/0x60
[ 2.535279] kasan_save_track+0x14/0x30
[ 2.535444] kasan_save_free_info+0x3b/0x60
[ 2.535625] __kasan_slab_free+0x43/0x70
[ 2.535798] kfree+0x121/0x380
[ 2.535935] smc_llc_srv_add_link+0x9a8/0x1e50
[ 2.536128] smc_listen_work+0x489e/0x4d00
[ 2.536305] process_one_work+0x633/0x1030
[ 2.536482] worker_thread+0x45b/0xd10
[ 2.536652] kthread+0x2c6/0x3b0
[ 2.536794] ret_from_fork+0x36e/0x5a0
[ 2.536958] ret_from_fork_asm+0x1a/0x30
[ 2.537133]
[ 2.537205] The buggy address belongs to the object at ffff888005219480
[ 2.537205] which belongs to the cache kmalloc-96 of size 96
[ 2.537719] The buggy address is located 94 bytes inside of
[ 2.537719] freed 96-byte region [ffff888005219480, ffff8880052194e0)
[ 2.538216]
[ 2.538289] The buggy address belongs to the physical page:
[ 2.538524] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5219
[ 2.538857] flags: 0x100000000000000(node=0|zone=1)
[ 2.539066] page_type: f5(slab)
[ 2.539210] raw: 0100000000000000 ffff888001041280 dead000000000122 0000000000000000
[ 2.539534] raw: 0000000000000000 0000000000200020 00000000f5000000 0000000000000000
[ 2.539863] page dumped because: kasan: bad access detected
[ 2.540098]
[ 2.540170] Memory state around the buggy address:
[ 2.540379] ffff888005219380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 2.540684] ffff888005219400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 2.540988] >ffff888005219480: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
[ 2.541291] ^
[ 2.541548] ffff888005219500: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc
[ 2.541857] ffff888005219580: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc
The offset is past the 72-byte queue entry because the out-of-bounds read
fixed by the next patch is on the same line; what this patch removes is the
free at smc_llc_srv_add_link+0x9a8 happening before the read at +0xaa2.
Detach the entry instead of freeing it there, and free it at the single
exit label. The reject path has to detach as well, otherwise it would be
freed twice.
This changes only the lifetime of the entry. The same read still runs past
its end until the next two patches bound it, so a backport wants all three.
Fixes: 27ef6a9981 ("net/smc: support SMC-R V2 for rdma devices with max_recv_sge equals to 1")
Cc: stable@vger.kernel.org
Reviewed-by: Sidraya Jayagond <sidraya@linux.ibm.com>
Signed-off-by: Yehyeong Lee <yhlee@isslab.korea.ac.kr>
Reviewed-by: Breno Leitao <leitao@debian.org>
Link: https://patch.msgid.link/20260819023306.644849-2-yhlee@isslab.korea.ac.kr
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In wx_ptp_set_timestamp_mode(), the driver copies the global `wx->flags`
bitmap to a local variable, modifies the PTP-related bits, and then writes
the entire bitmap back using memcpy().
This Read-Copy-Update pattern is unsafe and introduces a critical race
condition. Other asynchronous contexts (such as Tx timeout routines or
GPIO IRQ handlers) update individual bits in `wx->flags` concurrently
using atomic bitops like set_bit() or clear_bit(). The memcpy() write-back
can silently overwrite and drop these concurrent changes, potentially
causing the driver to miss critical module reset or PCIe recovery requests.
Fix this by removing the local bitmap copy. Instead, evaluate the intended
PTP flag states locally and apply them directly to `wx->flags` using
atomic set_bit() and clear_bit() operations only after the hardware is
successfully configured.
Fixes: 06e75161b9 ("net: wangxun: Add support for PTP clock")
Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com>
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Link: https://patch.msgid.link/6C7EC12D69217315+20260818074721.45536-1-jiawenwu@trustnetic.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Under memory pressure, the qede driver encounters NULL pointer
dereferences when processing TPA continuation fragments.
Commit 8a8633978b ("qede: Add build_skb() support.") accidentally
dropped the assignment of tpa_info->buffer.data in qede_tpa_start().
When memory pressure causes an SKB allocation failure in qede_tpa_start(),
the driver sets tpa_start_fail = true and attempts to recycle the physical
page later in qede_tpa_end() via qede_reuse_page(). However, because
buffer.data was left uninitialized (NULL), qede_reuse_page() pushes a
"ghost" BD (valid DMA mapping but NULL data pointer) back into the
active Rx ring.
The next time the hardware uses this ring slot, it passes a NULL page
to qede_fill_frag_skb(), causing a kernel panic.
Example crash from production system:
BUG: unable to handle kernel NULL pointer dereference at 0x8
RIP: qede_fill_frag_skb+0x96/0x430 [qede]
Call Trace:
qede_rx_int+0xb06/0x1de0
qede_poll+0x2f4/0x6c0
__napi_poll+0x2d/0x130
Fix the root cause by restoring the tpa_info->buffer.data assignment
in qede_tpa_start(), ensuring valid pages are correctly tracked and
recycled. Additionally, update the stale comment for
struct qede_agg_info::buffer to reflect its current usage.
Fixes: 8a8633978b ("qede: Add build_skb() support.")
Cc: stable@vger.kernel.org
Signed-off-by: Vaibhav Nagare <vnagare@redhat.com>
Link: https://patch.msgid.link/20260818073309.2266072-1-vnagare@redhat.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In txgbe_misc_irq_thread_fn(), the driver unmasks the miscellaneous
interrupt at the end of the handler using TXGBE_INTR_MISC(wx) (which
resolves to BIT(wx->num_q_vectors)). While this is correct for MSI-X
mode, it is incorrect for legacy INTx or single MSI modes.
Due to hardware behavior, the WX_PX_MISC_IVAR register is completely
ignored by the hardware when MSI-X is disabled. In non-MSI-X mode, the
hardware forcibly merges all interrupt causes (both Queue and MISC) into
a single bit: BIT(0) of the interrupt register.
Unconditionally unmasking TXGBE_INTR_MISC(wx) (e.g., BIT(1)) in non-MSI-X
mode means the actual MISC interrupt bit (BIT(0)) is not unmasked
promptly at the end of the MISC thread. Instead, it remains masked until
NAPI completes its polling and unmasks the shared BIT(0). This delays the
assertion of subsequent MISC interrupts, preventing timely handling of
events like link state changes.
Fix this by explicitly checking `pdev->msix_enabled` and falling back
to BIT(0) as the interrupt mask for the MISC cause when MSI-X is disabled.
Additionally, unconditionally unmasking the interrupt at the end of the
thread introduces a race condition during device teardown. Guarding the
wx_intr_enable() call with a check for the WX_STATE_DOWN bit, to prevent
re-arming the interrupt during device shutdown.
Fixes: e37546ad1f ("net: wangxun: revert the adjustment of the IRQ vector sequence")
Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/56A53978B83EEDE9+20260818023026.6631-1-jiawenwu@trustnetic.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
sparx5_set_rx_mode() runs with netif_addr_lock_bh held and iterates
dev->mc via __dev_mc_sync(), which per address calls sparx5_mc_sync() /
sparx5_mc_unsync() -> sparx5_mact_learn() / sparx5_mact_forget(). These
take sparx5->lock, a mutex, and then poll the MAC access command
register with readx_poll_timeout(). A mutex may block, which is not
allowed from atomic context.
Convert the driver to the new .ndo_set_rx_mode_async callback introduced
in commit 3554b4345d ("net: introduce ndo_set_rx_mode_async and
netdev_rx_mode_work"). The async callback is invoked from process
context, so the mutex and sleeping completion poll can remain.
Observed with CONFIG_PROVE_LOCKING, CONFIG_DEBUG_SPINLOCK,
CONFIG_DEBUG_MUTEXES and CONFIG_DEBUG_ATOMIC_SLEEP enabled:
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:591
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 217, name: ip
preempt_count: 201, expected: 0
Call trace:
__might_resched+0x144/0x248
__might_sleep+0x48/0x7c
__mutex_lock+0x74/0x850
mutex_lock_nested+0x24/0x30
sparx5_mact_learn+0x78/0x100
sparx5_mc_sync+0x40/0x54
__hw_addr_sync_dev+0xc4/0x170
sparx5_set_rx_mode+0x4c/0x58
__dev_set_rx_mode+0x64/0xa4
__dev_open+0x1ec/0x26c
Fixes: d6fce51419 ("net: sparx5: add switching support")
Signed-off-by: Daniel Machon <daniel.machon@microchip.com>
Link: https://patch.msgid.link/20260817-misc-fixes-sparx5-lan969x-v3-2-c7c7fef723a8@microchip.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
sparx5_vcap_init() runs before sparx5_register_netdevs() in probe, and
its debugfs setup calls vcap_port_debugfs() for every port using
netdev_name(ndev) as the debugfs file name. At that point the netdevs
have only been allocated, not registered, so dev->name still holds the
"eth%d" template and netdev_name() returns "(unnamed net_device)".
Every port tries to create the same file under vcaps/, producing a
flood of warnings at boot:
debugfs: '(unnamed net_device)' already exists in 'vcaps'
debugfs: '(unnamed net_device)' already exists in 'vcaps'
...
Add vcap_port_debugfs_portno(), a variant of vcap_port_debugfs() that
takes the port's stable hardware port number and uses "p%u" as the
debugfs file name instead of netdev_name(ndev). This makes the file
name independent of registration order; the file still stores and
later dereferences the netdev itself, same as before. sparx5 already
reports the same "p%d" string via ndo_get_phys_port_name(), so the
debugfs name now matches that.
Only sparx5 (and lan969x, which shares this code) is switched to the
new function. lan966x keeps calling vcap_port_debugfs() unchanged, so
this fix does not rename any of its existing debugfs files.
Fixes: b8909aad5b ("net: sparx5: move netdev and notifier block registration to probe")
Signed-off-by: Daniel Machon <daniel.machon@microchip.com>
Link: https://patch.msgid.link/20260817-misc-fixes-sparx5-lan969x-v3-1-c7c7fef723a8@microchip.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
PDP contexts can be deleted through GTP_CMD_DELPDP or while the GTP
network device is being unregistered. The latter is serialized by RTNL,
but the generic-netlink delete path only holds RCU.
Running both paths concurrently can therefore make both paths delete the
same PDP context. The issue was found through static analysis and
reproduced on a KASAN-enabled kernel by a simple two-thread program
racing GTP_CMD_DELPDP against RTM_DELLINK:
Oops: general protection fault, probably for non-canonical address
KASAN: maybe wild-memory-access in range
[0xdead000000000120-0xdead000000000127]
RIP: gtp_genl_del_pdp+0x1c1/0x420 [gtp]
RBP: dead000000000122
The second deletion dereferenced the poisoned hlist pprev pointer.
Serialize gtp_pdp_add(), gtp_genl_del_pdp(), and gtp_dellink() with a
shared mutex. Keep the mutex held until the final use of a PDP context in
the NEWPDP path, and keep the RCU read-side section around the complete
PDP context use in the DELPDP path.
Fixes: 459aa660eb ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)")
Cc: stable@vger.kernel.org
Signed-off-by: Qing Ming <a0yami@mailbox.org>
Link: https://patch.msgid.link/20260818150000.7670-1-a0yami@mailbox.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
xdp_convert_zc_to_xdp_frame() clones an XSK packet into an order-0 page
and advertises PAGE_SIZE as its frame size. It allows the copied frame
to occupy the page tail needed by skb_shared_info and records zero
headroom even when metadata separates the frame header from packet data.
An AF_XDP zero-copy packet redirected through cpumap can therefore make
the skb overlap skb_shared_info or place it beyond the allocated page.
Limit the copied layout to SKB_WITH_OVERHEAD(PAGE_SIZE) and include the
metadata length in frame headroom. Redirect callers already handle a
NULL conversion result.
BUG: KASAN: slab-out-of-bounds in skb_gro_receive
Write of size 4 at addr ffff88800cf37004 by task cpumap/1/map:1/146
Call Trace:
skb_gro_receive (net/core/gro.c:174)
udp_gro_receive (net/ipv4/udp_offload.c:812)
inet_gro_receive (net/ipv4/af_inet.c:1539)
dev_gro_receive (net/core/gro.c:515)
gro_receive_skb (net/core/gro.c:633)
cpu_map_kthread_run (kernel/bpf/cpumap.c:395)
kthread (kernel/kthread.c:436)
ret_from_fork (arch/x86/kernel/process.c:164)
ret_from_fork_asm (arch/x86/entry/entry_64.S:255)
Kernel panic - not syncing: KASAN: panic_on_warn set ...
Fixes: b0d1beeff2 ("xdp: implement convert_to_xdp_frame for MEM_TYPE_ZERO_COPY")
Cc: stable@vger.kernel.org
Reported-by: Xiang Mei <xmei5@asu.edu>
Signed-off-by: Weiming Shi <bestswngs@gmail.com>
Link: https://patch.msgid.link/20260818154516.793517-1-bestswngs@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When replacement skb allocation fails, ntb_netdev drops a packet that
was received successfully and requeues the original buffer. The drop is
counted, but rx_packets and rx_bytes are not.
Count every good packet before allocating its replacement.
Fixes: d2121faf13 ("NTB: ntb_netdev: Preserve RX queue depth on allocation failure")
Cc: stable@vger.kernel.org
Signed-off-by: Koichiro Den <den@valinux.co.jp>
Link: https://patch.msgid.link/20260819172539.1450821-3-den@valinux.co.jp
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
tcp_select_initial_window() assumes that callers never pass an MSS
smaller than 1, but route-derived advmss values can violate that
assumption.
A too-small explicit RTAX_ADVMSS is one way to get there, but it is not
the only one. The same divide-by-zero can also be reached through the
"default advmss" path when RTAX_ADVMSS is left at 0 and the effective
advmss is later driven down by route MTU and min_adv_mss.
Introduce a tcp_dst_advmss() helper that clamps route advmss to
TCP_MIN_MSS before TCP consumes it, and use it in the TCP paths that
derive advmss from dst metrics. This keeps the effective MSS from
dropping to zero before tcp_select_initial_window() rounds the receive
window.
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Reported-by: Vega <vega@nebusec.ai>
Signed-off-by: Yong Wang <edragain@163.com>
Signed-off-by: Ren Wei <weir@nebusec.ai>
Link: https://patch.msgid.link/251eaf8277fa7c66364c9815c5da01662d269181.1787074852.git.edragain@163.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In collect_md mode ipip_tunnel_rcv() returns 0 without freeing the skb
when ip_tun_rx_dst() fails to allocate the metadata_dst. ipip_rcv() and
mplsip_rcv() are registered as xfrm_tunnel handlers, so tunnel4_rcv()
and tunnelmpls4_rcv() read the zero return as "the packet has been
consumed" and do not free it either. The skb is leaked.
The other tunnel drivers all dispose of the packet at this point:
ip6_tunnel.c jumps to its drop label, ip_gre.c and ip6_gre.c return
PACKET_REJECT, which makes gre_rcv() free the skb. Only ipip returns 0.
Jump to the existing drop label instead. It frees the skb and still
returns 0, so the packet keeps being reported as consumed, which is what
we want here: the outer header has already been pulled, and neither the
remaining handlers nor an ICMP unreachable have any use for it.
Triggering this needs an ipip or mplsip tunnel in collect_md mode and an
atomic allocation failure, which is why it has gone unnoticed.
Fixes: cfc7381b30 ("ip_tunnel: add collect_md mode to IPIP tunnel")
Cc: stable@vger.kernel.org
Signed-off-by: Anton Danilov <littlesmilingcloud@gmail.com>
Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>
Link: https://patch.msgid.link/20260819104338.432631-2-littlesmilingcloud@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Allocations in the tc classifier *_change() paths (filter objects,
per-CPU counters, and per-filter aux data) use plain GFP_KERNEL without
__GFP_ACCOUNT, allowing unprivileged users to pin kernel memory outside
memcg charging. The shared tcf_exts_init_ex() action array allocation in
cls_api.c was also uncharged; this patch closes it along with the
per-classifier filter-object/percpu/aux allocations that remain
unaccounted.
Add GFP_KERNEL_ACCOUNT to:
- the shared tcf_exts_init_ex() action array (cls_api.c), common to every
filter of every classifier (32 pointers, 256 bytes);
- the filter-object, per-CPU-counter, and per-filter aux allocations in
cls_basic, cls_bpf, cls_cgroup, cls_flow, cls_flower, cls_fw,
cls_matchall, cls_route and cls_u32;
- the u32_init_knode() replace-path knode allocation (cls_u32.c), which
allocates the same struct tc_u_knode + sel.keys on every replace of an
existing knode and was missed by the create-path-only conversion.
Also fix the cls_basic error path: basic_change() inserts fnew into the
IDR before allocating the per-CPU counter. If alloc_percpu() fails the
errout path kfree'd fnew without idr_remove, leaving a dangling pointer
in the IDR. With GFP_KERNEL_ACCOUNT the percpu alloc becomes failable
on demand (memcg at memory.max), making the dead path attacker-reachable
and burning the handle permanently. Add the idr_remove on the percpu
failure path, matching the basic_set_parms failure-path pattern.
Note: vega@nebusec.ai provided a poc for basic_cls, but it was easy to
extend to the other classifiers.
Conditions to recreate the bug:
- CONFIG_NET_SCHED, CONFIG_NET_CLS_* (the classifier being used),
CONFIG_NET_CLS_ACT, CONFIG_MEMCG, CONFIG_USER_NS, CONFIG_NET_NS.
- Unprivileged user in a fresh user+network namespace (unshare -Urn),
or root with CAP_NET_ADMIN.
- Create a large number of tc filters (e.g. tc filter add dev lo
ingress ... <classifier> ...) while watching a memcg-limited cgroup:
system slab grows far faster than memory.current, pinning kernel
memory outside memcg charging.
Fixes: 0da974f4f3 ("[NET]: Conversions from kmalloc+memset to k(z|c)alloc.")
Reported-by: vega@nebusec.ai
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Reviewed-by: Breno Leitao <leitao@debian.org>
Link: https://patch.msgid.link/20260819143733.57538-1-jhs@mojatatu.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Simon Wunderlich says:
====================
Here are a few batman-adv bugfixes:
- fix stale receive device on merged fragments, by Zhiling Zou
the others are written by Sven Eckelmann:
- bla: fix potential CRC corruption issues (2 patches)
- dat: avoid unaligned fault in IP extraction
- dat: atomically update mac addresses
- mcast: fix TX priority extraction for BATADV_FORW_MCAST
- mcast: fix skb sharing and linearization (2 patches)
- bla: fix freeing of claims on meshif deletion
* tag 'batadv-net-pullrequest-20260821' of https://git.open-mesh.org/batadv:
batman-adv: bla: fix freeing of claims on meshif deletion
batman-adv: mcast: linearize skbuff for packet generation
batman-adv: mcast: ensure unshared skb for multicast packets
batman-adv: fix TX priority extraction for BATADV_FORW_MCAST
batman-adv: dat: atomically update mac addresses
batman-adv: dat: avoid unaligned fault in IP extraction
batman-adv: bla: prevent CRC corruptions after claim flush
batman-adv: bla: avoid CRC corruption due to parallel claim add
batman-adv: fix stale receive device on merged fragments
====================
Link: https://patch.msgid.link/20260821094813.201800-1-sw@simonwunderlich.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The max_period bound in net_timer_enable_perout() was computed as:
max_period = (u64)NETC_TMR_DEFAULT_FIPER + integral_period;
which exceeds U32_MAX when integral_period > 0 (e.g. 0x100000002 for
the default 333333333 Hz clock). A period_ns that passes this check but
exceeds U32_MAX is then silently truncated when stored into the u32
struct netc_pp::period field.
A truncated value of zero can reach netc_timer_set_perout_alarm(), where
the local u32 period variable would also be 0, causing a divide-by-zero
in roundup_u64(delta, period) whenever the stime < min_time branch is
taken (which always happens for a start time of {0, 0}).
Additionally, netc_timer_enable_periodic_pulse() and
netc_timer_enable_fiper() both compute:
fiper = pp->period - integral_period;
A zero pp->period results in an unsigned wraparound to 0xFFFFFFFD,
mis-programming the FIPER hardware register.
Fix all three issues by capping max_period at NETC_TMR_DEFAULT_FIPER
(0xFFFFFFFF). This ensures that any period_ns passing the range check
fits in a u32 without truncation, so the stored value is always valid
and non-zero. The accepted range is reduced by integral_period ns
(typically only a few nanoseconds), which is negligible in practice.
Fixes: 671e266835 ("ptp: netc: add periodic pulse output support")
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Link: https://patch.msgid.link/20260821032449.1235065-1-wei.fang@oss.nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In bnxt_request_irq(), pcie_enable_tph() is called unconditionally to
enable PCIe TPH when setting up interrupts.
If the NIC hardware or firmware capabilities do not support queue ops,
attempting to enable TPH during bnxt_request_irq() is unnecessary.
As a result a flood of "RX queue restart failed: err=-95" messages is
seen upon boot.
Older NICs (pre-Thor / BCM57414) do not support TPH or queue management.
TPH requires queue management to restart the queue. NICs that support
queue management (with updated FW) all support TPH.
Gate the call to pcie_enable_tph() and setting of bp->tph_mode
behind BNXT_SUPPORTS_QUEUE_API(bp) to ensure TPH is only initialized
on devices capable of supporting queue ops. This prevents a guaranteed
-EOPNOTSUPP error from occurring due to NULL operations.
Fixes: c214410c47 ("bnxt_en: Add TPH support in BNXT driver")
Suggested-by: Michal Schmidt <mschmidt@redhat.com>
Signed-off-by: Thomas Walsh <thwalsh@redhat.com>
Reviewed-by: Michael Chan <michael.chan@broadcom.com>
Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
Link: https://patch.msgid.link/20260820220544.1240879-1-thwalsh@redhat.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
