* Re: [PATCH net-next] r8169: report per-queue statistics through netdev qstats
From: Jakub Kicinski @ 2026-04-18 17:50 UTC (permalink / raw)
To: Gustavo Arantes
Cc: Heiner Kallweit, nic_swsd, Andrew Lunn, David S . Miller,
Eric Dumazet, Paolo Abeni, netdev, linux-kernel
In-Reply-To: <20260418021232.5425-1-dev.gustavoa@gmail.com>
On Fri, 17 Apr 2026 23:12:32 -0300 Gustavo Arantes wrote:
> r8169 maintains synchronized per-CPU software counters for packet and byte
> accounting, but does not expose them through the netdev qstats interface.
>
> Add netdev_stat_ops callbacks and report the existing software counters
> through queue 0 for both Rx and Tx. Provide zero base stats so device-scope
> qstats report the packet and byte counters as supported and match the
> existing RTNL statistics.
It'd be good to include the motivation / backstory that led you to
implementing this when you repost this after the merge window.
Benefit of having qstats with a single queue may not be obvious.
^ permalink raw reply
* Re: [PATCH net v2] ibmveth: Disable GSO for packets with small MSS
From: Jakub Kicinski @ 2026-04-18 17:54 UTC (permalink / raw)
To: mmc
Cc: Jakub Kicinski, netdev, davem, edumazet, pabeni, horms, bjking1,
haren, ricklind, maddy, mpe, linuxppc-dev, stable, shaik.abdulla1,
naveedaus
In-Reply-To: <20260417172910.81433-1-mmc@linux.ibm.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
ibmveth: Disable GSO for packets with small MSS
This commit adds an ndo_features_check callback to the ibmveth driver to
disable segmentation offload when the MSS is less than 224 bytes. This
prevents physical adapters in SEA configurations from freezing when given
small MSS packets.
> diff --git a/drivers/net/ethernet/ibm/ibmveth.c b/drivers/net/ethernet/ibm/ibmveth.c
> --- a/drivers/net/ethernet/ibm/ibmveth.c
> +++ b/drivers/net/ethernet/ibm/ibmveth.c
[ ... ]
> @@ -1756,6 +1756,25 @@ static int ibmveth_set_mac_addr(struct net_device *dev, void *p)
> return 0;
> }
>
> +static netdev_features_t ibmveth_features_check(struct sk_buff *skb,
> + struct net_device *dev,
> + netdev_features_t features)
> +{
> + /* Some physical adapters do not support segmentation offload with
> + * MSS < 224. Disable GSO for such packets to avoid adapter freeze.
> + */
> + if (skb_is_gso(skb)) {
The commit message mentions this matches the ibmvnic hardware errata from
commit f10b09ef687f. That commit disabled GSO for both gso_size < 224 and
gso_segs == 1.
By omitting the check for skb_shinfo(skb)->gso_segs == 1, could a
single-segment GSO packet still cause the adapter to freeze?
> + if (skb_shinfo(skb)->gso_size < IBMVETH_MIN_LSO_MSS) {
> + netdev_warn_once(dev,
> + "MSS %u too small for LSO, disabling GSO\n",
> + skb_shinfo(skb)->gso_size);
> + features &= ~NETIF_F_GSO_MASK;
> + }
> + }
> +
> + return features;
When implementing a custom ndo_features_check callback, netif_skb_features()
will bypass the standard dflt_features_check() function. Does this mean
vlan_features_check() is no longer called for this driver?
If vlan_features_check() is skipped, multi-tagged (QinQ) VLAN packets
might retain GSO and protocol-specific checksum offloads that the hardware
parser cannot handle.
Should this return vlan_features_check(skb, features) instead?
> +}
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH nf,v3] netfilter: nat: use kfree_rcu to release ops
From: Jakub Kicinski @ 2026-04-18 17:58 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: netfilter-devel, fw, netdev
In-Reply-To: <20260417101132.379848-1-pablo@netfilter.org>
On Fri, 17 Apr 2026 12:11:31 +0200 Pablo Neira Ayuso wrote:
> Subject: [PATCH nf,v3] netfilter: nat: use kfree_rcu to release ops
Out of curiosity - why are you CCing netdev on this?
^ permalink raw reply
* Re: [PATCH net] net: dsa: mt7530: fix .get_stats64 sleeping in atomic context
From: Jakub Kicinski @ 2026-04-18 18:01 UTC (permalink / raw)
To: daniel
Cc: Jakub Kicinski, chester.a.unal, andrew, olteanv, davem, edumazet,
pabeni, matthias.bgg, angelogioacchino.delregno, linux,
ansuelsmth, netdev, linux-kernel, linux-arm-kernel,
linux-mediatek, frank-w, john
In-Reply-To: <79dc0ec5b6be698b14cb66339d6f63033ca2934a.1776397542.git.daniel@makrotopia.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.
---
Subject: net: dsa: mt7530: fix .get_stats64 sleeping in atomic context
This commit addresses a sleep-in-atomic bug when reading MDIO-connected
switch port statistics by delegating the register reads to a delayed
workqueue. The get_stats64 callback now returns cached values protected
by a spinlock instead of synchronously reading from the MDIO bus.
MMIO-connected switches are unaffected and continue to read counters
directly.
> diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
> index b9423389c2ef0..786d3a8492bcb 100644
> --- a/drivers/net/dsa/mt7530.c
> +++ b/drivers/net/dsa/mt7530.c
[ ... ]
> @@ -951,6 +952,43 @@ static void mt7530_get_stats64(struct dsa_switch *ds, int port,
> &storage->rx_crc_errors);
> }
>
> +static void mt7530_stats_poll(struct work_struct *work)
> +{
> + struct mt7530_priv *priv = container_of(work, struct mt7530_priv,
> + stats_work.work);
> + struct rtnl_link_stats64 stats = {};
> + struct dsa_port *dp;
> + int port;
> +
> + dsa_switch_for_each_user_port(dp, priv->ds) {
> + port = dp->index;
> +
> + mt7530_read_port_stats64(priv, port, &stats);
> +
> + spin_lock(&priv->stats_lock);
Are we at risk of a deadlock here?
The get_stats64 callback can be called by dev_get_stats(), which runs in
softirq context.
If this delayed work runs in process context and is preempted by a softirq
that attempts to acquire the lock via dev_get_stats(), a deadlock could
occur. Both paths should likely use spin_lock_bh() and spin_unlock_bh().
> + priv->ports[port].stats = stats;
> + spin_unlock(&priv->stats_lock);
> + }
> +
> + schedule_delayed_work(&priv->stats_work,
> + MT7530_STATS_POLL_INTERVAL);
> +}
> +
> +static void mt7530_get_stats64(struct dsa_switch *ds, int port,
> + struct rtnl_link_stats64 *storage)
> +{
> + struct mt7530_priv *priv = ds->priv;
> +
> + if (priv->bus) {
> + spin_lock(&priv->stats_lock);
> + *storage = priv->ports[port].stats;
> + spin_unlock(&priv->stats_lock);
> + mod_delayed_work(system_wq, &priv->stats_work, 0);
Could this unconditional background refresh cause a denial of service on
the MDIO bus?
If an unprivileged user continually reads network statistics in a tight
loop, mt7530_stats_poll() will execute continuously, potentially starving
other MDIO tasks like PHY link-state monitoring.
Additionally, is it possible for this call to re-arm the workqueue during
teardown?
In mt7530_remove_common(), cancel_delayed_work_sync() is called before
dsa_unregister_switch(). If get_stats64() is called during or after
dsa_unregister_switch(), it would re-arm the workqueue after it was
explicitly cancelled, potentially causing a use-after-free when priv is
freed.
> + } else {
> + mt7530_read_port_stats64(priv, port, storage);
> + }
> +}
[ ... ]
> @@ -3137,6 +3175,13 @@ mt753x_setup(struct dsa_switch *ds)
> if (ret && priv->irq_domain)
> mt7530_free_mdio_irq(priv);
>
> + if (!ret && priv->bus) {
> + spin_lock_init(&priv->stats_lock);
> + INIT_DELAYED_WORK(&priv->stats_work, mt7530_stats_poll);
> + schedule_delayed_work(&priv->stats_work,
> + MT7530_STATS_POLL_INTERVAL);
If dsa_register_switch() encounters an error after this setup callback
completes successfully, the DSA core will attempt to clean up.
Since mt7530_switch_ops does not implement a teardown callback to cancel
this delayed work, will the work remain scheduled and eventually
dereference freed priv memory once the driver core frees it via devres?
> + }
> +
> return ret;
> }
--
pw-bot: cr
^ permalink raw reply
* [PATCH net v2 0/2] tcp: fix listener wakeup after reuseport migration
From: Zhenzhong Wu @ 2026-04-18 18:13 UTC (permalink / raw)
To: netdev
Cc: edumazet, ncardwell, kuniyu, davem, dsahern, kuba, pabeni, horms,
shuah, tamird, linux-kernel, linux-kselftest, Zhenzhong Wu
This series fixes a missing wakeup when inet_csk_listen_stop() migrates
an established child socket from a closing listener to another socket
in the same SO_REUSEPORT group after the child has already been queued
for accept.
The target listener receives the migrated accept-queue entry via
inet_csk_reqsk_queue_add(), but its waiters are not notified.
Nonblocking accept() still succeeds because it checks the accept queue
directly, but readiness-based waiters can remain asleep until another
connection generates a wakeup.
Patch 1 notifies the target listener after a successful migration in
inet_csk_listen_stop() and protects the post-queue_add() nsk accesses
with rcu_read_lock()/rcu_read_unlock().
Patch 2 extends the existing migrate_reuseport BPF selftest with an
epoll readiness check for the TCP_ESTABLISHED migration case.
Testing:
- On a patched kernel booted under QEMU, the full migrate_reuseport
selftest passes with SELFTEST_RC=0.
---
v2:
- wrap the post-queue_add() nsk dereferences with rcu_read_lock()/
rcu_read_unlock() to prevent a potential UAF (Eric Dumazet)
- extend tools/testing/selftests/bpf/prog_tests/migrate_reuseport.c
instead of adding standalone net selftests (Kuniyuki Iwashima)
- limit the epoll readiness check to TCP_ESTABLISHED cases
v1:
https://lore.kernel.org/netdev/20260418041633.691435-1-jt26wzz@gmail.com/
Zhenzhong Wu (2):
tcp: call sk_data_ready() after listener migration
selftests/bpf: check epoll readiness after reuseport migration
net/ipv4/inet_connection_sock.c | 3 ++
.../bpf/prog_tests/migrate_reuseport.c | 32 ++++++++++++++++++-
2 files changed, 34 insertions(+), 1 deletion(-)
base-commit: 52bcb57a4e8a0865a76c587c2451906342ae1b2d
--
2.43.0
^ permalink raw reply
* [PATCH net v2 1/2] tcp: call sk_data_ready() after listener migration
From: Zhenzhong Wu @ 2026-04-18 18:13 UTC (permalink / raw)
To: netdev
Cc: edumazet, ncardwell, kuniyu, davem, dsahern, kuba, pabeni, horms,
shuah, tamird, linux-kernel, linux-kselftest, Zhenzhong Wu,
stable
In-Reply-To: <20260418181333.1713389-1-jt26wzz@gmail.com>
When inet_csk_listen_stop() migrates an established child socket from
a closing listener to another socket in the same SO_REUSEPORT group,
the target listener gets a new accept-queue entry via
inet_csk_reqsk_queue_add(), but that path never notifies the target
listener's waiters. A nonblocking accept() still works because it
checks the queue directly, but poll()/epoll_wait() waiters and
blocking accept() callers can also remain asleep indefinitely.
Call READ_ONCE(nsk->sk_data_ready)(nsk) after a successful migration
in inet_csk_listen_stop().
However, after inet_csk_reqsk_queue_add() succeeds, the ref acquired
in reuseport_migrate_sock() is effectively transferred to
nreq->rsk_listener. Another CPU can then dequeue nreq via accept()
or listener shutdown, hit reqsk_put(), and drop that listener ref.
Since listeners are SOCK_RCU_FREE, wrap the post-queue_add()
dereferences of nsk in rcu_read_lock()/rcu_read_unlock(), which also
covers the existing sock_net(nsk) access in that path.
The reqsk_timer_handler() path does not need the same changes for two
reasons: half-open requests become readable only after the final ACK,
where tcp_child_process() already wakes the listener; and once nreq is
visible via inet_ehash_insert(), the success path no longer touches
nsk directly.
Fixes: 54b92e841937 ("tcp: Migrate TCP_ESTABLISHED/TCP_SYN_RECV sockets in accept queues.")
Cc: stable@vger.kernel.org
Suggested-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Zhenzhong Wu <jt26wzz@gmail.com>
---
net/ipv4/inet_connection_sock.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index 4ac3ae1bc..928654c34 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -1479,16 +1479,19 @@ void inet_csk_listen_stop(struct sock *sk)
if (nreq) {
refcount_set(&nreq->rsk_refcnt, 1);
+ rcu_read_lock();
if (inet_csk_reqsk_queue_add(nsk, nreq, child)) {
__NET_INC_STATS(sock_net(nsk),
LINUX_MIB_TCPMIGRATEREQSUCCESS);
reqsk_migrate_reset(req);
+ READ_ONCE(nsk->sk_data_ready)(nsk);
} else {
__NET_INC_STATS(sock_net(nsk),
LINUX_MIB_TCPMIGRATEREQFAILURE);
reqsk_migrate_reset(nreq);
__reqsk_free(nreq);
}
+ rcu_read_unlock();
/* inet_csk_reqsk_queue_add() has already
* called inet_child_forget() on failure case.
--
2.43.0
^ permalink raw reply related
* [PATCH net v2 2/2] selftests/bpf: check epoll readiness after reuseport migration
From: Zhenzhong Wu @ 2026-04-18 18:13 UTC (permalink / raw)
To: netdev
Cc: edumazet, ncardwell, kuniyu, davem, dsahern, kuba, pabeni, horms,
shuah, tamird, linux-kernel, linux-kselftest, Zhenzhong Wu
In-Reply-To: <20260418181333.1713389-1-jt26wzz@gmail.com>
After migrate_dance() moves established children to the target
listener, add it to an epoll set and verify that epoll_wait(..., 0)
reports it ready before accept().
This adds epoll coverage for the TCP_ESTABLISHED reuseport migration
case in migrate_reuseport.
Keep the check limited to TCP_ESTABLISHED cases. TCP_SYN_RECV and
TCP_NEW_SYN_RECV still depend on asynchronous handshake completion,
so a zero-timeout epoll_wait() would race there.
Signed-off-by: Zhenzhong Wu <jt26wzz@gmail.com>
---
.../bpf/prog_tests/migrate_reuseport.c | 32 ++++++++++++++++++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/bpf/prog_tests/migrate_reuseport.c b/tools/testing/selftests/bpf/prog_tests/migrate_reuseport.c
index 653b0a20f..580a53424 100644
--- a/tools/testing/selftests/bpf/prog_tests/migrate_reuseport.c
+++ b/tools/testing/selftests/bpf/prog_tests/migrate_reuseport.c
@@ -18,13 +18,16 @@
* 9. call shutdown() for the second server
* and migrate the requests in the accept queue
* to the last server socket.
- * 10. call accept() for the last server socket.
+ * 10. for TCP_ESTABLISHED cases, call epoll_wait(..., 0)
+ * for the last server socket.
+ * 11. call accept() for the last server socket.
*
* Author: Kuniyuki Iwashima <kuniyu@amazon.co.jp>
*/
#include <bpf/bpf.h>
#include <bpf/libbpf.h>
+#include <sys/epoll.h>
#include "test_progs.h"
#include "test_migrate_reuseport.skel.h"
@@ -522,6 +525,33 @@ static void run_test(struct migrate_reuseport_test_case *test_case,
goto close_clients;
}
+ /* Only TCP_ESTABLISHED has already-migrated accept-queue entries
+ * here. Later states still depend on follow-up handshake work.
+ */
+ if (test_case->state == BPF_TCP_ESTABLISHED) {
+ struct epoll_event ev = {
+ .events = EPOLLIN,
+ };
+ int epfd;
+ int nfds;
+
+ epfd = epoll_create1(EPOLL_CLOEXEC);
+ if (!ASSERT_NEQ(epfd, -1, "epoll_create1"))
+ goto close_clients;
+
+ ev.data.fd = test_case->servers[MIGRATED_TO];
+ if (!ASSERT_OK(epoll_ctl(epfd, EPOLL_CTL_ADD,
+ test_case->servers[MIGRATED_TO], &ev),
+ "epoll_ctl"))
+ goto close_epfd;
+
+ nfds = epoll_wait(epfd, &ev, 1, 0);
+ ASSERT_EQ(nfds, 1, "epoll_wait");
+
+close_epfd:
+ close(epfd);
+ }
+
count_requests(test_case, skel);
close_clients:
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net 00/14] tcp: take care of tcp_get_timestamping_opt_stats() races
From: patchwork-bot+netdevbpf @ 2026-04-18 18:50 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, kuba, pabeni, horms, ncardwell, kuniyu, netdev,
eric.dumazet
In-Reply-To: <20260416200319.3608680-1-edumazet@google.com>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 16 Apr 2026 20:03:05 +0000 you wrote:
> tcp_get_timestamping_opt_stats() does not own the socket lock,
> this is intentional.
>
> It calls tcp_get_info_chrono_stats() while other threads could
> change chrono fields in tcp_chrono_set(). It also reads many
> tcp socket fields that can be modified by other cpus/threads.
>
> [...]
Here is the summary with links:
- [net,01/14] tcp: annotate data-races in tcp_get_info_chrono_stats()
https://git.kernel.org/netdev/net/c/267bf3cf9a6f
- [net,02/14] tcp: add data-race annotations around tp->data_segs_out and tp->total_retrans
https://git.kernel.org/netdev/net/c/21e92a38cfd8
- [net,03/14] tcp: add data-races annotations around tp->reordering, tp->snd_cwnd
https://git.kernel.org/netdev/net/c/829ba1f329cb
- [net,04/14] tcp: annotate data-races around tp->snd_ssthresh
https://git.kernel.org/netdev/net/c/fd571afb05eb
- [net,05/14] tcp: annotate data-races around tp->delivered and tp->delivered_ce
https://git.kernel.org/netdev/net/c/faa886ad3ce5
- [net,06/14] tcp: add data-race annotations for TCP_NLA_SNDQ_SIZE
https://git.kernel.org/netdev/net/c/124199444de4
- [net,07/14] tcp: annotate data-races around tp->bytes_sent
https://git.kernel.org/netdev/net/c/ee43e957ce2e
- [net,08/14] tcp: annotate data-races around tp->bytes_retrans
https://git.kernel.org/netdev/net/c/5efc7b9f7cbd
- [net,09/14] tcp: annotate data-races around tp->dsack_dups
https://git.kernel.org/netdev/net/c/a984705ca88b
- [net,10/14] tcp: annotate data-races around tp->reord_seen
https://git.kernel.org/netdev/net/c/62585690e6b2
- [net,11/14] tcp: annotate data-races around tp->srtt_us
https://git.kernel.org/netdev/net/c/290b693ce7c9
- [net,12/14] tcp: annotate data-races around tp->timeout_rehash
https://git.kernel.org/netdev/net/c/71c675358b71
- [net,13/14] tcp: annotate data-races around (tp->write_seq - tp->snd_nxt)
https://git.kernel.org/netdev/net/c/3a63b3d16056
- [net,14/14] tcp: annotate data-races around tp->plb_rehash
https://git.kernel.org/netdev/net/c/9e89b9d03a2d
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net 0/6] pull request: fixes for ovpn 2026-04-17
From: Jakub Kicinski @ 2026-04-18 18:54 UTC (permalink / raw)
To: Antonio Quartulli
Cc: netdev, ralf, shuah, horms, Sabrina Dubroca, Paolo Abeni,
Andrew Lunn, David S. Miller, Eric Dumazet
In-Reply-To: <20260417090305.2775723-1-antonio@openvpn.net>
On Fri, 17 Apr 2026 11:02:59 +0200 Antonio Quartulli wrote:
> This is a respin of the PR I originally sent against net-next + an extra
> fix (patch 6).
>
> Please note that this patch:
> https://lore.kernel.org/all/20260225010833.11301-1-liuhangbin@gmail.com/
> broke the selftests entirely due to the switch from sh to bash.
>
> There are new commits in the kselftest tree which take care of this:
> https://lore.kernel.org/all/20260416-selftest-fix-readlink-e-v1-0-94e4cabbdec4@kernel.org/
> but they are not in net yet, therefore you won't be able to test/run
> our kselftests for now.
It does work for us, FWIW, maybe because we run tests with make
run_tests. There were some entirely unnecessary changes to ktap
output which broke our systems but we patched around them :/
> TCP tests are still failing every now and then.
> It seems that sometimes a single ping over a TCP tunnel is lost,
> thus making the selftest fail.
They seem to fail for us around 50% of the time on debug kernel
builds. What's your repro rate?
> We believe this is a bug in ovpn which we are currently hunting down.
> So it's nothing wrong about the tests (they are actually doing their
> job!).
FWIW one of today's runs hit this:
https://netdev-ctrl.bots.linux.dev/logs/vmksft/net-extra-dbg/results/608740/3-test-symmetric-id-tcp-sh/stderr
decoded:
https://netdev-ctrl.bots.linux.dev/logs/vmksft/net-extra-dbg/results/608740/vm-crash-thr0-0
In any case - test_mark.sh looks good now, so I'll take it out of
the ignored list. Thanks! 2 more to go? :)
^ permalink raw reply
* Re: [PATCH net v2 11/12] idpf: fix xdp crash in soft reset error path
From: Jakub Kicinski @ 2026-04-18 19:00 UTC (permalink / raw)
To: jacob.e.keller
Cc: Jakub Kicinski, andrew+netdev, davem, edumazet, pabeni, netdev,
emil.s.tantilov, stable, aleksandr.loktionov, patryk.holda
In-Reply-To: <20260416-iwl-net-submission-2026-04-14-v2-11-686c33c9828d@intel.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Jakub: I'll drop this patch and apply the rest.
---
idpf: fix xdp crash in soft reset error path
This commit fixes a NULL pointer dereference in idpf_vport_open() when
soft reset fails by restoring vport->xdp_prog to the old value. It also
updates the restart check to use IDPF_VPORT_UP instead of netif_running().
Cc: stable@vger.kernel.org
> diff --git a/drivers/net/ethernet/intel/idpf/xdp.c b/drivers/net/ethernet/intel/idpf/xdp.c
> --- a/drivers/net/ethernet/intel/idpf/xdp.c
> +++ b/drivers/net/ethernet/intel/idpf/xdp.c
> @@ -488,6 +488,7 @@ static int idpf_xdp_setup_prog(struct idpf_vport *vport,
> "Could not reopen the vport after XDP setup");
>
> cfg->user_config.xdp_prog = old;
> + vport->xdp_prog = old;
Does this also need to roll back vport->num_xdp_txq?
Because idpf_initiate_soft_reset() overwrites the vport struct with the new
queue configuration before failing, vport->num_xdp_txq might remain > 0
while vport->xdp_prog is restored to NULL.
When the interface is brought up, idpf_xdpsqs_get() evaluates
idpf_xdp_enabled(vport) as false and returns early without allocating the
NAPI timers (xdpsq->timer).
Could another interface redirect XDP frames via ndo_xdp_xmit, bypassing the
check because vport->num_xdp_txq > 0, and cause a NULL pointer dereference
in libeth_xdpsq_queue_timer() during idpf_xdp_tx_finalize()?
> old = prog;
> }
Is this old = prog assignment leading to a double-put of the BPF program?
If idpf_initiate_soft_reset() fails, this error path drops a reference to
the newly provided prog when it calls bpf_prog_put(old) right after this
block.
Since the function returns an error code to the core network stack, won't
dev_xdp_install() in net/core/dev.c also explicitly call bpf_prog_put(prog)
assuming ownership of the error cleanup?
Could this underflow the reference count and cause a use-after-free?
[ ... ]
> diff --git a/drivers/net/ethernet/intel/idpf/xsk.c b/drivers/net/ethernet/intel/idpf/xsk.c
> --- a/drivers/net/ethernet/intel/idpf/xsk.c
> +++ b/drivers/net/ethernet/intel/idpf/xsk.c
> @@ -568,7 +569,8 @@ int idpf_xsk_pool_setup(struct idpf_vport *vport, struct netdev_bpf *bpf)
> return -EINVAL;
> }
>
> - restart = idpf_xdp_enabled(vport) && netif_running(vport->netdev);
> + restart = idpf_xdp_enabled(vport) &&
> + test_bit(IDPF_VPORT_UP, np->state);
> if (!restart)
> goto pool;
Does this function leave the queue pair permanently disabled if the pool
setup fails?
If restart is true, the queue pair is disabled via:
idpf_qp_switch(vport, qid, false);
If the subsequent call to libeth_xsk_setup_pool() fails, the function
returns early:
ret = libeth_xsk_setup_pool(vport->netdev, qid, pool);
if (ret) {
...
return ret;
}
Does this early return bypass the idpf_qp_switch(vport, qid, true) call
expected later, causing a permanent partial loss of connectivity until the
interface is manually restarted?
^ permalink raw reply
* Re: [PATCH net 1/6] selftests: ovpn: add nftables config dependencies for test-mark
From: patchwork-bot+netdevbpf @ 2026-04-18 19:00 UTC (permalink / raw)
To: Antonio Quartulli
Cc: netdev, ralf, shuah, horms, sd, kuba, pabeni, andrew+netdev,
davem, edumazet
In-Reply-To: <20260417090305.2775723-2-antonio@openvpn.net>
Hello:
This series was applied to netdev/net.git (main)
by Antonio Quartulli <antonio@openvpn.net>:
On Fri, 17 Apr 2026 11:03:00 +0200 you wrote:
> From: Ralf Lici <ralf@mandelbit.com>
>
> test-mark.sh installs nftables rules in an inet/filter output chain and
> verifies packet drops via nft counters. In vmksft this can fail when the
> nftables core is not enabled by the ovpn selftest config.
>
> Add the missing kernel options required by this test:
> - CONFIG_NETFILTER
> - CONFIG_NF_TABLES
> - CONFIG_NF_TABLES_INET
>
> [...]
Here is the summary with links:
- [net,1/6] selftests: ovpn: add nftables config dependencies for test-mark
https://git.kernel.org/netdev/net/c/e5fd34ab8dff
- [net,2/6] selftests: ovpn: fail notification check on mismatch
https://git.kernel.org/netdev/net/c/c409da0fe15e
- [net,3/6] selftests: ovpn: flatten slurped notification JSON before filtering
https://git.kernel.org/netdev/net/c/222e7f8d1ca3
- [net,4/6] selftests: ovpn: add prefix to helpers and shared variables
https://git.kernel.org/netdev/net/c/7c29665a3a3c
- [net,5/6] selftests: ovpn: align command flow with TAP
https://git.kernel.org/netdev/net/c/1be93bb979ab
- [net,6/6] selftests: ovpn: serialize YNL listener startup
https://git.kernel.org/netdev/net/c/6c9b1dc218fe
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net 1/2] net/mlx5e: psp: Fix invalid access on PSP dev registration fail
From: Jakub Kicinski @ 2026-04-18 19:08 UTC (permalink / raw)
To: tariqt
Cc: Jakub Kicinski, edumazet, pabeni, andrew+netdev, davem, borisp,
saeedm, leon, mbloch, daniel.zahka, willemdebruijn.kernel, cratiu,
raeds, rrameshbabu, dtatulea, kees, netdev, linux-rdma,
linux-kernel, gal
In-Reply-To: <20260417050201.192070-2-tariqt@nvidia.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
net/mlx5e: psp: Fix invalid access on PSP dev registration fail
This commit updates PSP device registration to use a local variable,
only saving the PSP device pointer if psp_dev_create() succeeds. This
prevents an error pointer from being stored in priv->psp->psp.
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/psp.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/psp.c
[ ... ]
> @@ -1070,29 +1070,37 @@ static struct psp_dev_ops mlx5_psp_ops = {
[ ... ]
> void mlx5e_psp_register(struct mlx5e_priv *priv)
> {
> + struct mlx5e_psp *psp = priv->psp;
> + struct psp_dev *psd;
> +
[ ... ]
> - priv->psp->psp = psp_dev_create(priv->netdev, &mlx5_psp_ops,
> - &priv->psp->caps, NULL);
> - if (IS_ERR(priv->psp->psp))
> + psd = psp_dev_create(priv->netdev, &mlx5_psp_ops, &psp->caps, NULL);
> + if (IS_ERR(psd)) {
> mlx5_core_err(priv->mdev, "PSP failed to register due to %pe\n",
> - priv->psp->psp);
> + psd);
> + return;
> + }
> + psp->psp = psd;
> }
When psp_dev_create() fails, this function now returns without setting
psp->psp, leaving it as NULL. However, priv->psp remains allocated and
non-NULL.
Does this leave the RX datapath vulnerable to a NULL pointer dereference?
If priv->psp is non-NULL, the NIC RX initialization path can still call
mlx5_accel_psp_fs_init_rx_tables(), which creates hardware flow steering
rules to intercept UDP traffic.
If a UDP packet triggers these rules, the hardware flags the CQE with
MLX5E_PSP_MARKER_BIT. The RX fast-path sees the marker and invokes
mlx5e_psp_offload_handle_rx_skb(), which dereferences the pointer
unconditionally:
u16 dev_id = priv->psp->psp->id;
Since priv->psp->psp is NULL, this will cause a kernel panic. Should
priv->psp be cleaned up, or the error propagated, to prevent flow rules
from being installed when registration fails?
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net v2 00/12] Intel Wired LAN Driver Updates 2026-04-14 (ice, i40e, iavf, idpf, e1000e)
From: patchwork-bot+netdevbpf @ 2026-04-18 19:10 UTC (permalink / raw)
To: Jacob Keller
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, netdev,
grzegorz.nitka, aleksandr.loktionov, horms, sx.rinitha,
zoltan.fodor, sunithax.d.mekala, lgs201920130244, stable,
mschmidt, paul.greenwalt, przemyslaw.kitszel, kmta1236, kohei,
poros, pmenzel, rafal.romanowski, emil.s.tantilov, patryk.holda,
tactii, avigailx.dahan
In-Reply-To: <20260416-iwl-net-submission-2026-04-14-v2-0-686c33c9828d@intel.com>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 16 Apr 2026 17:53:24 -0700 you wrote:
> Grzegorz updates the logic for adjusting the PTP hardware clock on E830,
> fixing a bug that prevented adjustments below S32_MAX/MIN nanoseconds.
>
> Grzegorz and Zoli update the PCS latency settings for E825 devices at 10GbE
> and 25GbE, improving the accuracy of timestamps based on data from
> production hardware.
>
> [...]
Here is the summary with links:
- [net,v2,01/12] ice: fix 'adjust' timer programming for E830 devices
https://git.kernel.org/netdev/net/c/885c5e57924d
- [net,v2,02/12] ice: update PCS latency settings for E825 10G/25Gb modes
https://git.kernel.org/netdev/net/c/05567e405273
- [net,v2,03/12] ice: fix double free in ice_sf_eth_activate() error path
https://git.kernel.org/netdev/net/c/9aab1c3d7299
- [net,v2,04/12] ice: fix double-free of tx_buf skb
https://git.kernel.org/netdev/net/c/1a303baa715e
- [net,v2,05/12] ice: fix PHY config on media change with link-down-on-close
https://git.kernel.org/netdev/net/c/55e74f9ea7fe
- [net,v2,06/12] ice: fix ICE_AQ_LINK_SPEED_M for 200G
https://git.kernel.org/netdev/net/c/4a3a940059e9
- [net,v2,07/12] ice: fix race condition in TX timestamp ring cleanup
https://git.kernel.org/netdev/net/c/7c72ec18c2a4
- [net,v2,08/12] ice: fix potential NULL pointer deref in error path of ice_set_ringparam()
https://git.kernel.org/netdev/net/c/fa28351f970f
- [net,v2,09/12] i40e: don't advertise IFF_SUPP_NOFCS
https://git.kernel.org/netdev/net/c/a24162f18825
- [net,v2,10/12] iavf: fix wrong VLAN mask for legacy Rx descriptors L2TAG2
https://git.kernel.org/netdev/net/c/496d9f91062f
- [net,v2,11/12] idpf: fix xdp crash in soft reset error path
(no matching commit)
- [net,v2,12/12] e1000e: Unroll PTP in probe error handling
https://git.kernel.org/netdev/net/c/aa3f7fe40935
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [net,PATCH v4 1/2] net: ks8851: Reinstate disabling of BHs around IRQ handler
From: patchwork-bot+netdevbpf @ 2026-04-18 19:20 UTC (permalink / raw)
To: Marek Vasut
Cc: netdev, bigeasy, stable, davem, andrew+netdev, edumazet, kuba, nb,
pabeni, ronald.wahl, yiconghui, linux-kernel
In-Reply-To: <20260415231020.455298-1-marex@nabladev.com>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 16 Apr 2026 01:09:44 +0200 you wrote:
> If the driver executes ks8851_irq() AND a TX packet has been sent, then
> the driver enables TX queue via netif_wake_queue() which schedules TX
> softirq to queue packets for this device.
>
> If CONFIG_PREEMPT_RT=y is set AND a packet has also been received by
> the MAC, then ks8851_rx_pkts() calls netdev_alloc_skb_ip_align() to
> allocate SKBs for the received packets. If netdev_alloc_skb_ip_align()
> is called with BH enabled, then local_bh_enable() at the end of
> netdev_alloc_skb_ip_align() will trigger the pending softirq processing,
> which may ultimately call the .xmit callback ks8851_start_xmit_par().
> The ks8851_start_xmit_par() will try to lock struct ks8851_net_par
> .lock spinlock, which is already locked by ks8851_irq() from which
> ks8851_start_xmit_par() was called. This leads to a deadlock, which
> is reported by the kernel, including a trace listed below.
>
> [...]
Here is the summary with links:
- [net,v4,1/2] net: ks8851: Reinstate disabling of BHs around IRQ handler
https://git.kernel.org/netdev/net/c/5c9fcac3c872
- [net,v4,2/2] net: ks8851: Avoid excess softirq scheduling
https://git.kernel.org/netdev/net/c/22230e68b2cf
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net,v3 1/1] net: stmmac: Update default_an_inband before passing value to phylink_config
From: patchwork-bot+netdevbpf @ 2026-04-18 19:20 UTC (permalink / raw)
To: KhaiWenTan
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, mcoquelin.stm32,
alexandre.torgue, rmk+kernel, maxime.chevallier, netdev,
linux-stm32, linux-arm-kernel, linux-kernel, yoong.siang.song,
hong.aun.looi, khai.wen.tan
In-Reply-To: <20260416102609.7953-1-khai.wen.tan@intel.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 16 Apr 2026 18:26:09 +0800 you wrote:
> From: KhaiWenTan <khai.wen.tan@linux.intel.com>
>
> get_interfaces() will update both the plat->phy_interfaces and
> mdio_bus_data->default_an_inband based on reading a SERDES register. As
> get_interfaces() will be called after default_an_inband had already been
> read, dwmac-intel regressed as a result with incorrect default_an_inband
> value in phylink_config.
>
> [...]
Here is the summary with links:
- [net,v3,1/1] net: stmmac: Update default_an_inband before passing value to phylink_config
https://git.kernel.org/netdev/net/c/8cff9dbe89d8
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net] ipv6: fix possible UAF in icmpv6_rcv()
From: patchwork-bot+netdevbpf @ 2026-04-18 19:20 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, kuba, pabeni, horms, dsahern, idosch, netdev, eric.dumazet
In-Reply-To: <20260416103505.2380753-1-edumazet@google.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 16 Apr 2026 10:35:05 +0000 you wrote:
> Caching saddr and daddr before pskb_pull() is problematic
> since skb->head can change.
>
> Remove these temporary variables:
>
> - We only access &ipv6_hdr(skb)->saddr and &ipv6_hdr(skb)->daddr
> when net_dbg_ratelimited() is called in the slow path.
>
> [...]
Here is the summary with links:
- [net] ipv6: fix possible UAF in icmpv6_rcv()
https://git.kernel.org/netdev/net/c/f996edd7615e
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v1 net] af_unix: Drop all SCM attributes for SOCKMAP.
From: patchwork-bot+netdevbpf @ 2026-04-18 19:20 UTC (permalink / raw)
To: Kuniyuki Iwashima
Cc: davem, edumazet, kuba, pabeni, horms, cong.wang, jiang.wang,
kuni1840, netdev, xingyuj
In-Reply-To: <20260415184830.3988432-1-kuniyu@google.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 15 Apr 2026 18:48:29 +0000 you wrote:
> SOCKMAP can hide inflight fd from AF_UNIX GC.
>
> When a socket in SOCKMAP receives skb with inflight fd,
> sk_psock_verdict_data_ready() looks up the mapped socket and
> enqueue skb to its psock->ingress_skb.
>
> Since neither the old nor the new GC can inspect the psock
> queue, the hidden skb leaks the inflight sockets. Note that
> this cannot be detected via kmemleak because inflight sockets
> are linked to a global list.
>
> [...]
Here is the summary with links:
- [v1,net] af_unix: Drop all SCM attributes for SOCKMAP.
https://git.kernel.org/netdev/net/c/965dc93481d1
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* 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: Jakub Kicinski @ 2026-04-18 19:26 UTC (permalink / raw)
To: Kubalewski, Arkadiusz
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: <IA0PR11MB7378CF62D86454916AE8F9D79B202@IA0PR11MB7378.namprd11.prod.outlook.com>
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.
> >> 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.
I'm saying that the function of that pll is obvious since its pin will
plug into the netdev / rtnetlink.
> >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.
^ permalink raw reply
* Re: [PATCH net v6 2/2] pppoe: drop PFC frames
From: Jakub Kicinski @ 2026-04-18 19:11 UTC (permalink / raw)
To: qingfang.deng
Cc: Jakub Kicinski, linux-ppp, andrew+netdev, davem, edumazet, pabeni,
hataegu0826, horms, kees, kuniyu, bigeasy, gnault, ericwouds,
semen.protsenko, netdev, linux-kernel, paulus, jaco, carlsonj,
wojciech.drewek, marcin.szycik
In-Reply-To: <20260415022456.141758-2-qingfang.deng@linux.dev>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
pppoe: drop PFC frames
This commit drops Protocol Field Compression (PFC) frames for PPPoE to avoid
unaligned access exceptions caused by the network header being shifted. A
helper function is introduced to identify compressed protocol fields.
> diff --git a/drivers/net/ppp/pppoe.c b/drivers/net/ppp/pppoe.c
> --- a/drivers/net/ppp/pppoe.c
> +++ b/drivers/net/ppp/pppoe.c
[ ... ]
> @@ -434,6 +434,12 @@ static int pppoe_rcv(struct sk_buff *skb, struct net_device *dev,
> if (skb->len < len)
> goto drop;
>
> + /* skb->data points to the PPP protocol header after skb_pull_rcsum.
> + * Drop PFC frames.
> + */
> + if (ppp_skb_is_compressed_proto(skb))
Does this code safely access the PPP protocol byte?
After pulling the PPPoE header, skb->data points to the inner payload.
However, the new ppp_skb_is_compressed_proto() helper unconditionally
dereferences skb->data[0].
If a crafted PPPoE packet is received with an inner length of 0 and no
Ethernet padding, the linear buffer might end exactly after the PPPoE header.
In that scenario, this would read past the allocated linear buffer.
Even if the inner length is greater than 0, could the payload reside entirely
in non-linear paged fragments, causing an out-of-bounds read?
Would it be safer to verify the packet has at least 1 byte and use
pskb_may_pull() to ensure the protocol byte is in the linear region before
inspecting it, perhaps after the pskb_trim_rcsum() call?
> + goto drop;
> +
> if (pskb_trim_rcsum(skb, len))
> goto drop;
[ ... ]
> diff --git a/include/linux/ppp_defs.h b/include/linux/ppp_defs.h
> --- a/include/linux/ppp_defs.h
> +++ b/include/linux/ppp_defs.h
[ ... ]
> +static inline bool ppp_skb_is_compressed_proto(const struct sk_buff *skb)
> +{
> + return unlikely(skb->data[0] & 0x01);
> +}
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net] sctp: fix OOB write to userspace in sctp_getsockopt_peer_auth_chunks
From: patchwork-bot+netdevbpf @ 2026-04-18 19:30 UTC (permalink / raw)
To: Michael Bommarito
Cc: linux-sctp, marcelo.leitner, lucien.xin, davem, edumazet, kuba,
pabeni, horms, netdev, linux-kernel, stable
In-Reply-To: <20260416031903.1447072-1-michael.bommarito@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 15 Apr 2026 23:19:03 -0400 you wrote:
> sctp_getsockopt_peer_auth_chunks() checks that the caller's optval
> buffer is large enough for the peer AUTH chunk list with
>
> if (len < num_chunks)
> return -EINVAL;
>
> but then writes num_chunks bytes to p->gauth_chunks, which lives
> at offset offsetof(struct sctp_authchunks, gauth_chunks) == 8
> inside optval. The check is missing the sizeof(struct
> sctp_authchunks) = 8-byte header. When the caller supplies
> len == num_chunks (for any num_chunks > 0) the test passes but
> copy_to_user() writes sizeof(struct sctp_authchunks) = 8 bytes
> past the declared buffer.
>
> [...]
Here is the summary with links:
- [net] sctp: fix OOB write to userspace in sctp_getsockopt_peer_auth_chunks
https://git.kernel.org/netdev/net/c/0cf004ffb61c
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH nf] netfilter: xt_TCPMSS: check skb_dst before path-MTU clamping
From: Florian Westphal @ 2026-04-18 19:58 UTC (permalink / raw)
To: Weiming Shi
Cc: Pablo Neira Ayuso, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Phil Sutter, Simon Horman, netfilter-devel, coreteam,
netdev, Xiang Mei
In-Reply-To: <20260418163057.2611503-2-bestswngs@gmail.com>
Weiming Shi <bestswngs@gmail.com> wrote:
> When TCPMSS with CLAMP_PMTU is used via nft_compat in a non-base
> chain, par->hook_mask is set to 0, bypassing the checkentry hook
> validation. The target can then run at PRE_ROUTING where skb_dst is
> NULL, causing a null-ptr-deref in tcpmss_mangle_packet():
>
> KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
> RIP: 0010:tcpmss_mangle_packet (include/net/dst.h:219 net/netfilter/xt_TCPMSS.c:105)
> tcpmss_tg4 (net/netfilter/xt_TCPMSS.c:202)
> nft_target_eval_xt (net/netfilter/nft_compat.c:87)
> nft_do_chain (net/netfilter/nf_tables_core.c:287)
> nf_hook_slow (net/netfilter/core.c:623)
>
> Check skb_dst() for NULL before calling dst_mtu().
FWIW I will apply this patch even though its wrong.
nft_compat.c is just too broken, I don't see how it can be
fixed in any reasonable amount of time.
validation is done too early, at expression instantiation
time.
This doesn't work because we have incomplete graph, it has
to be done at final table validation time.
But then all required compat info (xtables hints) is gone
and no longer available.
AFAICS the only way to resolve this is to cache the info in
the nft_expr priv area (WHERE IS ABSOLUTELY DOESN'T BELONG!)
because thats the only storage thewre is.
*puke*
^ permalink raw reply
* [PATCH net v2] selftests: netfilter: conntrack_sctp_collision.sh: Introduce SCTP INIT collision test
From: Yi Chen @ 2026-04-18 19:58 UTC (permalink / raw)
To: Yi Chen, Pablo Neira Ayuso, Florian Westphal, Phil Sutter,
Long Xin, David S . Miller, Jakub Kicinski, Eric Dumazet,
Paolo Abeni, Simon Horman, Shuah Khan
Cc: coreteam, netfilter-devel, linux-kselftest, linux-kernel, netdev
The existing test covered a scenario where a delayed INIT_ACK chunk
updates the vtag in conntrack after the association has already been
established.
A similar issue can occur with a delayed SCTP INIT chunk.
Add a new simultaneous-open test case where the client's INIT is
delayed, allowing conntrack to establish the association based on
the server-initiated handshake.
When the stale INIT arrives later, it may get recorded and cause a
following INIT_ACK from the peer to be accepted instead of dropped.
This INIT_ACK overwrites the vtag in conntrack, causing subsequent
SCTP DATA chunks to be considered as invalid and then dropped by
nft rules matching on ct state invalid.
This test verifies such stale INIT chunks do not cause problems.
Signed-off-by: Yi Chen <yiche.cy@gmail.com>
Acked-by: Xin Long <lucien.xin@gmail.com>
---
v1 -> v2:
- Simplify conf_delay() by passing arguments.
- Avoid calling exit() inside the function.
- Enable nft log by setting net.netfilter.nf_log_all_netns=1.
- Add a description for the "ct invalid drop" rule match.
---
.../net/netfilter/conntrack_sctp_collision.sh | 85 ++++++++++++++-----
1 file changed, 63 insertions(+), 22 deletions(-)
diff --git a/tools/testing/selftests/net/netfilter/conntrack_sctp_collision.sh b/tools/testing/selftests/net/netfilter/conntrack_sctp_collision.sh
index d860f7d9744b..31823050391e 100755
--- a/tools/testing/selftests/net/netfilter/conntrack_sctp_collision.sh
+++ b/tools/testing/selftests/net/netfilter/conntrack_sctp_collision.sh
@@ -2,18 +2,32 @@
# SPDX-License-Identifier: GPL-2.0
#
# Testing For SCTP COLLISION SCENARIO as Below:
-#
+# 1. Stale INIT_ACK capture:
# 14:35:47.655279 IP CLIENT_IP.PORT > SERVER_IP.PORT: sctp (1) [INIT] [init tag: 2017837359]
# 14:35:48.353250 IP SERVER_IP.PORT > CLIENT_IP.PORT: sctp (1) [INIT] [init tag: 1187206187]
# 14:35:48.353275 IP CLIENT_IP.PORT > SERVER_IP.PORT: sctp (1) [INIT ACK] [init tag: 2017837359]
# 14:35:48.353283 IP SERVER_IP.PORT > CLIENT_IP.PORT: sctp (1) [COOKIE ECHO]
# 14:35:48.353977 IP CLIENT_IP.PORT > SERVER_IP.PORT: sctp (1) [COOKIE ACK]
# 14:35:48.855335 IP SERVER_IP.PORT > CLIENT_IP.PORT: sctp (1) [INIT ACK] [init tag: 164579970]
+# (Delayed)
+#
+# 2. Stale INIT capture:
+# 14:35:48.353250 IP SERVER_IP.PORT > CLIENT_IP.PORT: sctp (1) [INIT] [init tag: 1187206187]
+# 14:35:48.353275 IP CLIENT_IP.PORT > SERVER_IP.PORT: sctp (1) [INIT ACK] [init tag: 2017837359]
+# 14:35:48.353283 IP SERVER_IP.PORT > CLIENT_IP.PORT: sctp (1) [COOKIE ECHO]
+# 14:35:48.353977 IP CLIENT_IP.PORT > SERVER_IP.PORT: sctp (1) [COOKIE ACK]
+# 14:35:47.655279 IP CLIENT_IP.PORT > SERVER_IP.PORT: sctp (1) [INIT] [init tag: 2017837359]
+# (Delayed)
+# 14:35:48.855335 IP SERVER_IP.PORT > CLIENT_IP.PORT: sctp (1) [INIT ACK] [init tag: 164579970]
#
# TOPO: SERVER_NS (link0)<--->(link1) ROUTER_NS (link2)<--->(link3) CLIENT_NS
source lib.sh
+checktool "nft --version" "run test without nft"
+checktool "tc -h" "run test without tc"
+checktool "modprobe -q sctp" "load sctp module"
+
CLIENT_IP="198.51.200.1"
CLIENT_PORT=1234
@@ -24,7 +38,8 @@ CLIENT_GW="198.51.200.2"
SERVER_GW="198.51.100.2"
# setup the topo
-setup() {
+topo_setup() {
+ # setup_ns cleans up existing net namespaces first.
setup_ns CLIENT_NS SERVER_NS ROUTER_NS
ip -n "$SERVER_NS" link add link0 type veth peer name link1 netns "$ROUTER_NS"
ip -n "$CLIENT_NS" link add link3 type veth peer name link2 netns "$ROUTER_NS"
@@ -38,35 +53,53 @@ setup() {
ip -n "$ROUTER_NS" addr add $SERVER_GW/24 dev link1
ip -n "$ROUTER_NS" addr add $CLIENT_GW/24 dev link2
ip net exec "$ROUTER_NS" sysctl -wq net.ipv4.ip_forward=1
+ sysctl -wq net.netfilter.nf_log_all_netns=1
ip -n "$CLIENT_NS" link set link3 up
ip -n "$CLIENT_NS" addr add $CLIENT_IP/24 dev link3
ip -n "$CLIENT_NS" route add $SERVER_IP dev link3 via $CLIENT_GW
+}
- # simulate the delay on OVS upcall by setting up a delay for INIT_ACK with
- # tc on $SERVER_NS side
- tc -n "$SERVER_NS" qdisc add dev link0 root handle 1: htb r2q 64
- tc -n "$SERVER_NS" class add dev link0 parent 1: classid 1:1 htb rate 100mbit
- tc -n "$SERVER_NS" filter add dev link0 parent 1: protocol ip u32 match ip protocol 132 \
- 0xff match u8 2 0xff at 32 flowid 1:1
- if ! tc -n "$SERVER_NS" qdisc add dev link0 parent 1:1 handle 10: netem delay 1200ms; then
+conf_delay()
+{
+ # simulate the delay on OVS upcall by setting up a delay for INIT_ACK/INIT with
+ local ns=$1
+ local link=$2
+ local chunk_type=$3
+
+ # use a smaller number for assoc's max_retrans to reproduce the issue
+ ip net exec "$CLIENT_NS" sysctl -wq net.sctp.association_max_retrans=3
+
+ tc -n "$ns" qdisc add dev "$link" root handle 1: htb r2q 64
+ tc -n "$ns" class add dev "$link" parent 1: classid 1:1 htb rate 100mbit
+ tc -n "$ns" filter add dev "$link" parent 1: protocol ip \
+ u32 match ip protocol 132 0xff match u8 "$chunk_type" 0xff at 32 flowid 1:1
+ if ! tc -n "$ns" qdisc add dev "$link" parent 1:1 handle 10: netem delay 1200ms; then
echo "SKIP: Cannot add netem qdisc"
- exit $ksft_skip
+ return $ksft_skip
fi
# simulate the ctstate check on OVS nf_conntrack
- ip net exec "$ROUTER_NS" iptables -A FORWARD -m state --state INVALID,UNTRACKED -j DROP
- ip net exec "$ROUTER_NS" iptables -A INPUT -p sctp -j DROP
-
- # use a smaller number for assoc's max_retrans to reproduce the issue
- modprobe -q sctp
- ip net exec "$CLIENT_NS" sysctl -wq net.sctp.association_max_retrans=3
+ ip net exec "$ROUTER_NS" nft -f - <<-EOF
+ table ip t {
+ chain forward {
+ type filter hook forward priority filter; policy accept;
+ meta l4proto icmp counter accept
+ ct state new counter accept
+ ct state established,related counter accept
+ ct state invalid log flags all counter drop comment \
+ "Expect to drop stale INIT/INIT_ACK chunks"
+ counter
+ }
+ }
+ EOF
+ return 0
}
cleanup() {
- ip net exec "$CLIENT_NS" pkill sctp_collision >/dev/null 2>&1
- ip net exec "$SERVER_NS" pkill sctp_collision >/dev/null 2>&1
+ # cleanup_all_ns terminates running processes in the namespaces.
cleanup_all_ns
+ sysctl -wq net.netfilter.nf_log_all_netns=0
}
do_test() {
@@ -81,7 +114,15 @@ do_test() {
# run the test case
trap cleanup EXIT
-setup && \
-echo "Test for SCTP Collision in nf_conntrack:" && \
-do_test && echo "PASS!"
-exit $?
+
+echo "Test for SCTP INIT_ACK Collision in nf_conntrack:"
+(topo_setup && conf_delay $SERVER_NS link0 2) || exit $?
+if ! do_test; then
+ exit $ksft_fail
+fi
+
+echo "Test for SCTP INIT Collision in nf_conntrack:"
+(topo_setup && conf_delay $CLIENT_NS link3 1) || exit $?
+if ! do_test; then
+ exit $ksft_fail
+fi
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net] net/packet: fix TOCTOU race on mmap'd vnet_hdr in tpacket_snd()
From: Willem de Bruijn @ 2026-04-18 20:17 UTC (permalink / raw)
To: Bingquan Chen, Willem de Bruijn, Greg KH
Cc: Stephen Hemminger, security, David S . Miller, Jakub Kicinski,
Eric Dumazet, netdev, Bingquan Chen
In-Reply-To: <20260418112006.78823-1-patzilla007@gmail.com>
Bingquan Chen wrote:
> In tpacket_snd(), when PACKET_VNET_HDR is enabled, vnet_hdr points
> directly into the mmap'd TX ring buffer shared with userspace. The
> kernel validates the header via __packet_snd_vnet_parse() but then
> re-reads all fields later in virtio_net_hdr_to_skb(). A concurrent
> userspace thread can modify the vnet_hdr fields between validation
> and use, bypassing all safety checks.
>
> The non-TPACKET path (packet_snd()) already correctly copies vnet_hdr
> to a stack-local variable. All other vnet_hdr consumers in the kernel
> (tun.c, tap.c, virtio_net.c) also use stack copies. The TPACKET TX
> path is the only caller of virtio_net_hdr_to_skb() that reads directly
> from user-controlled shared memory.
>
> Fix this by copying vnet_hdr from the mmap'd ring buffer to a
> stack-local variable before validation and use, consistent with the
> approach used in packet_snd() and all other callers.
>
> Fixes: 1d036d25e560 ("packet: tpacket_snd gso and checksum offload")
> Signed-off-by: Bingquan Chen <patzilla007@gmail.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
^ permalink raw reply
* Re: [PATCH net v2] ipv6: Apply max_dst_opts_cnt to ip6_tnl_parse_tlv_enc_lim
From: Daniel Borkmann @ 2026-04-18 22:19 UTC (permalink / raw)
To: Justin Iurman, kuba
Cc: edumazet, dsahern, tom, willemdebruijn.kernel, idosch, pabeni,
netdev
In-Reply-To: <7c715640-5c20-4226-9c31-d2c5eef551db@gmail.com>
On 4/18/26 2:40 PM, Justin Iurman wrote:
> On 4/18/26 14:15, Daniel Borkmann wrote:
>> Commit 47d3d7ac656a ("ipv6: Implement limits on Hop-by-Hop and
>> Destination options") added net.ipv6.max_{hbh,dst}_opts_{cnt,len}
>> and applied them in ip6_parse_tlv(), the generic TLV walker
>> invoked from ipv6_destopt_rcv() and ipv6_parse_hopopts().
>>
>> ip6_tnl_parse_tlv_enc_lim() does not go through ip6_parse_tlv();
>> it has its own hand-rolled TLV scanner inside its NEXTHDR_DEST
>> branch which looks for IPV6_TLV_TNL_ENCAP_LIMIT. That inner
>> loop is bounded only by optlen, which can be up to 2048 bytes.
>> Stuffing the Destination Options header with 2046 Pad1 (type=0)
>> entries advances the scanner a single byte at a time, yielding
>> ~2000 TLV iterations per extension header.
>>
>> Reuse max_dst_opts_cnt to bound the TLV iterations, matching
>> the semantics from 47d3d7ac656a.
>>
>> Fixes: 47d3d7ac656a ("ipv6: Implement limits on Hop-by-Hop and Destination options")
>> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
>> ---
>> v1->v2:
>> - Remove unlikely (Justin)
>> - Use abs() given max_dst_opts_cnt's negative meaning (Justin)
>>
>> net/ipv6/ip6_tunnel.c | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
>> index 907c6a2af331..0f50b7fcb24e 100644
>> --- a/net/ipv6/ip6_tunnel.c
>> +++ b/net/ipv6/ip6_tunnel.c
>> @@ -430,11 +430,16 @@ __u16 ip6_tnl_parse_tlv_enc_lim(struct sk_buff *skb, __u8 *raw)
>> break;
>> }
>> if (nexthdr == NEXTHDR_DEST) {
>> + int tlv_max = abs(READ_ONCE(init_net.ipv6.sysctl.max_dst_opts_cnt));
>> + int tlv_cnt = 0;
>> u16 i = 2;
>> while (1) {
>> struct ipv6_tlv_tnl_enc_lim *tel;
>> + if (tlv_cnt++ >= tlv_max)
>> + break;
>> +
>> /* No more room for encapsulation limit */
>> if (i + sizeof(*tel) > optlen)
>> break;
>
> Thanks for v2, Daniel.
>
> I'm still wondering: should we align the above parsing behavior with the one in ip6_parse_tlv() to keep things consistent? That is: don't increment tlv_cnt for Pad1/PadN, make sure we don't exceed 8 bytes per padding (consecutive Pad1's, or a PadN), and we could also check that a PadN payload is only made of zeroes. Open question...
Hm, so it would be sth like the below on top of this one, I'd wish we wouldn't
have to open code another ip6_parse_tlv().
Have you seen such cases with the encap limit in the wild (vs encap limit as
first tlv) where a stack places leading Pad1/PadN before encap limit which the
v2 patch wouldn't catch?
net/ipv6/ip6_tunnel.c | 42 +++++++++++++++++++++++++++++++-----------
1 file changed, 31 insertions(+), 11 deletions(-)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 0f50b7fcb24e..1fa42a1cd97c 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -432,28 +432,48 @@ __u16 ip6_tnl_parse_tlv_enc_lim(struct sk_buff *skb, __u8 *raw)
if (nexthdr == NEXTHDR_DEST) {
int tlv_max = abs(READ_ONCE(init_net.ipv6.sysctl.max_dst_opts_cnt));
int tlv_cnt = 0;
+ int padlen = 0;
u16 i = 2;
- while (1) {
- struct ipv6_tlv_tnl_enc_lim *tel;
+ while (i < optlen) {
+ struct ipv6_tlv_tnl_enc_lim *tel =
+ (struct ipv6_tlv_tnl_enc_lim *)(skb->data + off + i);
+ int tel_len;
- if (tlv_cnt++ >= tlv_max)
+ if (tel->type == IPV6_TLV_PAD1) {
+ if (++padlen > 7)
+ break;
+ i++;
+ continue;
+ }
+
+ if (i + 2 > optlen)
+ break;
+ tel_len = tel->length + 2;
+ if (i + tel_len > optlen)
break;
- /* No more room for encapsulation limit */
- if (i + sizeof(*tel) > optlen)
+ if (tel->type == IPV6_TLV_PADN) {
+ padlen += tel_len;
+ if (padlen > 7)
+ break;
+ if (memchr_inv((u8 *)tel + 2, 0,
+ tel->length))
+ break;
+ i += tel_len;
+ continue;
+ }
+ padlen = 0;
+
+ if (tlv_cnt++ >= tlv_max)
break;
- tel = (struct ipv6_tlv_tnl_enc_lim *)(skb->data + off + i);
/* return index of option if found and valid */
if (tel->type == IPV6_TLV_TNL_ENCAP_LIMIT &&
tel->length == 1)
return i + off - nhoff;
- /* else jump to next option */
- if (tel->type)
- i += tel->length + 2;
- else
- i++;
+
+ i += tel_len;
}
}
nexthdr = hdr->nexthdr;
--
2.43.0
> Otherwise, LGTM:
> Reviewed-by: Justin Iurman <justin.iurman@gmail.com>
Thanks,
Daniel
^ permalink raw reply related
* Re: [PATCH net v2] ipv6: Apply max_dst_opts_cnt to ip6_tnl_parse_tlv_enc_lim
From: Justin Iurman @ 2026-04-18 22:37 UTC (permalink / raw)
To: Daniel Borkmann, kuba
Cc: edumazet, dsahern, tom, willemdebruijn.kernel, idosch, pabeni,
netdev
In-Reply-To: <d8d60970-6f73-4b9d-8808-76f4f8023100@iogearbox.net>
On 4/19/26 00:19, Daniel Borkmann wrote:
> On 4/18/26 2:40 PM, Justin Iurman wrote:
>> On 4/18/26 14:15, Daniel Borkmann wrote:
>>> Commit 47d3d7ac656a ("ipv6: Implement limits on Hop-by-Hop and
>>> Destination options") added net.ipv6.max_{hbh,dst}_opts_{cnt,len}
>>> and applied them in ip6_parse_tlv(), the generic TLV walker
>>> invoked from ipv6_destopt_rcv() and ipv6_parse_hopopts().
>>>
>>> ip6_tnl_parse_tlv_enc_lim() does not go through ip6_parse_tlv();
>>> it has its own hand-rolled TLV scanner inside its NEXTHDR_DEST
>>> branch which looks for IPV6_TLV_TNL_ENCAP_LIMIT. That inner
>>> loop is bounded only by optlen, which can be up to 2048 bytes.
>>> Stuffing the Destination Options header with 2046 Pad1 (type=0)
>>> entries advances the scanner a single byte at a time, yielding
>>> ~2000 TLV iterations per extension header.
>>>
>>> Reuse max_dst_opts_cnt to bound the TLV iterations, matching
>>> the semantics from 47d3d7ac656a.
>>>
>>> Fixes: 47d3d7ac656a ("ipv6: Implement limits on Hop-by-Hop and
>>> Destination options")
>>> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
>>> ---
>>> v1->v2:
>>> - Remove unlikely (Justin)
>>> - Use abs() given max_dst_opts_cnt's negative meaning (Justin)
>>>
>>> net/ipv6/ip6_tunnel.c | 5 +++++
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
>>> index 907c6a2af331..0f50b7fcb24e 100644
>>> --- a/net/ipv6/ip6_tunnel.c
>>> +++ b/net/ipv6/ip6_tunnel.c
>>> @@ -430,11 +430,16 @@ __u16 ip6_tnl_parse_tlv_enc_lim(struct sk_buff
>>> *skb, __u8 *raw)
>>> break;
>>> }
>>> if (nexthdr == NEXTHDR_DEST) {
>>> + int tlv_max =
>>> abs(READ_ONCE(init_net.ipv6.sysctl.max_dst_opts_cnt));
>>> + int tlv_cnt = 0;
>>> u16 i = 2;
>>> while (1) {
>>> struct ipv6_tlv_tnl_enc_lim *tel;
>>> + if (tlv_cnt++ >= tlv_max)
>>> + break;
>>> +
>>> /* No more room for encapsulation limit */
>>> if (i + sizeof(*tel) > optlen)
>>> break;
>>
>> Thanks for v2, Daniel.
>>
>> I'm still wondering: should we align the above parsing behavior with
>> the one in ip6_parse_tlv() to keep things consistent? That is: don't
>> increment tlv_cnt for Pad1/PadN, make sure we don't exceed 8 bytes per
>> padding (consecutive Pad1's, or a PadN), and we could also check that
>> a PadN payload is only made of zeroes. Open question...
>
> Hm, so it would be sth like the below on top of this one, I'd wish we
> wouldn't
> have to open code another ip6_parse_tlv().
>
> Have you seen such cases with the encap limit in the wild (vs encap
> limit as
> first tlv) where a stack places leading Pad1/PadN before encap limit
> which the
> v2 patch wouldn't catch?
Nope. But if it happens, users would be confused as max_dst_opts_cnt
would not have the same meaning in two different code paths. OTOH, I
agree that such situation would look suspicious. I guess it's fine to
keep your patch as is and to not over-complicate things unnecessarily.
> net/ipv6/ip6_tunnel.c | 42 +++++++++++++++++++++++++++++++-----------
> 1 file changed, 31 insertions(+), 11 deletions(-)
>
> diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
> index 0f50b7fcb24e..1fa42a1cd97c 100644
> --- a/net/ipv6/ip6_tunnel.c
> +++ b/net/ipv6/ip6_tunnel.c
> @@ -432,28 +432,48 @@ __u16 ip6_tnl_parse_tlv_enc_lim(struct sk_buff
> *skb, __u8 *raw)
> if (nexthdr == NEXTHDR_DEST) {
> int tlv_max =
> abs(READ_ONCE(init_net.ipv6.sysctl.max_dst_opts_cnt));
> int tlv_cnt = 0;
> + int padlen = 0;
> u16 i = 2;
>
> - while (1) {
> - struct ipv6_tlv_tnl_enc_lim *tel;
> + while (i < optlen) {
> + struct ipv6_tlv_tnl_enc_lim *tel =
> + (struct ipv6_tlv_tnl_enc_lim *)(skb->data + off + i);
> + int tel_len;
>
> - if (tlv_cnt++ >= tlv_max)
> + if (tel->type == IPV6_TLV_PAD1) {
> + if (++padlen > 7)
> + break;
> + i++;
> + continue;
> + }
> +
> + if (i + 2 > optlen)
> + break;
> + tel_len = tel->length + 2;
> + if (i + tel_len > optlen)
> break;
>
> - /* No more room for encapsulation limit */
> - if (i + sizeof(*tel) > optlen)
> + if (tel->type == IPV6_TLV_PADN) {
> + padlen += tel_len;
> + if (padlen > 7)
> + break;
> + if (memchr_inv((u8 *)tel + 2, 0,
> + tel->length))
> + break;
> + i += tel_len;
> + continue;
> + }
> + padlen = 0;
> +
> + if (tlv_cnt++ >= tlv_max)
> break;
>
> - tel = (struct ipv6_tlv_tnl_enc_lim *)(skb->data + off +
> i);
> /* return index of option if found and valid */
> if (tel->type == IPV6_TLV_TNL_ENCAP_LIMIT &&
> tel->length == 1)
> return i + off - nhoff;
> - /* else jump to next option */
> - if (tel->type)
> - i += tel->length + 2;
> - else
> - i++;
> +
> + i += tel_len;
> }
> }
> nexthdr = hdr->nexthdr;
^ 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