* Re: [PATCH net v2] selftests: netfilter: conntrack_sctp_collision.sh: Introduce SCTP INIT collision test
From: Jakub Kicinski @ 2026-04-20 15:23 UTC (permalink / raw)
To: Yi Chen
Cc: Pablo Neira Ayuso, Florian Westphal, Phil Sutter, Long Xin,
David S . Miller, Eric Dumazet, Paolo Abeni, Simon Horman,
Shuah Khan, coreteam, netfilter-devel, linux-kselftest,
linux-kernel, netdev
In-Reply-To: <20260418195843.303946-1-yiche.cy@gmail.com>
On Sun, 19 Apr 2026 03:58:43 +0800 Yi Chen wrote:
> The existing test covered a scenario where a delayed INIT_ACK chunk
> updates the vtag in conntrack after the association has already been
> established.
AI says:
The conntrack_sctp_collision.sh selftest is now failing in the NIPA CI on
both the normal and debug kernel builds:
not ok 1 1 selftests: net/netfilter: conntrack_sctp_collision.sh # exit=1
# Test for SCTP INIT_ACK Collision in nf_conntrack:
# Invalid netns name ""
# Invalid netns name ""
The root cause is a shell variable scoping bug introduced by this patch.
The new test structure wraps `topo_setup` in a subshell:
(topo_setup && conf_delay $SERVER_NS link0 2) || exit $?
if ! do_test; then
...
fi
`topo_setup` calls `setup_ns CLIENT_NS SERVER_NS ROUTER_NS`, which sets
those variables inside the subshell. Those assignments do not propagate
back to the parent shell, so when `do_test` is called afterwards, both
`$SERVER_NS` and `$CLIENT_NS` expand to empty strings. The `ip net exec ""`
calls then fail with "Invalid netns name """.
The second test case (SCTP INIT Collision) would have the same problem.
The fix is to avoid the subshell or ensure the namespace variables are
visible to `do_test`. The simplest approach is to remove the subshell
wrapping and call `topo_setup`, `conf_delay`, and `do_test` in the same
shell scope:
topo_setup && conf_delay "$SERVER_NS" link0 2 || exit $?
if ! do_test; then
exit $ksft_fail
fi
topo_setup && conf_delay "$CLIENT_NS" link3 1 || exit $?
if ! do_test; then
exit $ksft_fail
fi
Please also note that `conf_delay` references `$ROUTER_NS` directly
(not via a parameter), so it too requires that those variables be set
in the same shell scope.
^ permalink raw reply
* Re: [PATCH net 1/4] xsk: avoid skb leak in XDP_TX_METADATA case
From: Stanislav Fomichev @ 2026-04-20 15:22 UTC (permalink / raw)
To: Jason Xing
Cc: davem, edumazet, kuba, pabeni, bjorn, magnus.karlsson,
maciej.fijalkowski, jonathan.lemon, sdf, ast, daniel, hawk,
john.fastabend, horms, andrew+netdev, bpf, netdev, Jason Xing
In-Reply-To: <20260418045644.28612-2-kerneljasonxing@gmail.com>
On 04/18, Jason Xing wrote:
> From: Jason Xing <kernelxing@tencent.com>
>
> Fix it by explicitly adding kfree_skb() before returning back to its
> caller.
>
> How to reproduce it in virtio_net:
> 1. the current skb is the first one (which means no frag and xs->skb is
> NULL) and users enable metadata feature.
> 2. xsk_skb_metadata() returns a error code.
> 3. the caller xsk_build_skb() clears skb by using 'skb = NULL;'.
> 4. there is no chance to free this skb anymore.
>
> Closes: https://lore.kernel.org/all/20260415085204.3F87AC19424@smtp.kernel.org/
> Fixes: 30c3055f9c0d ("xsk: wrap generic metadata handling onto separate function")
> Signed-off-by: Jason Xing <kernelxing@tencent.com>
Acked-by: Stanislav Fomichev <sdf@fomichev.me>
^ permalink raw reply
* Re: [PATCH 1/1] tipc: fix double-free in tipc_buf_append()
From: Lee Jones @ 2026-04-20 15:10 UTC (permalink / raw)
To: Tung Quang Nguyen
Cc: Jon Maloy, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, netdev@vger.kernel.org,
tipc-discussion@lists.sourceforge.net,
linux-kernel@vger.kernel.org
In-Reply-To: <GV1P189MB198853F316580DDA547F4925C62F2@GV1P189MB1988.EURP189.PROD.OUTLOOK.COM>
On Mon, 20 Apr 2026, Tung Quang Nguyen wrote:
> >> Subject: [PATCH 1/1] tipc: fix double-free in tipc_buf_append()
> >> >
> >> >The tipc_msg_validate() function can potentially reallocate the skb
> >> >it is validating, freeing the old one. In tipc_buf_append(), it was
> >> >being called with a pointer to a local variable which was a copy of the
> >caller's skb pointer.
> >> >
> >> >If the skb was reallocated and validation subsequently failed, the
> >> >error handling path would free the original skb pointer, which had
> >> >already been freed, leading to double-free.
> >> >
> >> >Fix this by passing the caller's skb pointer-pointer directly to
> >> >tipc_msg_validate(), ensuring any modification is reflected correctly.
> >> >The local skb pointer is then updated from the (possibly modified)
> >> >caller's pointer.
> >> >
> >> >Fixes: d618d09a68e4 ("tipc: enforce valid ratio between skb truesize
> >> >and
> >> >contents")
> >> >Assisted-by: Gemini:gemini-3.1-pro-preview
> >> >Signed-off-by: Lee Jones <lee@kernel.org>
> >> >---
> >> > net/tipc/msg.c | 3 ++-
> >> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >> >
> >> >diff --git a/net/tipc/msg.c b/net/tipc/msg.c index
> >> >76284fc538eb..9f4f612ee027
> >> >100644
> >> >--- a/net/tipc/msg.c
> >> >+++ b/net/tipc/msg.c
> >> >@@ -177,8 +177,9 @@ int tipc_buf_append(struct sk_buff **headbuf,
> >> >struct sk_buff **buf)
> >> >
> >> > if (fragid == LAST_FRAGMENT) {
> >> > TIPC_SKB_CB(head)->validated = 0;
> >> >- if (unlikely(!tipc_msg_validate(&head)))
> >> >+ if (unlikely(!tipc_msg_validate(headbuf)))
> >> > goto err;
> >> >+ head = *headbuf;
> >> This is a known issue and was reported via
> >> https://patchwork.kernel.org/project/netdevbpf/patch/20260330205313.24
> >> 33372-1-nicholas@carlini.com/ The author did not respond to my
> >> comment.
> >> Can you improve the fix by applying my patch?
> >
> >I'd be happy to make any required changes.
> >
> >However, is this approach superior to simply passing a reference?
> >
> >v1 appears to be simpler, easier to read and avoids the explanation.
> >
> As I explained, your fix adds extra overhead to normal path while the error path is corner case and it rarely happens.
> Whatever approach is applied, we need to add explanation to understand more easily the logic and hidden trick in tipc_msg_validate().
Very well. I have made the recommended changes.
The patch is currently in my build-test environment.
I will post v2, when everything has been satisfied.
--
Lee Jones [李琼斯]
^ permalink raw reply
* [PATCH net 4/4] rxrpc: Fix rxkad crypto unalignment handling
From: David Howells @ 2026-04-20 14:58 UTC (permalink / raw)
To: netdev
Cc: David Howells, Marc Dionne, Jakub Kicinski, David S. Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, linux-afs, linux-kernel,
Jeffrey Altman, stable
In-Reply-To: <20260420145900.1223732-1-dhowells@redhat.com>
Fix handling of a packet with a misaligned crypto length. Also handle
non-ENOMEM errors from decryption by aborting. Further, remove the
WARN_ON_ONCE() so that it can't be remotely triggered (a trace line can
still be emitted).
Fixes: f93af41b9f5f ("rxrpc: Fix missing error checks for rxkad encryption/decryption failure")
Closes: https://sashiko.dev/#/patchset/20260408121252.2249051-1-dhowells%40redhat.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Marc Dionne <marc.dionne@auristor.com>
cc: Jeffrey Altman <jaltman@auristor.com>
cc: Eric Dumazet <edumazet@google.com>
cc: "David S. Miller" <davem@davemloft.net>
cc: Jakub Kicinski <kuba@kernel.org>
cc: Paolo Abeni <pabeni@redhat.com>
cc: Simon Horman <horms@kernel.org>
cc: linux-afs@lists.infradead.org
cc: netdev@vger.kernel.org
cc: stable@kernel.org
---
include/trace/events/rxrpc.h | 1 +
net/rxrpc/rxkad.c | 9 +++++++--
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/include/trace/events/rxrpc.h b/include/trace/events/rxrpc.h
index 578b8038b211..5820d7e41ea0 100644
--- a/include/trace/events/rxrpc.h
+++ b/include/trace/events/rxrpc.h
@@ -37,6 +37,7 @@
EM(rxkad_abort_1_short_encdata, "rxkad1-short-encdata") \
EM(rxkad_abort_1_short_header, "rxkad1-short-hdr") \
EM(rxkad_abort_2_short_check, "rxkad2-short-check") \
+ EM(rxkad_abort_2_crypto_unaligned, "rxkad2-crypto-unaligned") \
EM(rxkad_abort_2_short_data, "rxkad2-short-data") \
EM(rxkad_abort_2_short_header, "rxkad2-short-hdr") \
EM(rxkad_abort_2_short_len, "rxkad2-short-len") \
diff --git a/net/rxrpc/rxkad.c b/net/rxrpc/rxkad.c
index 0acdc46f42c2..2c4697063ab2 100644
--- a/net/rxrpc/rxkad.c
+++ b/net/rxrpc/rxkad.c
@@ -510,6 +510,9 @@ static int rxkad_verify_packet_2(struct rxrpc_call *call, struct sk_buff *skb,
return rxrpc_abort_eproto(call, skb, RXKADSEALEDINCON,
rxkad_abort_2_short_header);
+ /* Don't let the crypto algo see a misaligned length. */
+ sp->len = round_down(sp->len, 8);
+
/* Decrypt the skbuff in-place. TODO: We really want to decrypt
* directly into the target buffer.
*/
@@ -543,8 +546,10 @@ static int rxkad_verify_packet_2(struct rxrpc_call *call, struct sk_buff *skb,
if (sg != _sg)
kfree(sg);
if (ret < 0) {
- WARN_ON_ONCE(ret != -ENOMEM);
- return ret;
+ if (ret == -ENOMEM)
+ return ret;
+ return rxrpc_abort_eproto(call, skb, RXKADSEALEDINCON,
+ rxkad_abort_2_crypto_unaligned);
}
/* Extract the decrypted packet length */
^ permalink raw reply related
* [PATCH net 3/4] rxgk: Fix potential integer overflow in length check
From: David Howells @ 2026-04-20 14:58 UTC (permalink / raw)
To: netdev
Cc: David Howells, Marc Dionne, Jakub Kicinski, David S. Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, linux-afs, linux-kernel,
Jeffrey Altman, stable
In-Reply-To: <20260420145900.1223732-1-dhowells@redhat.com>
Fix potential integer overflow in rxgk_extract_token() when checking the
length of the ticket. Rather than rounding up the value to be tested
(which might overflow), round down the size of the available data.
Fixes: 2429a1976481 ("rxrpc: Fix untrusted unsigned subtract")
Closes: https://sashiko.dev/#/patchset/20260408121252.2249051-1-dhowells%40redhat.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Marc Dionne <marc.dionne@auristor.com>
cc: Jeffrey Altman <jaltman@auristor.com>
cc: Eric Dumazet <edumazet@google.com>
cc: "David S. Miller" <davem@davemloft.net>
cc: Jakub Kicinski <kuba@kernel.org>
cc: Paolo Abeni <pabeni@redhat.com>
cc: Simon Horman <horms@kernel.org>
cc: linux-afs@lists.infradead.org
cc: netdev@vger.kernel.org
cc: stable@kernel.org
---
net/rxrpc/rxgk_app.c | 2 +-
net/rxrpc/rxgk_common.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/rxrpc/rxgk_app.c b/net/rxrpc/rxgk_app.c
index 30275cb5ba3e..5587639d60c5 100644
--- a/net/rxrpc/rxgk_app.c
+++ b/net/rxrpc/rxgk_app.c
@@ -214,7 +214,7 @@ int rxgk_extract_token(struct rxrpc_connection *conn, struct sk_buff *skb,
ticket_len = ntohl(container.token_len);
ticket_offset = token_offset + sizeof(container);
- if (xdr_round_up(ticket_len) > token_len - sizeof(container))
+ if (ticket_len > xdr_round_down(token_len - sizeof(container)))
goto short_packet;
_debug("KVNO %u", kvno);
diff --git a/net/rxrpc/rxgk_common.h b/net/rxrpc/rxgk_common.h
index 80164d89e19c..1e257d7ab8ec 100644
--- a/net/rxrpc/rxgk_common.h
+++ b/net/rxrpc/rxgk_common.h
@@ -34,6 +34,7 @@ struct rxgk_context {
};
#define xdr_round_up(x) (round_up((x), sizeof(__be32)))
+#define xdr_round_down(x) (round_down((x), sizeof(__be32)))
#define xdr_object_len(x) (4 + xdr_round_up(x))
/*
^ permalink raw reply related
* [PATCH net 2/4] rxrpc: Fix conn-level packet handling to unshare RESPONSE packets
From: David Howells @ 2026-04-20 14:58 UTC (permalink / raw)
To: netdev
Cc: David Howells, Marc Dionne, Jakub Kicinski, David S. Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, linux-afs, linux-kernel,
Jeffrey Altman, stable
In-Reply-To: <20260420145900.1223732-1-dhowells@redhat.com>
The security operations that verify the RESPONSE packets decrypt bits of it
in place - however, the sk_buff may be shared with a packet sniffer, which
would lead to the sniffer seeing an apparently corrupt packet (actually
decrypted).
Fix this by unsharing the skbuff before handing it off to the specific
security handler.
Fixes: 17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both")
Closes: https://sashiko.dev/#/patchset/20260408121252.2249051-1-dhowells%40redhat.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Marc Dionne <marc.dionne@auristor.com>
cc: Jeffrey Altman <jaltman@auristor.com>
cc: Eric Dumazet <edumazet@google.com>
cc: "David S. Miller" <davem@davemloft.net>
cc: Jakub Kicinski <kuba@kernel.org>
cc: Paolo Abeni <pabeni@redhat.com>
cc: Simon Horman <horms@kernel.org>
cc: linux-afs@lists.infradead.org
cc: netdev@vger.kernel.org
cc: stable@kernel.org
---
net/rxrpc/ar-internal.h | 2 +-
net/rxrpc/conn_event.c | 12 ++++++++++--
net/rxrpc/io_thread.c | 15 +++------------
net/rxrpc/skbuff.c | 26 ++++++++++++++++++++++----
4 files changed, 36 insertions(+), 19 deletions(-)
diff --git a/net/rxrpc/ar-internal.h b/net/rxrpc/ar-internal.h
index 96ecb83c9071..fb04d2ffdb27 100644
--- a/net/rxrpc/ar-internal.h
+++ b/net/rxrpc/ar-internal.h
@@ -1486,7 +1486,7 @@ int rxrpc_server_keyring(struct rxrpc_sock *, sockptr_t, int);
void rxrpc_kernel_data_consumed(struct rxrpc_call *, struct sk_buff *);
void rxrpc_new_skb(struct sk_buff *, enum rxrpc_skb_trace);
void rxrpc_see_skb(struct sk_buff *, enum rxrpc_skb_trace);
-void rxrpc_eaten_skb(struct sk_buff *, enum rxrpc_skb_trace);
+struct sk_buff *rxrpc_unshare_skb(struct sk_buff **_old, gfp_t gfp);
void rxrpc_get_skb(struct sk_buff *, enum rxrpc_skb_trace);
void rxrpc_free_skb(struct sk_buff *, enum rxrpc_skb_trace);
void rxrpc_purge_queue(struct sk_buff_head *);
diff --git a/net/rxrpc/conn_event.c b/net/rxrpc/conn_event.c
index 9a41ec708aeb..3d56a5d23369 100644
--- a/net/rxrpc/conn_event.c
+++ b/net/rxrpc/conn_event.c
@@ -244,8 +244,9 @@ static void rxrpc_call_is_secure(struct rxrpc_call *call)
* connection-level Rx packet processor
*/
static int rxrpc_process_event(struct rxrpc_connection *conn,
- struct sk_buff *skb)
+ struct sk_buff **_skb)
{
+ struct sk_buff *skb = *_skb;
struct rxrpc_skb_priv *sp = rxrpc_skb(skb);
bool secured = false;
int ret;
@@ -270,6 +271,13 @@ static int rxrpc_process_event(struct rxrpc_connection *conn,
}
spin_unlock_irq(&conn->state_lock);
+ skb = rxrpc_unshare_skb(_skb, GFP_NOFS);
+ if (!skb)
+ return -ENOMEM;
+
+ /* If unshared, skb will have changed. */
+ sp = rxrpc_skb(skb);
+
ret = conn->security->verify_response(conn, skb);
if (ret < 0)
return ret;
@@ -371,7 +379,7 @@ static void rxrpc_do_process_connection(struct rxrpc_connection *conn)
* connection that each one has when we've finished with it */
while ((skb = skb_dequeue(&conn->rx_queue))) {
rxrpc_see_skb(skb, rxrpc_skb_see_conn_work);
- ret = rxrpc_process_event(conn, skb);
+ ret = rxrpc_process_event(conn, &skb);
switch (ret) {
case -ENOMEM:
case -EAGAIN:
diff --git a/net/rxrpc/io_thread.c b/net/rxrpc/io_thread.c
index 697956931925..0592ce644fc3 100644
--- a/net/rxrpc/io_thread.c
+++ b/net/rxrpc/io_thread.c
@@ -249,19 +249,10 @@ static bool rxrpc_input_packet(struct rxrpc_local *local, struct sk_buff **_skb)
* decryption.
*/
if (sp->hdr.securityIndex != 0) {
- skb = skb_unshare(skb, GFP_ATOMIC);
- if (!skb) {
- rxrpc_eaten_skb(*_skb, rxrpc_skb_eaten_by_unshare_nomem);
- *_skb = NULL;
+ skb = rxrpc_unshare_skb(_skb, GFP_ATOMIC);
+ if (!skb)
return just_discard;
- }
-
- if (skb != *_skb) {
- rxrpc_eaten_skb(*_skb, rxrpc_skb_eaten_by_unshare);
- *_skb = skb;
- rxrpc_new_skb(skb, rxrpc_skb_new_unshared);
- sp = rxrpc_skb(skb);
- }
+ sp = rxrpc_skb(skb);
}
break;
diff --git a/net/rxrpc/skbuff.c b/net/rxrpc/skbuff.c
index 3bcd6ee80396..0dca9ca163f1 100644
--- a/net/rxrpc/skbuff.c
+++ b/net/rxrpc/skbuff.c
@@ -47,12 +47,30 @@ void rxrpc_get_skb(struct sk_buff *skb, enum rxrpc_skb_trace why)
}
/*
- * Note the dropping of a ref on a socket buffer by the core.
+ * Do the unsharing of a socket buffer, noting the event in the traces.
*/
-void rxrpc_eaten_skb(struct sk_buff *skb, enum rxrpc_skb_trace why)
+struct sk_buff *rxrpc_unshare_skb(struct sk_buff **_old, gfp_t gfp)
{
- int n = atomic_inc_return(&rxrpc_n_rx_skbs);
- trace_rxrpc_skb(skb, 0, n, why);
+ struct sk_buff *skb, *old = *_old;
+ int n, r = refcount_read(&old->users);
+
+ skb = skb_unshare(old, gfp);
+ if (!skb) {
+ n = atomic_dec_return(&rxrpc_n_rx_skbs);
+ trace_rxrpc_skb(old, r, n, rxrpc_skb_eaten_by_unshare_nomem);
+ *_old = NULL;
+ return skb;
+ }
+
+ if (skb != old) {
+ n = atomic_read(&rxrpc_n_rx_skbs);
+ trace_rxrpc_skb(old, r, n, rxrpc_skb_eaten_by_unshare);
+ trace_rxrpc_skb(skb, refcount_read(&skb->users), n,
+ rxrpc_skb_new_unshared);
+ *_old = skb;
+ }
+
+ return skb;
}
/*
^ permalink raw reply related
* [PATCH net 1/4] rxrpc: Fix memory leaks in rxkad_verify_response()
From: David Howells @ 2026-04-20 14:58 UTC (permalink / raw)
To: netdev
Cc: David Howells, Marc Dionne, Jakub Kicinski, David S. Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, linux-afs, linux-kernel,
Jeffrey Altman, stable
In-Reply-To: <20260420145900.1223732-1-dhowells@redhat.com>
Fix rxkad_verify_response() to free ticket by using a __free() construct
rather than explicitly freeing it.
Also fix rxkad_verify_response() to free the server key by using a __free()
construct.
Fixes: 57af281e5389 ("rxrpc: Tidy up abort generation infrastructure")
Fixes: ec832bd06d6f ("rxrpc: Don't retain the server key in the connection")
Closes: https://sashiko.dev/#/patchset/20260408121252.2249051-1-dhowells%40redhat.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Marc Dionne <marc.dionne@auristor.com>
cc: Jeffrey Altman <jaltman@auristor.com>
cc: Eric Dumazet <edumazet@google.com>
cc: "David S. Miller" <davem@davemloft.net>
cc: Jakub Kicinski <kuba@kernel.org>
cc: Paolo Abeni <pabeni@redhat.com>
cc: Simon Horman <horms@kernel.org>
cc: linux-afs@lists.infradead.org
cc: netdev@vger.kernel.org
cc: stable@kernel.org
---
include/linux/key.h | 2 +
net/rxrpc/rxkad.c | 133 +++++++++++++++-----------------------------
2 files changed, 48 insertions(+), 87 deletions(-)
diff --git a/include/linux/key.h b/include/linux/key.h
index 81b8f05c6898..1cafbc3827c2 100644
--- a/include/linux/key.h
+++ b/include/linux/key.h
@@ -304,6 +304,8 @@ extern void key_put(struct key *key);
extern bool key_put_tag(struct key_tag *tag);
extern void key_remove_domain(struct key_tag *domain_tag);
+DEFINE_FREE(key_put, struct key *, if (!IS_ERR(_T)) key_put(_T))
+
static inline struct key *__key_get(struct key *key)
{
refcount_inc(&key->usage);
diff --git a/net/rxrpc/rxkad.c b/net/rxrpc/rxkad.c
index eb7f2769d2b1..0acdc46f42c2 100644
--- a/net/rxrpc/rxkad.c
+++ b/net/rxrpc/rxkad.c
@@ -1131,21 +1131,20 @@ static int rxkad_decrypt_response(struct rxrpc_connection *conn,
static int rxkad_verify_response(struct rxrpc_connection *conn,
struct sk_buff *skb)
{
- struct rxkad_response *response;
struct rxrpc_skb_priv *sp = rxrpc_skb(skb);
struct rxrpc_crypt session_key;
- struct key *server_key;
time64_t expiry;
- void *ticket;
u32 version, kvno, ticket_len, level;
__be32 csum;
int ret, i;
_enter("{%d}", conn->debug_id);
- server_key = rxrpc_look_up_server_security(conn, skb, 0, 0);
+ struct key *server_key __free(key_put) =
+ rxrpc_look_up_server_security(conn, skb, 0, 0);
if (IS_ERR(server_key)) {
ret = PTR_ERR(server_key);
+ server_key = NULL;
switch (ret) {
case -ENOKEY:
return rxrpc_abort_conn(conn, skb, RXKADUNKNOWNKEY, ret,
@@ -1160,16 +1159,15 @@ static int rxkad_verify_response(struct rxrpc_connection *conn,
}
ret = -ENOMEM;
- response = kzalloc_obj(struct rxkad_response, GFP_NOFS);
+ struct rxkad_response *response __free(kfree) =
+ kzalloc_obj(struct rxkad_response, GFP_NOFS);
if (!response)
goto temporary_error;
if (skb_copy_bits(skb, sizeof(struct rxrpc_wire_header),
- response, sizeof(*response)) < 0) {
- rxrpc_abort_conn(conn, skb, RXKADPACKETSHORT, -EPROTO,
- rxkad_abort_resp_short);
- goto protocol_error;
- }
+ response, sizeof(*response)) < 0)
+ return rxrpc_abort_conn(conn, skb, RXKADPACKETSHORT, -EPROTO,
+ rxkad_abort_resp_short);
version = ntohl(response->version);
ticket_len = ntohl(response->ticket_len);
@@ -1177,103 +1175,79 @@ static int rxkad_verify_response(struct rxrpc_connection *conn,
trace_rxrpc_rx_response(conn, sp->hdr.serial, version, kvno, ticket_len);
- if (version != RXKAD_VERSION) {
- rxrpc_abort_conn(conn, skb, RXKADINCONSISTENCY, -EPROTO,
- rxkad_abort_resp_version);
- goto protocol_error;
- }
+ if (version != RXKAD_VERSION)
+ return rxrpc_abort_conn(conn, skb, RXKADINCONSISTENCY, -EPROTO,
+ rxkad_abort_resp_version);
- if (ticket_len < 4 || ticket_len > MAXKRB5TICKETLEN) {
- rxrpc_abort_conn(conn, skb, RXKADTICKETLEN, -EPROTO,
- rxkad_abort_resp_tkt_len);
- goto protocol_error;
- }
+ if (ticket_len < 4 || ticket_len > MAXKRB5TICKETLEN)
+ return rxrpc_abort_conn(conn, skb, RXKADTICKETLEN, -EPROTO,
+ rxkad_abort_resp_tkt_len);
- if (kvno >= RXKAD_TKT_TYPE_KERBEROS_V5) {
- rxrpc_abort_conn(conn, skb, RXKADUNKNOWNKEY, -EPROTO,
- rxkad_abort_resp_unknown_tkt);
- goto protocol_error;
- }
+ if (kvno >= RXKAD_TKT_TYPE_KERBEROS_V5)
+ return rxrpc_abort_conn(conn, skb, RXKADUNKNOWNKEY, -EPROTO,
+ rxkad_abort_resp_unknown_tkt);
/* extract the kerberos ticket and decrypt and decode it */
ret = -ENOMEM;
- ticket = kmalloc(ticket_len, GFP_NOFS);
+ void *ticket __free(kfree) = kmalloc(ticket_len, GFP_NOFS);
if (!ticket)
- goto temporary_error_free_resp;
+ goto temporary_error;
if (skb_copy_bits(skb, sizeof(struct rxrpc_wire_header) + sizeof(*response),
- ticket, ticket_len) < 0) {
- rxrpc_abort_conn(conn, skb, RXKADPACKETSHORT, -EPROTO,
- rxkad_abort_resp_short_tkt);
- goto protocol_error;
- }
+ ticket, ticket_len) < 0)
+ return rxrpc_abort_conn(conn, skb, RXKADPACKETSHORT, -EPROTO,
+ rxkad_abort_resp_short_tkt);
ret = rxkad_decrypt_ticket(conn, server_key, skb, ticket, ticket_len,
&session_key, &expiry);
if (ret < 0)
- goto temporary_error_free_ticket;
+ goto temporary_error;
/* use the session key from inside the ticket to decrypt the
* response */
ret = rxkad_decrypt_response(conn, response, &session_key);
if (ret < 0)
- goto temporary_error_free_ticket;
+ goto temporary_error;
if (ntohl(response->encrypted.epoch) != conn->proto.epoch ||
ntohl(response->encrypted.cid) != conn->proto.cid ||
- ntohl(response->encrypted.securityIndex) != conn->security_ix) {
- rxrpc_abort_conn(conn, skb, RXKADSEALEDINCON, -EPROTO,
- rxkad_abort_resp_bad_param);
- goto protocol_error_free;
- }
+ ntohl(response->encrypted.securityIndex) != conn->security_ix)
+ return rxrpc_abort_conn(conn, skb, RXKADSEALEDINCON, -EPROTO,
+ rxkad_abort_resp_bad_param);
csum = response->encrypted.checksum;
response->encrypted.checksum = 0;
rxkad_calc_response_checksum(response);
- if (response->encrypted.checksum != csum) {
- rxrpc_abort_conn(conn, skb, RXKADSEALEDINCON, -EPROTO,
- rxkad_abort_resp_bad_checksum);
- goto protocol_error_free;
- }
+ if (response->encrypted.checksum != csum)
+ return rxrpc_abort_conn(conn, skb, RXKADSEALEDINCON, -EPROTO,
+ rxkad_abort_resp_bad_checksum);
for (i = 0; i < RXRPC_MAXCALLS; i++) {
u32 call_id = ntohl(response->encrypted.call_id[i]);
u32 counter = READ_ONCE(conn->channels[i].call_counter);
- if (call_id > INT_MAX) {
- rxrpc_abort_conn(conn, skb, RXKADSEALEDINCON, -EPROTO,
- rxkad_abort_resp_bad_callid);
- goto protocol_error_free;
- }
-
- if (call_id < counter) {
- rxrpc_abort_conn(conn, skb, RXKADSEALEDINCON, -EPROTO,
- rxkad_abort_resp_call_ctr);
- goto protocol_error_free;
- }
-
+ if (call_id > INT_MAX)
+ return rxrpc_abort_conn(conn, skb, RXKADSEALEDINCON, -EPROTO,
+ rxkad_abort_resp_bad_callid);
+ if (call_id < counter)
+ return rxrpc_abort_conn(conn, skb, RXKADSEALEDINCON, -EPROTO,
+ rxkad_abort_resp_call_ctr);
if (call_id > counter) {
- if (conn->channels[i].call) {
- rxrpc_abort_conn(conn, skb, RXKADSEALEDINCON, -EPROTO,
- rxkad_abort_resp_call_state);
- goto protocol_error_free;
- }
+ if (conn->channels[i].call)
+ return rxrpc_abort_conn(conn, skb, RXKADSEALEDINCON, -EPROTO,
+ rxkad_abort_resp_call_state);
conn->channels[i].call_counter = call_id;
}
}
- if (ntohl(response->encrypted.inc_nonce) != conn->rxkad.nonce + 1) {
- rxrpc_abort_conn(conn, skb, RXKADOUTOFSEQUENCE, -EPROTO,
- rxkad_abort_resp_ooseq);
- goto protocol_error_free;
- }
+ if (ntohl(response->encrypted.inc_nonce) != conn->rxkad.nonce + 1)
+ return rxrpc_abort_conn(conn, skb, RXKADOUTOFSEQUENCE, -EPROTO,
+ rxkad_abort_resp_ooseq);
level = ntohl(response->encrypted.level);
- if (level > RXRPC_SECURITY_ENCRYPT) {
- rxrpc_abort_conn(conn, skb, RXKADLEVELFAIL, -EPROTO,
- rxkad_abort_resp_level);
- goto protocol_error_free;
- }
+ if (level > RXRPC_SECURITY_ENCRYPT)
+ return rxrpc_abort_conn(conn, skb, RXKADLEVELFAIL, -EPROTO,
+ rxkad_abort_resp_level);
conn->security_level = level;
/* create a key to hold the security data and expiration time - after
@@ -1281,30 +1255,15 @@ static int rxkad_verify_response(struct rxrpc_connection *conn,
* as for a client connection */
ret = rxrpc_get_server_data_key(conn, &session_key, expiry, kvno);
if (ret < 0)
- goto temporary_error_free_ticket;
-
- kfree(ticket);
- kfree(response);
+ goto temporary_error;
_leave(" = 0");
return 0;
-protocol_error_free:
- kfree(ticket);
-protocol_error:
- kfree(response);
- key_put(server_key);
- return -EPROTO;
-
-temporary_error_free_ticket:
- kfree(ticket);
-temporary_error_free_resp:
- kfree(response);
temporary_error:
/* Ignore the response packet if we got a temporary error such as
* ENOMEM. We just want to send the challenge again. Note that we
* also come out this way if the ticket decryption fails.
*/
- key_put(server_key);
return ret;
}
^ permalink raw reply related
* [PATCH net 0/4] rxrpc: Miscellaneous fixes
From: David Howells @ 2026-04-20 14:58 UTC (permalink / raw)
To: netdev
Cc: David Howells, Marc Dionne, Jakub Kicinski, David S. Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, linux-afs, linux-kernel
Here are some fixes for rxrpc, as found by Sashiko[1]:
(1) Fix leaks in rxkad_verify_response().
(2) Fix lack of unsharing of RESPONSE packets.
(3) Fix integer overflow in RxGK ticket length check.
(4) Fix handling of rxkad-encrypted packets with crypto-misaligned
lengths.
David
The patches can be found here also:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=rxrpc-fixes
Link: https://sashiko.dev/#/patchset/20260408121252.2249051-1-dhowells%40redhat.com [1]
David Howells (4):
rxrpc: Fix memory leaks in rxkad_verify_response()
rxrpc: Fix conn-level packet handling to unshare RESPONSE packets
rxgk: Fix potential integer overflow in length check
rxrpc: Fix rxkad crypto unalignment handling
include/linux/key.h | 2 +
include/trace/events/rxrpc.h | 1 +
net/rxrpc/ar-internal.h | 2 +-
net/rxrpc/conn_event.c | 12 ++-
net/rxrpc/io_thread.c | 15 +---
net/rxrpc/rxgk_app.c | 2 +-
net/rxrpc/rxgk_common.h | 1 +
net/rxrpc/rxkad.c | 142 +++++++++++++----------------------
net/rxrpc/skbuff.c | 26 ++++++-
9 files changed, 94 insertions(+), 109 deletions(-)
^ permalink raw reply
* [PATCH net-next] net: hns: use u32 for register offset in RCB TX coalescing
From: Agalakov Daniil @ 2026-04-20 14:40 UTC (permalink / raw)
To: Jian Shen
Cc: Agalakov Daniil, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, linux-kernel, lvc-project,
Roman Razov
The local variable reg in hns_rcb_get_tx_coalesced_frames() and
hns_rcb_set_tx_coalesced_frames() holds a register offset passed to
dsaf_read_dev()/dsaf_write_dev(). Register offsets on this hardware
are 32-bit values; using u64 was misleading.
Change the type to u32, consistent with the hardware.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Agalakov Daniil <ade@amicon.ru>
---
drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
index 635b3a95dd82..3c4e4e8ca140 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
@@ -563,7 +563,7 @@ u32 hns_rcb_get_rx_coalesced_frames(
u32 hns_rcb_get_tx_coalesced_frames(
struct rcb_common_cb *rcb_common, u32 port_idx)
{
- u64 reg;
+ u32 reg;
reg = RCB_CFG_PKTLINE_REG + (port_idx + HNS_RCB_TX_PKTLINE_OFFSET) * 4;
return dsaf_read_dev(rcb_common, reg);
@@ -634,7 +634,7 @@ int hns_rcb_set_tx_coalesced_frames(
{
u32 old_waterline =
hns_rcb_get_tx_coalesced_frames(rcb_common, port_idx);
- u64 reg;
+ u32 reg;
if (coalesced_frames == old_waterline)
return 0;
--
2.51.0
^ permalink raw reply related
* RE: [Intel-wired-lan] [PATCH v5 net-next 0/8] dpll/ice: Add TXC DPLL type and full TX reference clock control for E825
From: Kubalewski, Arkadiusz @ 2026-04-20 14:52 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Vecera, Ivan, vadim.fedorenko@linux.dev, edumazet@google.com,
netdev@vger.kernel.org, richardcochran@gmail.com,
donald.hunter@gmail.com, linux-kernel@vger.kernel.org,
davem@davemloft.net, Prathosh.Satish@microchip.com,
andrew+netdev@lunn.ch, intel-wired-lan@lists.osuosl.org,
horms@kernel.org, Kitszel, Przemyslaw, Nguyen, Anthony L,
pabeni@redhat.com, jiri@resnulli.us
In-Reply-To: <20260418122603.06d12715@kernel.org>
>From: Jakub Kicinski <kuba@kernel.org>
>Sent: Saturday, April 18, 2026 9:26 PM
>
>On Fri, 17 Apr 2026 12:22:05 +0000 Kubalewski, Arkadiusz wrote:
>> >> I was thinking that this is more like a purpose specific DPLL device,
>> >> if
>> >> someone would want something similar we would have to review it,
>> >> right?
>> >
>> >We would if it was a Ethernet MAC PLL, but if someone wanted to expose
>> >whether some random PLL in their ASIC locks - are we adding a new type
>> >for each one of those?
>>
>> Yes, that was the implicit intention within those patches, if other
>> purpose
>> specific PLL would have to be present for whatever HW design and user
>> control over it would be required, then that would be the easiest to
>> maintain in the long term? Multiple types and each have own
>> function/purpose.
>>
>> It would be good as long as there is one PLL for a function per board,
>> once
>> there could be multiple ones for single function, we would have to add
>> some
>> enumeration (labels, etc.)
>
>Defer on adding identifiers. User knows which driver and bus device
>spawned the pll and more importantly what the pin topology is.
>Naming in the kernel is rarely a good idea.
Sure.
>
>> >> It depends, TX clock has one of external pins connected to external
>> >> DPLL,
>> >> but second is a board-level pin with ability to provide some external
>> >> clock signal, the user would have to determine that purpose just
>> >> based
>> >> on the topology of one of the pins, which seems a bit problematic?
>> >> I.e. if at some point there would be HW with only external non-DPLL
>> >> connected pins?
>> >
>> >Not sure I follow, TBH. To me the function of the "MAC PLL" is fairly
>> >obvious from the fact that it has a pin exposed via rtnetlink. So it's
>> >obviously a DPLL which can drive the Tx clock?
>>
>> I am lost a bit now too. You mean clock recovery pin? And EEC type dpll?
>> In this solution the 'MAC'/EEC is external and it doesn't drive TX
>> clocks
>> directly.
>
>MAC == "tspll" == TXC in this series. On Grzegorz's diagram the new PLL
>was in the MAC, which makes sense since it's a pll in the same ASIC as
>the MAC.
>
We wanted the TSPLL from the picture to be PPS type as it drives the PHC
timer within the MAC.
>I'm saying that the function of that pll is obvious since its pin will
>plug into the netdev / rtnetlink.
>
Yeah I got it, just saying it will work for now :)
>> >It's the function / relation / linking to the EEC DPLL that may not
>> >be obvious. But user can see how the pins connect they can get some
>> >LLM to draw a diagram of a live system.. et voila :)
>>
>> Yes, correct it would work for this particular HW, but adding a variant
>> without a external EEC-connected pin in the picture would be problematic
>> to understand 'generic' dpll purpose, pointing to the labels later.
>
>The function of the "MAC/tspll" is still obvious. The clarity of the
>external PLL is not helped by naming the "MAC/tspll".
>
>> Just to make it clear. I believe that generic type dpll could be used in
>> any HW and for any purpose, so after all each such usage could possibly
>> introduce entropy and confusion on the user side.
>>
>> But if you are fine with that, then sure, we can live with generic
>> purpose dpll.
>
>Considering all the imperfect options - generic / unnamed type would be
>my preference.
Ok, sounds good.
Thank you!
Arkadiusz
^ permalink raw reply
* RE: [PATCH 1/1] tipc: fix double-free in tipc_buf_append()
From: Tung Quang Nguyen @ 2026-04-20 14:49 UTC (permalink / raw)
To: Lee Jones
Cc: Jon Maloy, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, netdev@vger.kernel.org,
tipc-discussion@lists.sourceforge.net,
linux-kernel@vger.kernel.org
In-Reply-To: <20260420143309.GD3202366@google.com>
>> Subject: [PATCH 1/1] tipc: fix double-free in tipc_buf_append()
>> >
>> >The tipc_msg_validate() function can potentially reallocate the skb
>> >it is validating, freeing the old one. In tipc_buf_append(), it was
>> >being called with a pointer to a local variable which was a copy of the
>caller's skb pointer.
>> >
>> >If the skb was reallocated and validation subsequently failed, the
>> >error handling path would free the original skb pointer, which had
>> >already been freed, leading to double-free.
>> >
>> >Fix this by passing the caller's skb pointer-pointer directly to
>> >tipc_msg_validate(), ensuring any modification is reflected correctly.
>> >The local skb pointer is then updated from the (possibly modified)
>> >caller's pointer.
>> >
>> >Fixes: d618d09a68e4 ("tipc: enforce valid ratio between skb truesize
>> >and
>> >contents")
>> >Assisted-by: Gemini:gemini-3.1-pro-preview
>> >Signed-off-by: Lee Jones <lee@kernel.org>
>> >---
>> > net/tipc/msg.c | 3 ++-
>> > 1 file changed, 2 insertions(+), 1 deletion(-)
>> >
>> >diff --git a/net/tipc/msg.c b/net/tipc/msg.c index
>> >76284fc538eb..9f4f612ee027
>> >100644
>> >--- a/net/tipc/msg.c
>> >+++ b/net/tipc/msg.c
>> >@@ -177,8 +177,9 @@ int tipc_buf_append(struct sk_buff **headbuf,
>> >struct sk_buff **buf)
>> >
>> > if (fragid == LAST_FRAGMENT) {
>> > TIPC_SKB_CB(head)->validated = 0;
>> >- if (unlikely(!tipc_msg_validate(&head)))
>> >+ if (unlikely(!tipc_msg_validate(headbuf)))
>> > goto err;
>> >+ head = *headbuf;
>> This is a known issue and was reported via
>> https://patchwork.kernel.org/project/netdevbpf/patch/20260330205313.24
>> 33372-1-nicholas@carlini.com/ The author did not respond to my
>> comment.
>> Can you improve the fix by applying my patch?
>
>I'd be happy to make any required changes.
>
>However, is this approach superior to simply passing a reference?
>
>v1 appears to be simpler, easier to read and avoids the explanation.
>
As I explained, your fix adds extra overhead to normal path while the error path is corner case and it rarely happens.
Whatever approach is applied, we need to add explanation to understand more easily the logic and hidden trick in tipc_msg_validate().
>> diff --git a/net/tipc/msg.c b/net/tipc/msg.c index
>> 76284fc538eb..01a693559589 100644
>> --- a/net/tipc/msg.c
>> +++ b/net/tipc/msg.c
>> @@ -177,8 +177,19 @@ int tipc_buf_append(struct sk_buff **headbuf,
>> struct sk_buff **buf)
>>
>> if (fragid == LAST_FRAGMENT) {
>> TIPC_SKB_CB(head)->validated = 0;
>> - if (unlikely(!tipc_msg_validate(&head)))
>> + if (unlikely(!tipc_msg_validate(&head))) {
>> + /* reassembled skb has been freed in
>> + * tipc_msg_validate() because of invalid truesize.
>> + * head now points to newly-allocated reassembled skb
>> + * while *headbuf points to freed reassembled skb.
>> + * So, correct *headbuf for freeing newly-allocated
>> + * reassembled skb later.
>> + */
>> + if (head != *headbuf)
>> + *headbuf = head;
>> +
>> goto err;
>> + }
>> *buf = head;
>> TIPC_SKB_CB(head)->tail = NULL;
>> *headbuf = NULL;
>> > *buf = head;
>> > TIPC_SKB_CB(head)->tail = NULL;
>> > *headbuf = NULL;
>> >--
>> >2.54.0.rc1.513.gad8abe7a5a-goog
>> >
>>
>
>--
>Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v4 net] ax25: fix OOB read after address header strip in ax25_rcv()
From: Simon Horman @ 2026-04-20 14:30 UTC (permalink / raw)
To: ashutoshdesai993
Cc: 'Simon Horman', netdev, linux-hams, jreuter, davem,
edumazet, kuba, pabeni, stable, linux-kernel, david.laight.linux
In-Reply-To: <20260417065407.206499-1-ashutoshdesai993@gmail.com>
From: 'Simon Horman' <horms@kernel.org>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
---
ax25: fix OOB read after address header strip in ax25_rcv()
A crafted AX.25 frame with a valid address header but no control or PID
bytes causes skb->len to drop to zero after skb_pull() strips the
address header. The subsequent reads of skb->data[0] and skb->data[1]
are then out of bounds.
> diff --git a/net/ax25/ax25_in.c b/net/ax25/ax25_in.c
> index d75b3e9ed93de..d14ccebf9cdd5 100644
> --- a/net/ax25/ax25_in.c
> +++ b/net/ax25/ax25_in.c
> @@ -190,6 +190,9 @@ static int ax25_rcv(struct sk_buff *skb, struct net_device *dev,
> ax25_cb *ax25;
> ax25_dev *ax25_dev;
>
> + if (skb_linearize(skb))
> + goto free;
Could calling skb_linearize() before verifying if the device is configured for
AX.25 introduce a regression?
Since ax25_packet_type is registered globally, ax25_rcv() receives all
ETH_P_AX25 packets from any network interface. skb_linearize() performs
memory allocations to coalesce fragmented packets. By performing this before
checking if ax25_dev is NULL, could an attacker send fragmented ETH_P_AX25
packets to an unconfigured interface to force unnecessary memory allocation
and CPU cycles?
Should the skb_linearize() call be moved after the device configuration check?
> +
> /*
> * Process the AX.25/LAPB frame.
> */
[ ... ]
> @@ -217,6 +220,9 @@ static int ax25_rcv(struct sk_buff *skb, struct net_device *dev,
> */
> skb_pull(skb, ax25_addr_size(&dp));
>
> + if (skb->len < 2)
> + goto free;
Does this unconditionally drop all AX.25 LAPB control frames?
Standard AX.25 LAPB control frames (such as SABM, DISC, UA, DM, and RR)
consist solely of a 1-byte Control field and no PID byte. For these connection
management frames, skb->len is exactly 1 after the address header is pulled.
By discarding all frames shorter than 2 bytes, could this break the ability
to establish, acknowledge, or disconnect AX.25 connections?
Should the initial check only verify skb->len >= 1, and any requirement for
skb->len >= 2 be strictly scoped to the code paths that actually parse a PID
byte?
Also, if this skb->len < 2 check is relaxed, there is a pre-existing
out-of-bounds read in ax25_decode() for extended modulus frames.
If a malformed 1-byte frame is received on an extended modulus (AX25_EMODULUS)
connection, ax25_decode() unconditionally reads skb->data[1] for I-frames and
S-frames. It then calls skb_pull(skb, 2) but ignores the return value. Should
ax25_decode() validate that skb->len >= 2 before parsing the second control
byte for extended modulus frames?
Finally, there appears to be a pre-existing use-after-free and list corruption
in the ax25_rcv() error path when allocating memory for ax25->digipeat.
When handling an incoming connection request for a listener socket, the code
physically links the skb into the listener socket's receive queue via
skb_queue_head(&sk->sk_receive_queue, skb). Shortly after, it attempts to
allocate memory. If this allocation fails, the error path explicitly calls
kfree_skb(skb).
However, it fails to unlink the skb from sk->sk_receive_queue. (The subsequent
call to ax25_destroy_socket() flushes the newly created socket's queue, not
the listener socket's queue). This leaves a freed skb in the listener socket's
queue. When a user process later calls accept(), will it dequeue and
dereference the freed skb, resulting in a use-after-free?
^ permalink raw reply
* Re: [RFC Patch net-next v1 8/9] r8169: move struct ethtool_ops
From: Andrew Lunn @ 2026-04-20 14:33 UTC (permalink / raw)
To: javen
Cc: hkallweit1, nic_swsd, andrew+netdev, davem, edumazet, kuba,
pabeni, horms, netdev, linux-kernel
In-Reply-To: <20260420021957.1756-9-javen_xu@realsil.com.cn>
On Mon, Apr 20, 2026 at 10:19:56AM +0800, javen wrote:
> From: Javen Xu <javen_xu@realsil.com.cn>
>
> This patch move struct ethtool_ops, no changes. Prepare for next patch.
Commit messages are all about "Why?". You normally move code because a
local function is after where it will be called from. I assume your
next patch is going to add a function which will be listed in the
ethtool ops, and it calls a function which is currently after the
ethtool ops. Please name names.
Andrew
---
pw-bot: cr
^ permalink raw reply
* Re: [PATCH 1/1] tipc: fix double-free in tipc_buf_append()
From: Lee Jones @ 2026-04-20 14:33 UTC (permalink / raw)
To: Tung Quang Nguyen
Cc: Jon Maloy, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, netdev@vger.kernel.org,
tipc-discussion@lists.sourceforge.net,
linux-kernel@vger.kernel.org
In-Reply-To: <GV1P189MB19886E03BDD0F407B757E5ABC62F2@GV1P189MB1988.EURP189.PROD.OUTLOOK.COM>
On Mon, 20 Apr 2026, Tung Quang Nguyen wrote:
> Subject: [PATCH 1/1] tipc: fix double-free in tipc_buf_append()
> >
> >The tipc_msg_validate() function can potentially reallocate the skb it is
> >validating, freeing the old one. In tipc_buf_append(), it was being called with a
> >pointer to a local variable which was a copy of the caller's skb pointer.
> >
> >If the skb was reallocated and validation subsequently failed, the error
> >handling path would free the original skb pointer, which had already been
> >freed, leading to double-free.
> >
> >Fix this by passing the caller's skb pointer-pointer directly to
> >tipc_msg_validate(), ensuring any modification is reflected correctly.
> >The local skb pointer is then updated from the (possibly modified) caller's
> >pointer.
> >
> >Fixes: d618d09a68e4 ("tipc: enforce valid ratio between skb truesize and
> >contents")
> >Assisted-by: Gemini:gemini-3.1-pro-preview
> >Signed-off-by: Lee Jones <lee@kernel.org>
> >---
> > net/tipc/msg.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> >diff --git a/net/tipc/msg.c b/net/tipc/msg.c index 76284fc538eb..9f4f612ee027
> >100644
> >--- a/net/tipc/msg.c
> >+++ b/net/tipc/msg.c
> >@@ -177,8 +177,9 @@ int tipc_buf_append(struct sk_buff **headbuf, struct
> >sk_buff **buf)
> >
> > if (fragid == LAST_FRAGMENT) {
> > TIPC_SKB_CB(head)->validated = 0;
> >- if (unlikely(!tipc_msg_validate(&head)))
> >+ if (unlikely(!tipc_msg_validate(headbuf)))
> > goto err;
> >+ head = *headbuf;
> This is a known issue and was reported via https://patchwork.kernel.org/project/netdevbpf/patch/20260330205313.2433372-1-nicholas@carlini.com/
> The author did not respond to my comment.
> Can you improve the fix by applying my patch?
I'd be happy to make any required changes.
However, is this approach superior to simply passing a reference?
v1 appears to be simpler, easier to read and avoids the explanation.
> diff --git a/net/tipc/msg.c b/net/tipc/msg.c
> index 76284fc538eb..01a693559589 100644
> --- a/net/tipc/msg.c
> +++ b/net/tipc/msg.c
> @@ -177,8 +177,19 @@ int tipc_buf_append(struct sk_buff **headbuf, struct sk_buff **buf)
>
> if (fragid == LAST_FRAGMENT) {
> TIPC_SKB_CB(head)->validated = 0;
> - if (unlikely(!tipc_msg_validate(&head)))
> + if (unlikely(!tipc_msg_validate(&head))) {
> + /* reassembled skb has been freed in
> + * tipc_msg_validate() because of invalid truesize.
> + * head now points to newly-allocated reassembled skb
> + * while *headbuf points to freed reassembled skb.
> + * So, correct *headbuf for freeing newly-allocated
> + * reassembled skb later.
> + */
> + if (head != *headbuf)
> + *headbuf = head;
> +
> goto err;
> + }
> *buf = head;
> TIPC_SKB_CB(head)->tail = NULL;
> *headbuf = NULL;
> > *buf = head;
> > TIPC_SKB_CB(head)->tail = NULL;
> > *headbuf = NULL;
> >--
> >2.54.0.rc1.513.gad8abe7a5a-goog
> >
>
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH RFC bpf-next 1/8] kasan: expose generic kasan helpers
From: Alexis Lothoré @ 2026-04-20 14:27 UTC (permalink / raw)
To: Alexei Starovoitov, Andrey Konovalov
Cc: Alexis Lothoré, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Jiri Olsa,
John Fastabend, David S. Miller, David Ahern, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, X86 ML, H. Peter Anvin,
Shuah Khan, Maxime Coquelin, Alexandre Torgue, Andrey Ryabinin,
Alexander Potapenko, Dmitry Vyukov, Vincenzo Frascino,
Andrew Morton, ebpf, Bastien Curutchet, Thomas Petazzoni,
Xu Kuohai, bpf, LKML, Network Development,
open list:KERNEL SELFTEST FRAMEWORK, linux-stm32,
linux-arm-kernel, kasan-dev, linux-mm
In-Reply-To: <CAADnVQKuptG_opA12O=Xb9_+cHf3f=ycAZdfUp17P2HBYQzdsg@mail.gmail.com>
On Mon Apr 20, 2026 at 12:51 AM CEST, Alexei Starovoitov wrote:
> On Sun, Apr 19, 2026 at 2:49 PM Andrey Konovalov <andreyknvl@gmail.com> wrote:
>>
>> On Tue, Apr 14, 2026 at 5:58 PM Alexei Starovoitov
>> <alexei.starovoitov@gmail.com> wrote:
>> >
>> > I think we're talking past each other.
>> > We're not interested in KASAN_SW_TAGS or KASAN_HW_TAGS.
>> > We're not going to modify arm64 JIT at all.
>> >
>> > This is purely KASAN_GENRIC and only on x86-64.
>> > JIT will emit exactly what compilers emit for generic
>> > which is __asan_load/store. This is as stable ABI as it can get
>> > and we don't want to deviate from it.
>>
>> OK, I supposed that's fair. You did throw me off point with your
>> performance comment. But if you decide to add SW_TAGS support at some
>> point, I think this discussion needs to be revisited.
>>
>> But please add a comment saying that those functions are only exposed
>> for BPF JIT and they are not supposed to be used by other parts of the
>> kernel. And in case you do end up adding a new config option, guard
>> the public declarations by a corresponding ifdef.
>
> I feel concerns of misuse are overblown.
> Being in include/linux/kasan.h doesn't make them free-for-all
> all of a sudden, but if you prefer we can just copy paste:
> +void __asan_load1(void *p);
> +void __asan_store1(void *p);
> into bpf_jit_comp.c
That's actually what I initially went with when working on this, but it
did look a bit fragile, and suspected that I would rather be asked to export
them properly through a dedicated header. I'm fine with putting back the
manual declarations in jit comp, though.
>
>> > The goal here is to find bugs in the verifier.
>> > If something got past it, that shouldn't have,
>> > kasan generic on x86-64 is enough.
>>
>> FWIW, I suspect HW_TAGS KASAN already just works with JITed BPF code.
>
> Ohh. Good point. Looks like modern arm64 cpus in public clouds
> don't have that enabled, so one would need pixel phone to
> catch verifier bugs via hw_tags.
> So we still need this x86-specific jit kasan.
> I guess eventually it can be removed when hw_tags support is widespread.
--
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v3] net: phy: air_en8811h: add AN8811HB MCU assert/deassert support
From: Bjørn Mork @ 2026-04-20 14:25 UTC (permalink / raw)
To: Lucien.Jheng
Cc: andrew, hkallweit1, linux, davem, edumazet, kuba, pabeni, netdev,
linux-kernel, ericwouds, frank-w, daniel, lucien.jheng,
albert-al.lee
In-Reply-To: <20260420134506.35164-1-lucienzx159@gmail.com>
"Lucien.Jheng" <lucienzx159@gmail.com> writes:
> AN8811HB needs a MCU soft-reset cycle before firmware loading begins.
Sorry for having missed that. I assume it explains a rare issue I've
observed where a link down/up sometimes was necessary after a cold boot.
I've been running with your v2 patch for a while, and cannot reproduce
this issue anymore.
Tested-by: Bjørn Mork <bjorn@mork.no>
^ permalink raw reply
* Re: [PATCH net v4 0/2] net: airoha: Fix airoha_qdma_cleanup_tx_queue() processing
From: Simon Horman @ 2026-04-20 13:56 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260417-airoha_qdma_cleanup_tx_queue-fix-net-v4-0-e04bcc2c9642@kernel.org>
On Fri, Apr 17, 2026 at 08:36:30AM +0200, Lorenzo Bianconi wrote:
> Add missing bits in airoha_qdma_cleanup_tx_queue routine.
> Fix airoha_qdma_cleanup_tx_queue processing errors intorduced in commit
> '3f47e67dff1f7 ("net: airoha: Add the capability to consume out-of-order
> DMA tx descriptors")'.
>
> ---
> Changes in v4:
> - Drop patch 2/3 to move entries to queue head in case of DMA mapping
> failure in airoha_dev_xmit().
> - Link to v3: https://lore.kernel.org/r/20260416-airoha_qdma_cleanup_tx_queue-fix-net-v3-0-2b69f5788580@kernel.org
>
> Changes in v3:
> - Move ndesc initialization fix in a dedicated patch.
> - Add patch 2/3 to move entries to queue head in case of DMA mapping
> failure in airoha_dev_xmit().
> - Cosmetics.
> - Link to v2: https://lore.kernel.org/r/20260414-airoha_qdma_cleanup_tx_queue-fix-net-v2-1-875de57cc022@kernel.org
>
> Changes in v2:
> - Move q->ndesc initialization at end of airoha_qdma_init_tx routine in
> order to avoid any possible NULL pointer dereference in
> airoha_qdma_cleanup_tx_queue()
> - Check if q->tx_list is empty in airoha_qdma_cleanup_tx_queue()
> - Link to v1: https://lore.kernel.org/r/20260410-airoha_qdma_cleanup_tx_queue-fix-net-v1-1-b7171c8f1e78@kernel.org
>
> ---
> Lorenzo Bianconi (2):
> net: airoha: Move ndesc initialization at end of airoha_qdma_init_tx()
> net: airoha: Add missing bits in airoha_qdma_cleanup_tx_queue()
>
> drivers/net/ethernet/airoha/airoha_eth.c | 40 +++++++++++++++++++++++++++-----
> 1 file changed, 34 insertions(+), 6 deletions(-)
Thanks for the updates, this series looks good to me:
Reviewed-by: Simon Horman <horms@kernel.org>
As is the way of things, Sashiko has some feedback on this patchset.
Please consider looking over it for potential follow-up changes.
I do not think that needs to block progress of this patchset.
^ permalink raw reply
* RE: [PATCH 1/1] tipc: fix double-free in tipc_buf_append()
From: Tung Quang Nguyen @ 2026-04-20 13:46 UTC (permalink / raw)
To: Lee Jones
Cc: Jon Maloy, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, netdev@vger.kernel.org,
tipc-discussion@lists.sourceforge.net,
linux-kernel@vger.kernel.org
In-Reply-To: <20260420130524.3527420-1-lee@kernel.org>
Subject: [PATCH 1/1] tipc: fix double-free in tipc_buf_append()
>
>The tipc_msg_validate() function can potentially reallocate the skb it is
>validating, freeing the old one. In tipc_buf_append(), it was being called with a
>pointer to a local variable which was a copy of the caller's skb pointer.
>
>If the skb was reallocated and validation subsequently failed, the error
>handling path would free the original skb pointer, which had already been
>freed, leading to double-free.
>
>Fix this by passing the caller's skb pointer-pointer directly to
>tipc_msg_validate(), ensuring any modification is reflected correctly.
>The local skb pointer is then updated from the (possibly modified) caller's
>pointer.
>
>Fixes: d618d09a68e4 ("tipc: enforce valid ratio between skb truesize and
>contents")
>Assisted-by: Gemini:gemini-3.1-pro-preview
>Signed-off-by: Lee Jones <lee@kernel.org>
>---
> net/tipc/msg.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
>diff --git a/net/tipc/msg.c b/net/tipc/msg.c index 76284fc538eb..9f4f612ee027
>100644
>--- a/net/tipc/msg.c
>+++ b/net/tipc/msg.c
>@@ -177,8 +177,9 @@ int tipc_buf_append(struct sk_buff **headbuf, struct
>sk_buff **buf)
>
> if (fragid == LAST_FRAGMENT) {
> TIPC_SKB_CB(head)->validated = 0;
>- if (unlikely(!tipc_msg_validate(&head)))
>+ if (unlikely(!tipc_msg_validate(headbuf)))
> goto err;
>+ head = *headbuf;
This is a known issue and was reported via https://patchwork.kernel.org/project/netdevbpf/patch/20260330205313.2433372-1-nicholas@carlini.com/
The author did not respond to my comment.
Can you improve the fix by applying my patch?
diff --git a/net/tipc/msg.c b/net/tipc/msg.c
index 76284fc538eb..01a693559589 100644
--- a/net/tipc/msg.c
+++ b/net/tipc/msg.c
@@ -177,8 +177,19 @@ int tipc_buf_append(struct sk_buff **headbuf, struct sk_buff **buf)
if (fragid == LAST_FRAGMENT) {
TIPC_SKB_CB(head)->validated = 0;
- if (unlikely(!tipc_msg_validate(&head)))
+ if (unlikely(!tipc_msg_validate(&head))) {
+ /* reassembled skb has been freed in
+ * tipc_msg_validate() because of invalid truesize.
+ * head now points to newly-allocated reassembled skb
+ * while *headbuf points to freed reassembled skb.
+ * So, correct *headbuf for freeing newly-allocated
+ * reassembled skb later.
+ */
+ if (head != *headbuf)
+ *headbuf = head;
+
goto err;
+ }
*buf = head;
TIPC_SKB_CB(head)->tail = NULL;
*headbuf = NULL;
> *buf = head;
> TIPC_SKB_CB(head)->tail = NULL;
> *headbuf = NULL;
>--
>2.54.0.rc1.513.gad8abe7a5a-goog
>
^ permalink raw reply related
* [PATCH v3] net: phy: air_en8811h: add AN8811HB MCU assert/deassert support
From: Lucien.Jheng @ 2026-04-20 13:45 UTC (permalink / raw)
To: andrew, hkallweit1, linux, davem, edumazet, kuba, pabeni, netdev,
linux-kernel, bjorn
Cc: ericwouds, frank-w, daniel, lucien.jheng, albert-al.lee,
Lucien.Jheng
AN8811HB needs a MCU soft-reset cycle before firmware loading begins.
Assert the MCU (hold it in reset) and immediately deassert (release)
via a dedicated PBUS register pair (0x5cf9f8 / 0x5cf9fc), accessed
through a registered mdio_device at PHY-addr+8.
Add __air_pbus_reg_write() as a low-level helper taking a struct
mdio_device *, create and register the PBUS mdio_device in
an8811hb_probe() and store it in priv->pbusdev, then implement
an8811hb_mcu_assert() / _deassert() on top of it. Add
an8811hb_remove() to unregister the PBUS device on teardown. Wire
both calls into an8811hb_load_firmware() and en8811h_restart_mcu()
so every firmware load or MCU restart on AN8811HB correctly sequences
the reset control registers.
Fixes: 0a55766b7711 ("net: phy: air_en8811h: add Airoha AN8811HB support")
Signed-off-by: Lucien Jheng <lucienzx159@gmail.com>
---
Changes in v3:
- Register a dedicated mdio_device for the PBUS node (addr+8) in
an8811hb_probe() and store it in priv->pbusdev, replacing the
inline addr+8 computation in v2.
- Change __air_pbus_reg_write() to take struct mdio_device * instead
of struct phy_device *.
- Add an8811hb_remove() to unregister and free the PBUS device.
- Fix error handling in an8811hb_probe() with goto error paths to
ensure the PBUS device is always cleaned up on failure.
drivers/net/phy/air_en8811h.c | 142 +++++++++++++++++++++++++++++++++-
1 file changed, 138 insertions(+), 4 deletions(-)
diff --git a/drivers/net/phy/air_en8811h.c b/drivers/net/phy/air_en8811h.c
index 29ae73e65..1fe2d8bec 100644
--- a/drivers/net/phy/air_en8811h.c
+++ b/drivers/net/phy/air_en8811h.c
@@ -170,9 +170,21 @@
#define AN8811HB_CLK_DRV_CKO_LDPWD BIT(13)
#define AN8811HB_CLK_DRV_CKO_LPPWD BIT(14)
+#define AN8811HB_MCU_SW_RST 0x5cf9f8
+#define AN8811HB_MCU_SW_RST_HOLD BIT(16)
+#define AN8811HB_MCU_SW_RST_RUN (BIT(16) | BIT(0))
+#define AN8811HB_MCU_SW_START 0x5cf9fc
+#define AN8811HB_MCU_SW_START_EN BIT(16)
+
+/* MII register constants for PBUS access (PHY addr + 8) */
+#define AIR_PBUS_ADDR_HIGH 0x1c
+#define AIR_PBUS_DATA_HIGH 0x10
+
/* Led definitions */
#define EN8811H_LED_COUNT 3
+#define EN8811H_PBUS_ADDR_OFFS 8
+
/* Default LED setup:
* GPIO5 <-> LED0 On: Link detected, blink Rx/Tx
* GPIO4 <-> LED1 On: Link detected at 2500 or 1000 Mbps
@@ -201,6 +213,7 @@ struct en8811h_priv {
struct clk_hw hw;
struct phy_device *phydev;
unsigned int cko_is_enabled;
+ struct mdio_device *pbusdev;
};
enum {
@@ -254,6 +267,31 @@ static int air_phy_write_page(struct phy_device *phydev, int page)
return __phy_write(phydev, AIR_EXT_PAGE_ACCESS, page);
}
+static int __air_pbus_reg_write(struct mdio_device *mdiodev,
+ u32 pbus_reg, u32 pbus_data)
+{
+ int ret;
+
+ ret = __mdiobus_write(mdiodev->bus, mdiodev->addr, AIR_EXT_PAGE_ACCESS,
+ upper_16_bits(pbus_reg));
+ if (ret < 0)
+ return ret;
+
+ ret = __mdiobus_write(mdiodev->bus, mdiodev->addr, AIR_PBUS_ADDR_HIGH,
+ (pbus_reg & GENMASK(15, 6)) >> 6);
+ if (ret < 0)
+ return ret;
+
+ ret = __mdiobus_write(mdiodev->bus, mdiodev->addr,
+ (pbus_reg & GENMASK(5, 2)) >> 2,
+ lower_16_bits(pbus_data));
+ if (ret < 0)
+ return ret;
+
+ return __mdiobus_write(mdiodev->bus, mdiodev->addr, AIR_PBUS_DATA_HIGH,
+ upper_16_bits(pbus_data));
+}
+
static int __air_buckpbus_reg_write(struct phy_device *phydev,
u32 pbus_address, u32 pbus_data)
{
@@ -570,10 +608,67 @@ static int an8811hb_load_file(struct phy_device *phydev, const char *name,
return ret;
}
+static int an8811hb_mcu_assert(struct phy_device *phydev)
+{
+ struct en8811h_priv *priv = phydev->priv;
+ int ret;
+
+ phy_lock_mdio_bus(phydev);
+
+ ret = __air_pbus_reg_write(priv->pbusdev, AN8811HB_MCU_SW_RST,
+ AN8811HB_MCU_SW_RST_HOLD);
+ if (ret < 0)
+ goto unlock;
+
+ ret = __air_pbus_reg_write(priv->pbusdev, AN8811HB_MCU_SW_START, 0);
+ if (ret < 0)
+ goto unlock;
+
+ msleep(50);
+ phydev_dbg(phydev, "MCU asserted\n");
+
+unlock:
+ phy_unlock_mdio_bus(phydev);
+ return ret;
+}
+
+static int an8811hb_mcu_deassert(struct phy_device *phydev)
+{
+ struct en8811h_priv *priv = phydev->priv;
+ int ret;
+
+ phy_lock_mdio_bus(phydev);
+
+ ret = __air_pbus_reg_write(priv->pbusdev, AN8811HB_MCU_SW_START,
+ AN8811HB_MCU_SW_START_EN);
+ if (ret < 0)
+ goto unlock;
+
+ ret = __air_pbus_reg_write(priv->pbusdev, AN8811HB_MCU_SW_RST,
+ AN8811HB_MCU_SW_RST_RUN);
+ if (ret < 0)
+ goto unlock;
+
+ msleep(50);
+ phydev_dbg(phydev, "MCU deasserted\n");
+
+unlock:
+ phy_unlock_mdio_bus(phydev);
+ return ret;
+}
+
static int an8811hb_load_firmware(struct phy_device *phydev)
{
int ret;
+ ret = an8811hb_mcu_assert(phydev);
+ if (ret < 0)
+ return ret;
+
+ ret = an8811hb_mcu_deassert(phydev);
+ if (ret < 0)
+ return ret;
+
ret = air_buckpbus_reg_write(phydev, EN8811H_FW_CTRL_1,
EN8811H_FW_CTRL_1_START);
if (ret < 0)
@@ -662,6 +757,16 @@ static int en8811h_restart_mcu(struct phy_device *phydev)
{
int ret;
+ if (phy_id_compare_model(phydev->phy_id, AN8811HB_PHY_ID)) {
+ ret = an8811hb_mcu_assert(phydev);
+ if (ret < 0)
+ return ret;
+
+ ret = an8811hb_mcu_deassert(phydev);
+ if (ret < 0)
+ return ret;
+ }
+
ret = air_buckpbus_reg_write(phydev, EN8811H_FW_CTRL_1,
EN8811H_FW_CTRL_1_START);
if (ret < 0)
@@ -1166,6 +1271,7 @@ static int en8811h_leds_setup(struct phy_device *phydev)
static int an8811hb_probe(struct phy_device *phydev)
{
+ struct mdio_device *mdiodev;
struct en8811h_priv *priv;
int ret;
@@ -1175,10 +1281,22 @@ static int an8811hb_probe(struct phy_device *phydev)
return -ENOMEM;
phydev->priv = priv;
+ mdiodev = mdio_device_create(phydev->mdio.bus,
+ phydev->mdio.addr + EN8811H_PBUS_ADDR_OFFS);
+ if (IS_ERR(mdiodev))
+ return PTR_ERR(mdiodev);
+
+ ret = mdio_device_register(mdiodev);
+ if (ret) {
+ mdio_device_free(mdiodev);
+ return ret;
+ }
+ priv->pbusdev = mdiodev;
+
ret = an8811hb_load_firmware(phydev);
if (ret < 0) {
phydev_err(phydev, "Load firmware failed: %d\n", ret);
- return ret;
+ goto error;
}
en8811h_print_fw_version(phydev);
@@ -1191,22 +1309,27 @@ static int an8811hb_probe(struct phy_device *phydev)
ret = en8811h_leds_setup(phydev);
if (ret < 0)
- return ret;
+ goto error;
priv->phydev = phydev;
/* Co-Clock Output */
ret = an8811hb_clk_provider_setup(&phydev->mdio.dev, &priv->hw);
if (ret)
- return ret;
+ goto error;
/* Configure led gpio pins as output */
ret = air_buckpbus_reg_modify(phydev, AN8811HB_GPIO_OUTPUT,
AN8811HB_GPIO_OUTPUT_345,
AN8811HB_GPIO_OUTPUT_345);
if (ret < 0)
- return ret;
+ goto error;
return 0;
+
+error:
+ mdio_device_remove(priv->pbusdev);
+ mdio_device_free(priv->pbusdev);
+ return ret;
}
static int en8811h_probe(struct phy_device *phydev)
@@ -1561,6 +1684,16 @@ static int en8811h_suspend(struct phy_device *phydev)
return genphy_suspend(phydev);
}
+static void an8811hb_remove(struct phy_device *phydev)
+{
+ struct en8811h_priv *priv = phydev->priv;
+
+ if (priv->pbusdev) {
+ mdio_device_remove(priv->pbusdev);
+ mdio_device_free(priv->pbusdev);
+ }
+}
+
static struct phy_driver en8811h_driver[] = {
{
PHY_ID_MATCH_MODEL(EN8811H_PHY_ID),
@@ -1587,6 +1720,7 @@ static struct phy_driver en8811h_driver[] = {
PHY_ID_MATCH_MODEL(AN8811HB_PHY_ID),
.name = "Airoha AN8811HB",
.probe = an8811hb_probe,
+ .remove = an8811hb_remove,
.get_features = en8811h_get_features,
.config_init = an8811hb_config_init,
.get_rate_matching = en8811h_get_rate_matching,
--
2.34.1
^ permalink raw reply related
* Re: Question/proposal for DPLL NCO (DCO) mode
From: Jiri Pirko @ 2026-04-20 13:43 UTC (permalink / raw)
To: Ivan Vecera
Cc: netdev@vger.kernel.org, Arkadiusz Kubalewski, Vadim Fedorenko,
Jakub Kicinski
In-Reply-To: <21cce17b-9a79-41b5-8363-faee2378aa37@redhat.com>
Mon, Apr 20, 2026 at 01:42:29PM +0200, ivecera@redhat.com wrote:
>Hi all,
>
>I am currently working on adding PTP clock support (PHC) to the ZL3073x
>driver, and I would like to discuss an architectural addition to the
>DPLL subsystem enum dpll_mode before sending the formal patch series.
>
>To support IEEE 1588 PTP, the hardware DPLL must be decoupled from
>tracking physical reference pins. Instead, its output frequency needs to
>be continuously steered by a software PTP stack (e.g., linuxptp) using
>the .adjfine() callback. In the industry, this specific hardware state
>is widely known as NCO (Numerically Controlled Oscillator) or DCO
>(Digitally Controlled Oscillator) mode.
>
>Currently, the DPLL subsystem defines two modes in enum dpll_mode:
>
>MANUAL: The user explicitly selects a physical input pin to track.
>
>AUTOMATIC: The hardware automatically selects the best physical input pin
>based on priorities.
>
>Neither of these accurately represents the NCO/DCO state, where physical
>pins are ignored, and the loop is fully software-steered.
The manual/automatic mode is defining strategy/behaviour about how the
input pins are selected.
<header_quote>
* enum dpll_mode - working modes a dpll can support, differentiates if and how
* dpll selects one of its inputs to syntonize with it
</header_quote>
You don't want to change the strategy. You just
don't want that/don't care. Why it make sense to add a mode then?
I was thinking exposing this over STATUS. We have:
UNLOCKED (free running)
LOCKED
LOCKED_HO_ACQ
HOLDOVER
So something maybe like SW_STEERED? But:
The problem is you need to do selection. Perhaps we can have a
"magic pin" to select for this :S ? We have pin of type
DPLL_PIN_TYPE_INT_OSCILLATOR already. Perhaps we can have
DPLL_PIN_TYPE_INT_NCO/NDO? It's a source.
Makes sense?
>
>Without a dedicated mode, drivers are forced into "automagic"
>workarounds. A driver might implicitly switch the hardware to NCO mode
>in the background as soon as .adjfine() is called, while misreporting
>its mode as MANUAL to the DPLL subsystem.
>
>I strongly believe this hidden "automagic" behavior is a bad design. The
>user-space should have full visibility and explicit control over what
>the DPLL state machine is actually doing.
>
>The Proposal:
>I would like to propose adding a new mode: DPLL_MODE_NCO (or
>DPLL_MODE_DCO, I am open to suggestions regarding the terminology).
>
>The expected workflow would be explicit:
>If a user wants to actively steer the DPLL frequency via software (for
>PTP or other Time-over-Packet applications), they must explicitly set
>the DPLL device to this mode via Netlink first. Only then will the
>hardware accept frequency adjustments via .adjfine().
>
>I would appreciate any feedback from the DPLL subsystem maintainers and
>the community on this approach.
>
>Thanks,
>Ivan
>
^ permalink raw reply
* [PATCH RFC nf-next] netfilter: flowtable_offload: propagate CT mark to hardware offload path
From: Lorenzo Bianconi @ 2026-04-20 13:39 UTC (permalink / raw)
To: Pablo Neira Ayuso, Florian Westphal, Phil Sutter, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman
Cc: netfilter-devel, coreteam, netdev, Lorenzo Bianconi
When a user-space process sets the Connection Tracking (CT) mark on a
flow via nft_ct or xt_CONNMARK, that mark should be visible to the
hardware offload path when the flow is accelerated through the flowtable
infrastructure.
Extend the flowtable offload attribute set to include the ct mark field
when it has been explicitly set on the conntrack entry.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
net/netfilter/nf_flow_table_offload.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/net/netfilter/nf_flow_table_offload.c b/net/netfilter/nf_flow_table_offload.c
index 002ec15d988b..d5fe35b1a647 100644
--- a/net/netfilter/nf_flow_table_offload.c
+++ b/net/netfilter/nf_flow_table_offload.c
@@ -679,6 +679,22 @@ static int flow_offload_decap_tunnel(const struct flow_offload *flow,
return 0;
}
+static void nf_flow_rule_ct_meta_mark(const struct flow_offload *flow,
+ struct nf_flow_rule *flow_rule)
+{
+#if IS_ENABLED(CONFIG_NF_CONNTRACK_MARK)
+ u32 mark = flow->ct ? READ_ONCE(flow->ct->mark) : 0;
+
+ if (mark) {
+ struct flow_action_entry *entry;
+
+ entry = flow_action_entry_next(flow_rule);
+ entry->id = FLOW_ACTION_CT_METADATA;
+ entry->ct_metadata.mark = mark;
+ }
+#endif /* IS_ENABLED(CONFIG_NF_CONNTRACK_MARK) */
+}
+
static int
nf_flow_rule_route_common(struct net *net, const struct flow_offload *flow,
enum flow_offload_tuple_dir dir,
@@ -747,6 +763,8 @@ int nf_flow_rule_route_ipv4(struct net *net, struct flow_offload *flow,
if (nf_flow_rule_route_common(net, flow, dir, flow_rule) < 0)
return -1;
+ nf_flow_rule_ct_meta_mark(flow, flow_rule);
+
if (test_bit(NF_FLOW_SNAT, &flow->flags)) {
if (flow_offload_ipv4_snat(net, flow, dir, flow_rule) < 0 ||
flow_offload_port_snat(net, flow, dir, flow_rule) < 0)
@@ -776,6 +794,8 @@ int nf_flow_rule_route_ipv6(struct net *net, struct flow_offload *flow,
if (nf_flow_rule_route_common(net, flow, dir, flow_rule) < 0)
return -1;
+ nf_flow_rule_ct_meta_mark(flow, flow_rule);
+
if (test_bit(NF_FLOW_SNAT, &flow->flags)) {
if (flow_offload_ipv6_snat(net, flow, dir, flow_rule) < 0 ||
flow_offload_port_snat(net, flow, dir, flow_rule) < 0)
---
base-commit: 3f3a2aefbc661b837c8e344f944982d61c2ae037
change-id: 20260420-nft-flowtable-priority-6eef902d255a
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* Re: [net-next v2 3/5] dt-bindings: net: starfive,jh7110-dwmac: Add JHB100 sgmii rx clk
From: Rob Herring @ 2026-04-20 13:39 UTC (permalink / raw)
To: Minda Chen
Cc: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Krzysztof Kozlowski, Conor Dooley, netdev,
linux-kernel, linux-stm32, devicetree
In-Reply-To: <20260417024523.107786-4-minda.chen@starfivetech.com>
On Fri, Apr 17, 2026 at 10:45:21AM +0800, Minda Chen wrote:
> JHB100 SGMII interface tx/rx mac clock is split and require to
> set clock rate in 10M/100M/1000M speed. So dts need to add a
> new rx clock in code, dts and dt binding doc.
>
> Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
> ---
> .../bindings/net/starfive,jh7110-dwmac.yaml | 42 ++++++++++++++++---
> 1 file changed, 36 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> index edc246a71ce3..3802cdbf1848 100644
> --- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> +++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> @@ -39,20 +39,26 @@ properties:
> maxItems: 1
>
> clocks:
> + minItems: 5
> items:
> - description: GMAC main clock
> - description: GMAC AHB clock
> - description: PTP clock
> - description: TX clock
> - description: GTX clock
> + - description: SGMII RX clock
>
> clock-names:
> - items:
> - - const: stmmaceth
> - - const: pclk
> - - const: ptp_ref
> - - const: tx
> - - const: gtx
> + minItems: 5
> + maxItems: 6
> + contains:
> + enum:
> + - stmmaceth
> + - pclk
> + - ptp_ref
> + - tx
> + - gtx
> + - sgmii_rx
No, this allows any of the above strings plus any other random strings.
Rob
^ permalink raw reply
* Re: [PATCH v5] net: caif: fix stack out-of-bounds write in cfctrl_link_setup()
From: Kangzheng Gu @ 2026-04-20 13:38 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Simon Horman, Paolo Abeni, David S . Miller, Eric Dumazet,
Jakub Kicinski, Kees Cook, Thorsten Blum, sjur.brandeland, Netdev,
linux-kernel, stable
In-Reply-To: <85ec14af-bdd5-45ea-8c06-ebd769499bd1@app.fastmail.com>
Ok, I would like to wait. I am just researching for security.
Arnd Bergmann <arnd@arndb.de> 于2026年4月20日周一 16:14写道：
>
> On Mon, Apr 20, 2026, at 10:09, Kangzheng Gu wrote:
> > Thanks for all of your advice, I am preparing a new version of patch now.
>
> If you are actively using CAIF, please chime in at
>
> https://lore.kernel.org/all/20260416182829.1440262-1-kuba@kernel.org/
>
> If you are not actually using CAIF, maybe wait a little bit before
> spending more time on it because the patches may no longer
> apply if it gets removed due to lack of users.
>
> Arnd
^ permalink raw reply
* Re: [PATCH] docs: maintainer-netdev: fix typo in "targeting"
From: Breno Leitao @ 2026-04-20 13:35 UTC (permalink / raw)
To: Ariful Islam Shoikot; +Cc: netdev, linux-doc, workflows, linux-kernel
In-Reply-To: <20260420114554.1026-1-islamarifulshoikat@gmail.com>
On Mon, Apr 20, 2026 at 05:45:53PM +0600, Ariful Islam Shoikot wrote:
> Fix spelling mistake "targgeting" -> "targeting" in
> maintainer-netdev.rst
>
> No functional change.
>
> Signed-off-by: Ariful Islam Shoikot <islamarifulshoikat@gmail.com>
Reviewed-by: Breno Leitao <leitao@debian.org>
^ permalink raw reply
* Re: [PATCH AUTOSEL 7.0] dsa: tag_mxl862xx: set dsa_default_offload_fwd_mark()
From: Daniel Golle @ 2026-04-20 13:34 UTC (permalink / raw)
To: Sasha Levin
Cc: patches, stable, Jakub Kicinski, andrew, olteanv, davem, edumazet,
pabeni, netdev, linux-kernel
In-Reply-To: <20260420132314.1023554-153-sashal@kernel.org>
On Mon, Apr 20, 2026 at 09:19:07AM -0400, Sasha Levin wrote:
> From: Daniel Golle <daniel@makrotopia.org>
>
> [ Upstream commit 4250ff1640ea1ede99bfe02ca949acbcc6c0927f ]
>
> The MxL862xx offloads bridge forwarding in hardware, so set
> dsa_default_offload_fwd_mark() to avoid duplicate forwarding of
> packets of (eg. flooded) frames arriving at the CPU port.
>
> Link-local frames are directly trapped to the CPU port only, so don't
> set dsa_default_offload_fwd_mark() on those.
>
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> Link: https://patch.msgid.link/e1161c90894ddc519c57dc0224b3a0f6bfa1d2d6.1775049897.git.daniel@makrotopia.org
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---
>
> LLM Generated explanations, may be completely bogus:
>
> Now I have all the information needed for a complete analysis.
This commit should NOT be backported, it only makes sense with bridge
offloading implemented, which only happened with commit 340bdf984613c
("net: dsa: mxl862xx: implement bridge offloading").
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox