* [PATCH net 08/11] netfilter: nf_conntrack_sip: don't use simple_strtoul
From: Pablo Neira Ayuso @ 2026-04-24 19:05 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev, kuba, pabeni, edumazet, fw, horms
In-Reply-To: <20260424190513.32823-1-pablo@netfilter.org>
From: Florian Westphal <fw@strlen.de>
Replace unsafe port parsing in epaddr_len(), ct_sip_parse_header_uri(),
and ct_sip_parse_request() with a new sip_parse_port() helper that
validates each digit against the buffer limit, eliminating the use of
simple_strtoul() which assumes NUL-terminated strings.
The previous code dereferenced pointers without bounds checks after
sip_parse_addr() and relied on simple_strtoul() on non-NUL-terminated
skb data. A port that reaches the buffer limit without a trailing
character is also rejected as malformed.
Also get rid of all simple_strtoul() usage in conntrack, prefer a
stricter version instead. There are intentional changes:
- Bail out if number is > UINT_MAX and indicate a failure, same for
too long sequences.
While we do accept 05535 as port 5535, we will not accept e.g.
'sip:10.0.0.1:005060'. While its syntactically valid under RFC 3261,
we should restrict this to not waste cycles when presented with
malformed packets with 64k '0' characters.
- Force base 10 in ct_sip_parse_numerical_param(). This is used to fetch
'expire=' and 'rports='; both are expected to use base-10.
- In nf_nat_sip.c, only accept the parsed value if its within the 1k-64k
range.
- epaddr_len now returns 0 if the port is invalid, as it already does
for invalid ip addresses. This is intentional. nf_conntrack_sip
performs lots of guesswork to find the right parts of the message
to parse. Being stricter could break existing setups.
Connection tracking helpers are designed to allow traffic to
pass, not to block it.
Based on an earlier patch from Jenny Guanni Qu <qguanni@gmail.com>.
Fixes: 05e3ced297fe ("[NETFILTER]: nf_conntrack_sip: introduce SIP-URI parsing helper")
Reported-by: Klaudia Kloc <klaudia@vidocsecurity.com>
Reported-by: Dawid Moczadło <dawid@vidocsecurity.com>
Reported-by: Jenny Guanni Qu <qguanni@gmail.com>.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nf_conntrack_sip.c | 152 ++++++++++++++++++++++++-------
net/netfilter/nf_nat_sip.c | 1 +
2 files changed, 119 insertions(+), 34 deletions(-)
diff --git a/net/netfilter/nf_conntrack_sip.c b/net/netfilter/nf_conntrack_sip.c
index 182cfb119448..1eb55907d470 100644
--- a/net/netfilter/nf_conntrack_sip.c
+++ b/net/netfilter/nf_conntrack_sip.c
@@ -181,6 +181,57 @@ static int sip_parse_addr(const struct nf_conn *ct, const char *cp,
return 1;
}
+/* Parse optional port number after IP address.
+ * Returns false on malformed input, true otherwise.
+ * If port is non-NULL, stores parsed port in network byte order.
+ * If no port is present, sets *port to default SIP port.
+ */
+static bool sip_parse_port(const char *dptr, const char **endp,
+ const char *limit, __be16 *port)
+{
+ unsigned int p = 0;
+ int len = 0;
+
+ if (dptr >= limit)
+ return false;
+
+ if (*dptr != ':') {
+ if (port)
+ *port = htons(SIP_PORT);
+ if (endp)
+ *endp = dptr;
+ return true;
+ }
+
+ dptr++; /* skip ':' */
+
+ while (dptr < limit && isdigit(*dptr)) {
+ p = p * 10 + (*dptr - '0');
+ dptr++;
+ len++;
+ if (len > 5) /* max "65535" */
+ return false;
+ }
+
+ if (len == 0)
+ return false;
+
+ /* reached limit while parsing port */
+ if (dptr >= limit)
+ return false;
+
+ if (p < 1024 || p > 65535)
+ return false;
+
+ if (port)
+ *port = htons(p);
+
+ if (endp)
+ *endp = dptr;
+
+ return true;
+}
+
/* skip ip address. returns its length. */
static int epaddr_len(const struct nf_conn *ct, const char *dptr,
const char *limit, int *shift)
@@ -193,11 +244,8 @@ static int epaddr_len(const struct nf_conn *ct, const char *dptr,
return 0;
}
- /* Port number */
- if (*dptr == ':') {
- dptr++;
- dptr += digits_len(ct, dptr, limit, shift);
- }
+ if (!sip_parse_port(dptr, &dptr, limit, NULL))
+ return 0;
return dptr - aux;
}
@@ -228,6 +276,51 @@ static int skp_epaddr_len(const struct nf_conn *ct, const char *dptr,
return epaddr_len(ct, dptr, limit, shift);
}
+/* simple_strtoul stops after first non-number character.
+ * But as we're not dealing with c-strings, we can't rely on
+ * hitting \r,\n,\0 etc. before moving past end of buffer.
+ *
+ * This is a variant of simple_strtoul, but doesn't require
+ * a c-string.
+ *
+ * If value exceeds UINT_MAX, 0 is returned.
+ */
+static unsigned int sip_strtouint(const char *cp, unsigned int len, char **endp)
+{
+ const unsigned int max = sizeof("4294967295");
+ unsigned int olen = len;
+ const char *s = cp;
+ u64 result = 0;
+
+ if (len > max)
+ len = max;
+
+ while (olen > 0 && isdigit(*s)) {
+ unsigned int value;
+
+ if (len == 0)
+ goto err;
+
+ value = *s - '0';
+ result = result * 10 + value;
+
+ if (result > UINT_MAX)
+ goto err;
+ s++;
+ len--;
+ olen--;
+ }
+
+ if (endp)
+ *endp = (char *)s;
+
+ return result;
+err:
+ if (endp)
+ *endp = (char *)cp;
+ return 0;
+}
+
/* Parse a SIP request line of the form:
*
* Request-Line = Method SP Request-URI SP SIP-Version CRLF
@@ -241,7 +334,6 @@ int ct_sip_parse_request(const struct nf_conn *ct,
{
const char *start = dptr, *limit = dptr + datalen, *end;
unsigned int mlen;
- unsigned int p;
int shift = 0;
/* Skip method and following whitespace */
@@ -267,14 +359,8 @@ int ct_sip_parse_request(const struct nf_conn *ct,
if (!sip_parse_addr(ct, dptr, &end, addr, limit, true))
return -1;
- if (end < limit && *end == ':') {
- end++;
- p = simple_strtoul(end, (char **)&end, 10);
- if (p < 1024 || p > 65535)
- return -1;
- *port = htons(p);
- } else
- *port = htons(SIP_PORT);
+ if (!sip_parse_port(end, &end, limit, port))
+ return -1;
if (end == dptr)
return 0;
@@ -509,7 +595,6 @@ int ct_sip_parse_header_uri(const struct nf_conn *ct, const char *dptr,
union nf_inet_addr *addr, __be16 *port)
{
const char *c, *limit = dptr + datalen;
- unsigned int p;
int ret;
ret = ct_sip_walk_headers(ct, dptr, dataoff ? *dataoff : 0, datalen,
@@ -520,14 +605,8 @@ int ct_sip_parse_header_uri(const struct nf_conn *ct, const char *dptr,
if (!sip_parse_addr(ct, dptr + *matchoff, &c, addr, limit, true))
return -1;
- if (*c == ':') {
- c++;
- p = simple_strtoul(c, (char **)&c, 10);
- if (p < 1024 || p > 65535)
- return -1;
- *port = htons(p);
- } else
- *port = htons(SIP_PORT);
+ if (!sip_parse_port(c, &c, limit, port))
+ return -1;
if (dataoff)
*dataoff = c - dptr;
@@ -609,7 +688,7 @@ int ct_sip_parse_numerical_param(const struct nf_conn *ct, const char *dptr,
return 0;
start += strlen(name);
- *val = simple_strtoul(start, &end, 0);
+ *val = sip_strtouint(start, limit - start, (char **)&end);
if (start == end)
return -1;
if (matchoff && matchlen) {
@@ -1064,6 +1143,8 @@ static int process_sdp(struct sk_buff *skb, unsigned int protoff,
mediaoff = sdpoff;
for (i = 0; i < ARRAY_SIZE(sdp_media_types); ) {
+ char *end;
+
if (ct_sip_get_sdp_header(ct, *dptr, mediaoff, *datalen,
SDP_HDR_MEDIA, SDP_HDR_UNSPEC,
&mediaoff, &medialen) <= 0)
@@ -1079,8 +1160,8 @@ static int process_sdp(struct sk_buff *skb, unsigned int protoff,
mediaoff += t->len;
medialen -= t->len;
- port = simple_strtoul(*dptr + mediaoff, NULL, 10);
- if (port == 0)
+ port = sip_strtouint(*dptr + mediaoff, *datalen - mediaoff, (char **)&end);
+ if (port == 0 || *dptr + mediaoff == end)
continue;
if (port < 1024 || port > 65535) {
nf_ct_helper_log(skb, ct, "wrong port %u", port);
@@ -1254,7 +1335,7 @@ static int process_register_request(struct sk_buff *skb, unsigned int protoff,
*/
if (ct_sip_get_header(ct, *dptr, 0, *datalen, SIP_HDR_EXPIRES,
&matchoff, &matchlen) > 0)
- expires = simple_strtoul(*dptr + matchoff, NULL, 10);
+ expires = sip_strtouint(*dptr + matchoff, *datalen - matchoff, NULL);
ret = ct_sip_parse_header_uri(ct, *dptr, NULL, *datalen,
SIP_HDR_CONTACT, NULL,
@@ -1358,7 +1439,7 @@ static int process_register_response(struct sk_buff *skb, unsigned int protoff,
if (ct_sip_get_header(ct, *dptr, 0, *datalen, SIP_HDR_EXPIRES,
&matchoff, &matchlen) > 0)
- expires = simple_strtoul(*dptr + matchoff, NULL, 10);
+ expires = sip_strtouint(*dptr + matchoff, *datalen - matchoff, NULL);
while (1) {
unsigned int c_expires = expires;
@@ -1418,10 +1499,12 @@ static int process_sip_response(struct sk_buff *skb, unsigned int protoff,
struct nf_conn *ct = nf_ct_get(skb, &ctinfo);
unsigned int matchoff, matchlen, matchend;
unsigned int code, cseq, i;
+ char *end;
if (*datalen < strlen("SIP/2.0 200"))
return NF_ACCEPT;
- code = simple_strtoul(*dptr + strlen("SIP/2.0 "), NULL, 10);
+ code = sip_strtouint(*dptr + strlen("SIP/2.0 "),
+ *datalen - strlen("SIP/2.0 "), NULL);
if (!code) {
nf_ct_helper_log(skb, ct, "cannot get code");
return NF_DROP;
@@ -1432,8 +1515,8 @@ static int process_sip_response(struct sk_buff *skb, unsigned int protoff,
nf_ct_helper_log(skb, ct, "cannot parse cseq");
return NF_DROP;
}
- cseq = simple_strtoul(*dptr + matchoff, NULL, 10);
- if (!cseq && *(*dptr + matchoff) != '0') {
+ cseq = sip_strtouint(*dptr + matchoff, *datalen - matchoff, (char **)&end);
+ if (*dptr + matchoff == end) {
nf_ct_helper_log(skb, ct, "cannot get cseq");
return NF_DROP;
}
@@ -1482,6 +1565,7 @@ static int process_sip_request(struct sk_buff *skb, unsigned int protoff,
for (i = 0; i < ARRAY_SIZE(sip_handlers); i++) {
const struct sip_handler *handler;
+ char *end;
handler = &sip_handlers[i];
if (handler->request == NULL)
@@ -1498,8 +1582,8 @@ static int process_sip_request(struct sk_buff *skb, unsigned int protoff,
nf_ct_helper_log(skb, ct, "cannot parse cseq");
return NF_DROP;
}
- cseq = simple_strtoul(*dptr + matchoff, NULL, 10);
- if (!cseq && *(*dptr + matchoff) != '0') {
+ cseq = sip_strtouint(*dptr + matchoff, *datalen - matchoff, (char **)&end);
+ if (*dptr + matchoff == end) {
nf_ct_helper_log(skb, ct, "cannot get cseq");
return NF_DROP;
}
@@ -1575,7 +1659,7 @@ static int sip_help_tcp(struct sk_buff *skb, unsigned int protoff,
&matchoff, &matchlen) <= 0)
break;
- clen = simple_strtoul(dptr + matchoff, (char **)&end, 10);
+ clen = sip_strtouint(dptr + matchoff, datalen - matchoff, (char **)&end);
if (dptr + matchoff == end)
break;
diff --git a/net/netfilter/nf_nat_sip.c b/net/netfilter/nf_nat_sip.c
index c845b6d1a2bd..9fbfc6bff0c2 100644
--- a/net/netfilter/nf_nat_sip.c
+++ b/net/netfilter/nf_nat_sip.c
@@ -246,6 +246,7 @@ static unsigned int nf_nat_sip(struct sk_buff *skb, unsigned int protoff,
if (ct_sip_parse_numerical_param(ct, *dptr, matchend, *datalen,
"rport=", &poff, &plen,
&n) > 0 &&
+ n >= 1024 && n <= 65535 &&
htons(n) == ct->tuplehash[dir].tuple.dst.u.udp.port &&
htons(n) != ct->tuplehash[!dir].tuple.src.u.udp.port) {
__be16 p = ct->tuplehash[!dir].tuple.src.u.udp.port;
--
2.47.3
^ permalink raw reply related
* [PATCH net 09/11] ipvs: fixes for the new ip_vs_status info
From: Pablo Neira Ayuso @ 2026-04-24 19:05 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev, kuba, pabeni, edumazet, fw, horms
In-Reply-To: <20260424190513.32823-1-pablo@netfilter.org>
From: Julian Anastasov <ja@ssi.bg>
Sashiko reports some problems for the recently added
/proc/net/ip_vs_status:
* ip_vs_status_show() as a table reader may run long after the
conn_tab and svc_table table are released. While ip_vs_conn_flush()
properly changes the conn_tab_changes counter when conn_tab is removed,
ip_vs_del_service() and ip_vs_flush() were missing such change for
the svc_table_changes counter. As result, readers like
ip_vs_dst_event() and ip_vs_status_show() may continue to use
a freed table after a cond_resched_rcu() call.
* While counting the buckets in ip_vs_status_show() make sure we
traverse only the needed number of entries in the chain. This also
prevents possible overflow of the 'count' variable.
* Add check for 'loops' to prevent infinite loops while restarting
the traversal on table change.
* While IP_VS_CONN_TAB_MAX_BITS is 20 on 32-bit platforms and
there is no risk to overflow when multiplying the number of
conn_tab buckets to 100, prefer the div_u64() helper to make
the following dividing safer.
* Use 0440 permissions for ip_vs_status to restrict the
info only to root due to the exported information for hash
distribution.
Link: https://sashiko.dev/#/patchset/20260410112352.23599-1-fw%40strlen.de
Signed-off-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/ipvs/ip_vs_ctl.c | 51 ++++++++++++++++++++++++----------
1 file changed, 36 insertions(+), 15 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
index 6632daa87ded..27e50afe9a54 100644
--- a/net/netfilter/ipvs/ip_vs_ctl.c
+++ b/net/netfilter/ipvs/ip_vs_ctl.c
@@ -2032,6 +2032,9 @@ static int ip_vs_del_service(struct ip_vs_service *svc)
cancel_delayed_work_sync(&ipvs->svc_resize_work);
if (t) {
rcu_assign_pointer(ipvs->svc_table, NULL);
+ /* Inform readers that table is removed */
+ smp_mb__before_atomic();
+ atomic_inc(&ipvs->svc_table_changes);
while (1) {
p = rcu_dereference_protected(t->new_tbl, 1);
call_rcu(&t->rcu_head, ip_vs_rht_rcu_free);
@@ -2078,6 +2081,9 @@ static int ip_vs_flush(struct netns_ipvs *ipvs, bool cleanup)
t = rcu_dereference_protected(ipvs->svc_table, 1);
if (t) {
rcu_assign_pointer(ipvs->svc_table, NULL);
+ /* Inform readers that table is removed */
+ smp_mb__before_atomic();
+ atomic_inc(&ipvs->svc_table_changes);
while (1) {
p = rcu_dereference_protected(t->new_tbl, 1);
call_rcu(&t->rcu_head, ip_vs_rht_rcu_free);
@@ -3004,7 +3010,8 @@ static int ip_vs_status_show(struct seq_file *seq, void *v)
int old_gen, new_gen;
u32 counts[8];
u32 bucket;
- int count;
+ u32 count;
+ int loops;
u32 sum1;
u32 sum;
int i;
@@ -3020,6 +3027,7 @@ static int ip_vs_status_show(struct seq_file *seq, void *v)
if (!atomic_read(&ipvs->conn_count))
goto after_conns;
old_gen = atomic_read(&ipvs->conn_tab_changes);
+ loops = 0;
repeat_conn:
smp_rmb(); /* ipvs->conn_tab and conn_tab_changes */
@@ -3032,8 +3040,11 @@ static int ip_vs_status_show(struct seq_file *seq, void *v)
resched_score++;
ip_vs_rht_walk_bucket_rcu(t, bucket, head) {
count = 0;
- hlist_bl_for_each_entry_rcu(hn, e, head, node)
+ hlist_bl_for_each_entry_rcu(hn, e, head, node) {
count++;
+ if (count >= ARRAY_SIZE(counts) - 1)
+ break;
+ }
}
resched_score += count;
if (resched_score >= 100) {
@@ -3042,37 +3053,41 @@ static int ip_vs_status_show(struct seq_file *seq, void *v)
new_gen = atomic_read(&ipvs->conn_tab_changes);
/* New table installed ? */
if (old_gen != new_gen) {
+ /* Too many changes? */
+ if (++loops >= 5)
+ goto after_conns;
old_gen = new_gen;
goto repeat_conn;
}
}
- counts[min(count, (int)ARRAY_SIZE(counts) - 1)]++;
+ counts[count]++;
}
}
for (sum = 0, i = 0; i < ARRAY_SIZE(counts); i++)
sum += counts[i];
sum1 = sum - counts[0];
- seq_printf(seq, "Conn buckets empty:\t%u (%lu%%)\n",
- counts[0], (unsigned long)counts[0] * 100 / max(sum, 1U));
+ seq_printf(seq, "Conn buckets empty:\t%u (%llu%%)\n",
+ counts[0], div_u64((u64)counts[0] * 100U, max(sum, 1U)));
for (i = 1; i < ARRAY_SIZE(counts); i++) {
if (!counts[i])
continue;
- seq_printf(seq, "Conn buckets len-%d:\t%u (%lu%%)\n",
+ seq_printf(seq, "Conn buckets len-%d:\t%u (%llu%%)\n",
i, counts[i],
- (unsigned long)counts[i] * 100 / max(sum1, 1U));
+ div_u64((u64)counts[i] * 100U, max(sum1, 1U)));
}
after_conns:
t = rcu_dereference(ipvs->svc_table);
count = ip_vs_get_num_services(ipvs);
- seq_printf(seq, "Services:\t%d\n", count);
+ seq_printf(seq, "Services:\t%u\n", count);
seq_printf(seq, "Service buckets:\t%d (%d bits, lfactor %d)\n",
t ? t->size : 0, t ? t->bits : 0, t ? t->lfactor : 0);
if (!count)
goto after_svc;
old_gen = atomic_read(&ipvs->svc_table_changes);
+ loops = 0;
repeat_svc:
smp_rmb(); /* ipvs->svc_table and svc_table_changes */
@@ -3086,8 +3101,11 @@ static int ip_vs_status_show(struct seq_file *seq, void *v)
ip_vs_rht_walk_bucket_rcu(t, bucket, head) {
count = 0;
hlist_bl_for_each_entry_rcu(svc, e, head,
- s_list)
+ s_list) {
count++;
+ if (count >= ARRAY_SIZE(counts) - 1)
+ break;
+ }
}
resched_score += count;
if (resched_score >= 100) {
@@ -3096,24 +3114,27 @@ static int ip_vs_status_show(struct seq_file *seq, void *v)
new_gen = atomic_read(&ipvs->svc_table_changes);
/* New table installed ? */
if (old_gen != new_gen) {
+ /* Too many changes? */
+ if (++loops >= 5)
+ goto after_svc;
old_gen = new_gen;
goto repeat_svc;
}
}
- counts[min(count, (int)ARRAY_SIZE(counts) - 1)]++;
+ counts[count]++;
}
}
for (sum = 0, i = 0; i < ARRAY_SIZE(counts); i++)
sum += counts[i];
sum1 = sum - counts[0];
- seq_printf(seq, "Service buckets empty:\t%u (%lu%%)\n",
- counts[0], (unsigned long)counts[0] * 100 / max(sum, 1U));
+ seq_printf(seq, "Service buckets empty:\t%u (%llu%%)\n",
+ counts[0], div_u64((u64)counts[0] * 100U, max(sum, 1U)));
for (i = 1; i < ARRAY_SIZE(counts); i++) {
if (!counts[i])
continue;
- seq_printf(seq, "Service buckets len-%d:\t%u (%lu%%)\n",
+ seq_printf(seq, "Service buckets len-%d:\t%u (%llu%%)\n",
i, counts[i],
- (unsigned long)counts[i] * 100 / max(sum1, 1U));
+ div_u64((u64)counts[i] * 100U, max(sum1, 1U)));
}
after_svc:
@@ -5039,7 +5060,7 @@ int __net_init ip_vs_control_net_init(struct netns_ipvs *ipvs)
ipvs->net->proc_net,
ip_vs_stats_percpu_show, NULL))
goto err_percpu;
- if (!proc_create_net_single("ip_vs_status", 0, ipvs->net->proc_net,
+ if (!proc_create_net_single("ip_vs_status", 0440, ipvs->net->proc_net,
ip_vs_status_show, NULL))
goto err_status;
#endif
--
2.47.3
^ permalink raw reply related
* [PATCH net 10/11] ipvs: fix races around the conn_lfactor and svc_lfactor sysctl vars
From: Pablo Neira Ayuso @ 2026-04-24 19:05 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev, kuba, pabeni, edumazet, fw, horms
In-Reply-To: <20260424190513.32823-1-pablo@netfilter.org>
From: Julian Anastasov <ja@ssi.bg>
Sashiko warns that the new sysctls vars can be changed
after the hash tables are destroyed and their respective
resizing works canceled, leading to mod_delayed_work()
being called for canceled works.
Solve this in different ways. conn_tab can be present even
without services and is destroyed only on netns exit, so use
disable_delayed_work_sync() to disable the work instead of
adding more synchronization mechanisms.
As for the svc_table, it is destroyed when the services
are deleted, so we must be sure that netns exit is not
called yet (the check for 'enable') and the work is
not canceled by checking all under same mutex lock.
Also, use WRITE_ONCE when updating the sysctl vars as we
already read them with READ_ONCE.
Link: https://sashiko.dev/#/patchset/20260410112352.23599-1-fw%40strlen.de
Signed-off-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/ipvs/ip_vs_conn.c | 2 +-
net/netfilter/ipvs/ip_vs_ctl.c | 12 +++++++++---
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_conn.c b/net/netfilter/ipvs/ip_vs_conn.c
index 2082bfb2d93c..84a4921a7865 100644
--- a/net/netfilter/ipvs/ip_vs_conn.c
+++ b/net/netfilter/ipvs/ip_vs_conn.c
@@ -1835,7 +1835,7 @@ static void ip_vs_conn_flush(struct netns_ipvs *ipvs)
if (!rcu_dereference_protected(ipvs->conn_tab, 1))
return;
- cancel_delayed_work_sync(&ipvs->conn_resize_work);
+ disable_delayed_work_sync(&ipvs->conn_resize_work);
if (!atomic_read(&ipvs->conn_count))
goto unreg;
diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
index 27e50afe9a54..caec516856e9 100644
--- a/net/netfilter/ipvs/ip_vs_ctl.c
+++ b/net/netfilter/ipvs/ip_vs_ctl.c
@@ -2469,7 +2469,7 @@ static int ipvs_proc_conn_lfactor(const struct ctl_table *table, int write,
if (val < -8 || val > 8) {
ret = -EINVAL;
} else {
- *valp = val;
+ WRITE_ONCE(*valp, val);
if (rcu_access_pointer(ipvs->conn_tab))
mod_delayed_work(system_unbound_wq,
&ipvs->conn_resize_work, 0);
@@ -2496,10 +2496,16 @@ static int ipvs_proc_svc_lfactor(const struct ctl_table *table, int write,
if (val < -8 || val > 8) {
ret = -EINVAL;
} else {
- *valp = val;
- if (rcu_access_pointer(ipvs->svc_table))
+ mutex_lock(&ipvs->service_mutex);
+ WRITE_ONCE(*valp, val);
+ /* Make sure the services are present */
+ if (rcu_access_pointer(ipvs->svc_table) &&
+ READ_ONCE(ipvs->enable) &&
+ !test_bit(IP_VS_WORK_SVC_NORESIZE,
+ &ipvs->work_flags))
mod_delayed_work(system_unbound_wq,
&ipvs->svc_resize_work, 0);
+ mutex_unlock(&ipvs->service_mutex);
}
}
return ret;
--
2.47.3
^ permalink raw reply related
* [PATCH net 11/11] ipvs: fix the spin_lock usage for RT build
From: Pablo Neira Ayuso @ 2026-04-24 19:05 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev, kuba, pabeni, edumazet, fw, horms
In-Reply-To: <20260424190513.32823-1-pablo@netfilter.org>
From: Julian Anastasov <ja@ssi.bg>
syzbot reports for sleeping function called from invalid context [1].
The recently added code for resizable hash tables uses
hlist_bl bit locks in combination with spin_lock for
the connection fields (cp->lock).
Fix the following problems:
* avoid using spin_lock(&cp->lock) under locked bit lock
because it sleeps on PREEMPT_RT
* as the recent changes call ip_vs_conn_hash() only for newly
allocated connection, the spin_lock can be removed there because
the connection is still not linked to table and does not need
cp->lock protection.
* the lock can be removed also from ip_vs_conn_unlink() where we
are the last connection user.
* the last place that is fixed is ip_vs_conn_fill_cport()
where now the cp->lock is locked before the other locks to
ensure other packets do not modify the cp->flags in non-atomic
way. Here we make sure cport and flags are changed only once
if two or more packets race to fill the cport. Also, we fill
cport early, so that if we race with resizing there will be
valid cport key for the hashing. Add a warning if too many
hash table changes occur for our RCU read-side critical
section which is error condition but minor because the
connection still can expire gracefully. Problems reported
by Sashiko.
[1]:
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 16, name: ktimers/0
preempt_count: 2, expected: 0
RCU nest depth: 3, expected: 3
8 locks held by ktimers/0/16:
#0: ffffffff8de5f260 (local_bh){.+.+}-{1:3}, at: __local_bh_disable_ip+0x3c/0x420 kernel/softirq.c:163
#1: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: __local_bh_disable_ip+0x3c/0x420 kernel/softirq.c:163
#2: ffff8880b8826360 (&base->expiry_lock){+...}-{3:3}, at: spin_lock include/linux/spinlock_rt.h:45 [inline]
#2: ffff8880b8826360 (&base->expiry_lock){+...}-{3:3}, at: timer_base_lock_expiry kernel/time/timer.c:1502 [inline]
#2: ffff8880b8826360 (&base->expiry_lock){+...}-{3:3}, at: __run_timer_base+0x120/0x9f0 kernel/time/timer.c:2384
#3: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:300 [inline]
#3: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:838 [inline]
#3: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: __rt_spin_lock kernel/locking/spinlock_rt.c:50 [inline]
#3: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: rt_spin_lock+0x1e0/0x400 kernel/locking/spinlock_rt.c:57
#4: ffffc90000157a80 ((&cp->timer)){+...}-{0:0}, at: call_timer_fn+0xd4/0x5e0 kernel/time/timer.c:1745
#5: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:300 [inline]
#5: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:838 [inline]
#5: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: ip_vs_conn_unlink net/netfilter/ipvs/ip_vs_conn.c:315 [inline]
#5: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: ip_vs_conn_expire+0x257/0x2390 net/netfilter/ipvs/ip_vs_conn.c:1260
#6: ffffffff8de5f260 (local_bh){.+.+}-{1:3}, at: __local_bh_disable_ip+0x3c/0x420 kernel/softirq.c:163
#7: ffff888068d4c3f0 (&cp->lock#2){+...}-{3:3}, at: spin_lock include/linux/spinlock_rt.h:45 [inline]
#7: ffff888068d4c3f0 (&cp->lock#2){+...}-{3:3}, at: ip_vs_conn_unlink net/netfilter/ipvs/ip_vs_conn.c:324 [inline]
#7: ffff888068d4c3f0 (&cp->lock#2){+...}-{3:3}, at: ip_vs_conn_expire+0xd4a/0x2390 net/netfilter/ipvs/ip_vs_conn.c:1260
Preemption disabled at:
[<ffffffff898a6358>] bit_spin_lock include/linux/bit_spinlock.h:38 [inline]
[<ffffffff898a6358>] hlist_bl_lock+0x18/0x110 include/linux/list_bl.h:149
CPU: 0 UID: 0 PID: 16 Comm: ktimers/0 Tainted: G W L syzkaller #0 PREEMPT_{RT,(full)}
Tainted: [W]=WARN, [L]=SOFTLOCKUP
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/18/2026
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
__might_resched+0x329/0x480 kernel/sched/core.c:9162
__rt_spin_lock kernel/locking/spinlock_rt.c:48 [inline]
rt_spin_lock+0xc2/0x400 kernel/locking/spinlock_rt.c:57
spin_lock include/linux/spinlock_rt.h:45 [inline]
ip_vs_conn_unlink net/netfilter/ipvs/ip_vs_conn.c:324 [inline]
ip_vs_conn_expire+0xd4a/0x2390 net/netfilter/ipvs/ip_vs_conn.c:1260
call_timer_fn+0x192/0x5e0 kernel/time/timer.c:1748
expire_timers kernel/time/timer.c:1799 [inline]
__run_timers kernel/time/timer.c:2374 [inline]
__run_timer_base+0x6a3/0x9f0 kernel/time/timer.c:2386
run_timer_base kernel/time/timer.c:2395 [inline]
run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2405
handle_softirqs+0x1de/0x6d0 kernel/softirq.c:622
__do_softirq kernel/softirq.c:656 [inline]
run_ktimerd+0x69/0x100 kernel/softirq.c:1151
smpboot_thread_fn+0x541/0xa50 kernel/smpboot.c:160
kthread+0x388/0x470 kernel/kthread.c:436
ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
Reported-by: syzbot+504e778ddaecd36fdd17@syzkaller.appspotmail.com
Link: https://sashiko.dev/#/patchset/20260415200216.79699-1-ja%40ssi.bg
Link: https://sashiko.dev/#/patchset/20260420165539.85174-4-ja%40ssi.bg
Link: https://sashiko.dev/#/patchset/20260422135823.50489-4-ja%40ssi.bg
Fixes: 2fa7cc9c7025 ("ipvs: switch to per-net connection table")
Signed-off-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/ipvs/ip_vs_conn.c | 69 +++++++++++++++++----------------
1 file changed, 36 insertions(+), 33 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_conn.c b/net/netfilter/ipvs/ip_vs_conn.c
index 84a4921a7865..9e23cda84825 100644
--- a/net/netfilter/ipvs/ip_vs_conn.c
+++ b/net/netfilter/ipvs/ip_vs_conn.c
@@ -267,27 +267,20 @@ static inline int ip_vs_conn_hash(struct ip_vs_conn *cp)
hash_key2 = hash_key;
use2 = false;
}
+
conn_tab_lock(t, cp, hash_key, hash_key2, use2, true /* new_hash */,
&head, &head2);
- spin_lock(&cp->lock);
-
- if (!(cp->flags & IP_VS_CONN_F_HASHED)) {
- cp->flags |= IP_VS_CONN_F_HASHED;
- WRITE_ONCE(cp->hn0.hash_key, hash_key);
- WRITE_ONCE(cp->hn1.hash_key, hash_key2);
- refcount_inc(&cp->refcnt);
- hlist_bl_add_head_rcu(&cp->hn0.node, head);
- if (use2)
- hlist_bl_add_head_rcu(&cp->hn1.node, head2);
- ret = 1;
- } else {
- pr_err("%s(): request for already hashed, called from %pS\n",
- __func__, __builtin_return_address(0));
- ret = 0;
- }
- spin_unlock(&cp->lock);
+ cp->flags |= IP_VS_CONN_F_HASHED;
+ WRITE_ONCE(cp->hn0.hash_key, hash_key);
+ WRITE_ONCE(cp->hn1.hash_key, hash_key2);
+ refcount_inc(&cp->refcnt);
+ hlist_bl_add_head_rcu(&cp->hn0.node, head);
+ if (use2)
+ hlist_bl_add_head_rcu(&cp->hn1.node, head2);
+
conn_tab_unlock(head, head2);
+ ret = 1;
/* Schedule resizing if load increases */
if (atomic_read(&ipvs->conn_count) > t->u_thresh &&
@@ -321,7 +314,6 @@ static inline bool ip_vs_conn_unlink(struct ip_vs_conn *cp)
conn_tab_lock(t, cp, hash_key, hash_key2, use2, false /* new_hash */,
&head, &head2);
- spin_lock(&cp->lock);
if (cp->flags & IP_VS_CONN_F_HASHED) {
/* Decrease refcnt and unlink conn only if we are last user */
@@ -334,7 +326,6 @@ static inline bool ip_vs_conn_unlink(struct ip_vs_conn *cp)
}
}
- spin_unlock(&cp->lock);
conn_tab_unlock(head, head2);
rcu_read_unlock();
@@ -637,6 +628,7 @@ void ip_vs_conn_fill_cport(struct ip_vs_conn *cp, __be16 cport)
struct ip_vs_conn_hnode *hn;
u32 hash_key, hash_key_new;
struct ip_vs_conn_param p;
+ bool by_me = false;
int ntbl;
int dir;
@@ -664,8 +656,11 @@ void ip_vs_conn_fill_cport(struct ip_vs_conn *cp, __be16 cport)
t = rcu_dereference(t->new_tbl);
ntbl++;
/* We are lost? */
- if (ntbl >= 2)
+ if (ntbl >= 2) {
+ IP_VS_ERR_RL("%s(): Too many ht changes for dir %d\n",
+ __func__, dir);
return;
+ }
}
/* Rehashing during resize? Use the recent table for adds */
@@ -683,10 +678,13 @@ void ip_vs_conn_fill_cport(struct ip_vs_conn *cp, __be16 cport)
if (head > head2 && t == t2)
swap(head, head2);
+ /* Protect the cp->flags modification */
+ spin_lock_bh(&cp->lock);
+
/* Lock seqcount only for the old bucket, even if we are on new table
* because it affects the del operation, not the adding.
*/
- spin_lock_bh(&t->lock[hash_key & t->lock_mask].l);
+ spin_lock(&t->lock[hash_key & t->lock_mask].l);
preempt_disable_nested();
write_seqcount_begin(&t->seqc[hash_key & t->seqc_mask]);
@@ -704,14 +702,23 @@ void ip_vs_conn_fill_cport(struct ip_vs_conn *cp, __be16 cport)
hlist_bl_unlock(head);
write_seqcount_end(&t->seqc[hash_key & t->seqc_mask]);
preempt_enable_nested();
- spin_unlock_bh(&t->lock[hash_key & t->lock_mask].l);
+ spin_unlock(&t->lock[hash_key & t->lock_mask].l);
+ spin_unlock_bh(&cp->lock);
hash_key = hash_key_new;
goto retry;
}
- spin_lock(&cp->lock);
- if ((cp->flags & IP_VS_CONN_F_NO_CPORT) &&
- (cp->flags & IP_VS_CONN_F_HASHED)) {
+ /* Fill cport once, even if multiple packets try to do it */
+ if (cp->flags & IP_VS_CONN_F_NO_CPORT && (!cp->cport || by_me)) {
+ /* If we race with resizing make sure cport is set for dir 1 */
+ if (!cp->cport) {
+ cp->cport = cport;
+ by_me = true;
+ }
+ if (!dir) {
+ atomic_dec(&ipvs->no_cport_conns[af_id]);
+ cp->flags &= ~IP_VS_CONN_F_NO_CPORT;
+ }
/* We do not recalc hash_key_r under lock, we assume the
* parameters in cp do not change, i.e. cport is
* the only possible change.
@@ -726,21 +733,17 @@ void ip_vs_conn_fill_cport(struct ip_vs_conn *cp, __be16 cport)
hlist_bl_del_rcu(&hn->node);
hlist_bl_add_head_rcu(&hn->node, head_new);
}
- if (!dir) {
- atomic_dec(&ipvs->no_cport_conns[af_id]);
- cp->flags &= ~IP_VS_CONN_F_NO_CPORT;
- cp->cport = cport;
- }
}
- spin_unlock(&cp->lock);
if (head != head2)
hlist_bl_unlock(head2);
hlist_bl_unlock(head);
write_seqcount_end(&t->seqc[hash_key & t->seqc_mask]);
preempt_enable_nested();
- spin_unlock_bh(&t->lock[hash_key & t->lock_mask].l);
- if (dir--)
+ spin_unlock(&t->lock[hash_key & t->lock_mask].l);
+
+ spin_unlock_bh(&cp->lock);
+ if (dir-- && by_me)
goto next_dir;
}
--
2.47.3
^ permalink raw reply related
* [PATCH bpf] bpf, sockmap: reject overflowing copy + len in bpf_msg_push_data()
From: Weiming Shi @ 2026-04-24 19:16 UTC (permalink / raw)
To: Martin KaFai Lau, Daniel Borkmann, Alexei Starovoitov,
Andrii Nakryiko, Eduard Zingerman, Kumar Kartikeya Dwivedi,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: John Fastabend, Stanislav Fomichev, Song Liu, Yonghong Song,
Jiri Olsa, Simon Horman, bpf, netdev, Xiang Mei, Weiming Shi,
Xinyu Ma
When the scatterlist ring is full or nearly full, bpf_msg_push_data()
enters a copy fallback path and computes copy + len for the page
allocation size. Since len comes from BPF with arg3_type = ARG_ANYTHING
and both are u32, a crafted len can wrap the sum to a small value,
causing an undersized allocation followed by an out-of-bounds memcpy.
BUG: unable to handle page fault for address: ffffed104089a402
Oops: Oops: 0000 [#1] SMP KASAN NOPTI
Call Trace:
__asan_memcpy (mm/kasan/shadow.c:105)
bpf_msg_push_data (net/core/filter.c:2852 net/core/filter.c:2788)
bpf_prog_9ed8b5711920a7d7+0x2e/0x36
sk_psock_msg_verdict (net/core/skmsg.c:934)
tcp_bpf_sendmsg (net/ipv4/tcp_bpf.c:421 net/ipv4/tcp_bpf.c:584)
__sys_sendto (net/socket.c:2206)
do_syscall_64 (arch/x86/entry/syscall_64.c:94)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
Add an overflow check before the allocation.
Link: https://lore.kernel.org/all/20260424155913.A19FDC19425@smtp.kernel.org
Fixes: 6fff607e2f14 ("bpf: sk_msg program helper bpf_msg_push_data")
Tested-by: Xiang Mei <xmei5@asu.edu>
Tested-by: Xinyu Ma <mmmxny@gmail.com>
Signed-off-by: Weiming Shi <bestswngs@gmail.com>
---
net/core/filter.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/core/filter.c b/net/core/filter.c
index bc96c18df4e0..4f5a00ade2d3 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -2820,6 +2820,9 @@ BPF_CALL_4(bpf_msg_push_data, struct sk_msg *, msg, u32, start,
if (!space || (space == 1 && start != offset))
copy = msg->sg.data[i].length;
+ if (unlikely(copy + len < copy))
+ return -EINVAL;
+
page = alloc_pages(__GFP_NOWARN | GFP_ATOMIC | __GFP_COMP,
get_order(copy + len));
if (unlikely(!page))
--
2.43.0
^ permalink raw reply related
* Re: [PATCH iproute2-next] utils: add fflush_monitor() helper
From: David Ahern @ 2026-04-24 19:30 UTC (permalink / raw)
To: Eric Dumazet, Stephen Hemminger
Cc: David S . Miller, Jakub Kicinski, Paolo Abeni, Kuniyuki Iwashima,
netdev, eric.dumazet
In-Reply-To: <20260424171151.1190882-1-edumazet@google.com>
On 4/24/26 11:11 AM, Eric Dumazet wrote:
> @@ -399,4 +400,10 @@ FILE *generic_proc_open(const char *env, const char *name);
> int open_fds_add(int fd);
> void open_fds_close(void);
>
> +static inline void fflush_monitor(FILE *fp)
> +{
> + if (monitor_mode)
> + fflush_monitor(fp);
Circular call?
> +}
> +
> #endif /* __UTILS_H__ */
^ permalink raw reply
* Re: [bug report] Potential order bug in 'net/xfrm/xfrm_state.c', primarily in 'xfrm_state_walk_done()'
From: Florian Westphal @ 2026-04-24 19:31 UTC (permalink / raw)
To: Ginger; +Cc: steffen.klassert, netdev, linux-kernel
In-Reply-To: <CAGp+u1autEHVxgs1pdqxz0kwExuKE3+XmQOtTC5bv-R7WU8nBw@mail.gmail.com>
Ginger <ginger.jzllee@gmail.com> wrote:
> Potential concurrent triggering executions:
> T0:
> xfrm_state_walk_done
> --> kfree(walk->filter); [t0]
> --> list_del(&walk->all); [t3]
list_del() uses same spinlock as iterator.
> T1:
> xfrm_state_walk
2652 int xfrm_state_walk(struct net *net, struct xfrm_state_walk *walk,
2653 int (*func)(struct xfrm_state *, int, void*),
2654 void *data)
2655 {
[..]
2663 spin_lock_bh(&net->xfrm.xfrm_state_lock);
2668 list_for_each_entry_from(x, &net->xfrm.state_all, all) {
2669 if (x->state == XFRM_STATE_DEAD)
2670 continue;
... and walker has STATE_DEAD, no? So I don't see how UaF is possible.
Even if parallel invocation (pfkey+netlink?) is possible, then we have:
T0: walk_done() -> free filter -> blocks on spinlock for list_del
T1: list_for_each ... -> walker is valid memory, checks x->state -> SKIP
to next entry
(or list_del already finished, but then _walk() is blocked on
spinlock).
^ permalink raw reply
* Re: [PATCH net-next v6 0/2] net: mana: add ethtool private flag for full-page RX buffers
From: David Wei @ 2026-04-24 20:05 UTC (permalink / raw)
To: Dipayaan Roy, Jakub Kicinski
Cc: kys, haiyangz, wei.liu, decui, andrew+netdev, davem, edumazet,
pabeni, leon, longli, kotaranov, horms, shradhagupta, ssengar,
ernis, shirazsaleem, linux-hyperv, netdev, linux-kernel,
linux-rdma, stephen, jacob.e.keller, leitao, kees, john.fastabend,
hawk, bpf, daniel, ast, sdf, dipayanroy
In-Reply-To: <aeoVC27mIzoKytqA@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
On 2026-04-23 05:48, Dipayaan Roy wrote:
> On Thu, Apr 16, 2026 at 08:31:46AM -0700, Jakub Kicinski wrote:
>> On Tue, 14 Apr 2026 09:00:56 -0700 Dipayaan Roy wrote:
>>> I still see roughly a 5% overhead from the atomic refcount operation
>>> itself, but on that platform there is no throughput drop when using
>>> page fragments versus full-page mode.
>>
>> That seems to contradict your claim that it's a problem with a specific
>> platform.. Since we're in the merge window I asked David Wei to try to
>> experiment with disabling page fragmentation on the ARM64 platforms we
>> have at Meta. If it repros we should use the generic rx-buf-len
>> ringparam because more NICs may want to implement this strategy.
>
> Hi Jakub,
>
> Thanks. I think I was not precise enough in my previous reply.
>
> What I meant is that the atomic refcount cost itself does not appear to
> be unique to the affected platform. I see a similar ~5% overhead on
> another ARM64 platformi (different vendor) as well. However, on that platform
> there is no throughput delta between fragment mode and full-page mode; both reach
> line rate.
>
> On the affected platform, fragment mode shows an additional ~15%
> throughput drop versus full-page mode. So the current data suggests that
> the atomic overhead is common, but the throughput regression is not
> explained by that overhead alone and likely depends on an additional
> platform-specific factor.
>
> Separately, the hardware team collected PCIe traces on the affected
> platform and reported stalls in the fragment-mode case that are not seen
> in full-page mode. They are still investigating the root cause, but
> their current hypothesis is that this is related to that platform’s
> PCIe/root-port microarchitecture rather than to page_pool refcounting
> alone.
>
> That said, I agree the right direction depends on whether this
> reproduces on other ARM64 platforms. If David is able to reproduce the
> same behavior, then using the generic rx-buf-len ringparam sounds like
> the better direction.
>
> Please let me know what David finds, and I can rework the patch
> accordingly.
I ran a test on Grace, 4 KB pages, 72 cores, 1 NUMA node.
Broadcom NIC, bnxt driver, 50 Gbps bandwidth. Hacked it up to either
give me 1 or 2 frags per page. No agg ring, no HDS, no HW GRO.
Use 1 combined queue only for the server. Affinitized its net rx softirq
to run on core 4.
Ran iperf3 server, taskset onto cpu cores 32-47. The iperf3 client is
running on a host w/ same hw in the same region. Using 32 queues, no
softirq affinities. The idea is to hammer page->pp_ref_count from
different cores.
* 1 frag/page -> 32.3 Gbps
* 2 frags/page -> 36.0 Gbps
Comparing perf, for 2 frags/page the cost of skb_release_data() hitting
pp_ref_count goes up, as expected. Is this what you see? When you say
there's a +5% overhead, what function?
Overall tput is higher with multiple frags. That's to be expected w/
page pool.
There are some 200 Gbps NICs but they're mlx5 so I'd have to redo the
driver hack. Are you going to re-implement this change with rx-buf-len
instead of a private flag? If so, I won't spend more time running this
test.
>
>
> Regards
> Dipayaan Roy
^ permalink raw reply
* Re: [PATCH net v8 4/6] net/sched: netem: validate slot configuration
From: Jamal Hadi Salim @ 2026-04-24 20:17 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Paolo Abeni, netdev, jiri, David S. Miller, Eric Dumazet,
Jakub Kicinski, Dave Taht, open list, Simon Horman
In-Reply-To: <20260424080700.6846dfcb@phoenix.local>
() ncalls s
On Fri, Apr 24, 2026 at 11:07 AM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> On Thu, 23 Apr 2026 17:12:15 -0400
> Jamal Hadi Salim <jhs@mojatatu.com> wrote:
>
> > > > This is intended and explicitly explained in the cover letter.
> > > Jamal, given the uAPI implication, could you please double check that
> > > the change is fine?
> > >
> >
> > It should be fine; at least iproute2 will never allow the kernel to
> > receive a negative number.
> > Stephen brought up the fact that strtod() could return a -ve number
> > (but at least iproute2 makes sure negative numbers are not carried
> > forward to the kernel).
> >
> > cheers,
> > jamal
>
> Iproute2 blocks negative values kind of by accident.
> The NEXT_IS_NUMBER() macro looks for digit at start of arg.
> To hit this you need to either use raw netlink or change NEXT_IS_NUMBER()
> to NEXT_IS_SIGNED_NUMBER() where slot values are parsed.
For this specific attribute it was intentional:
...
if (get_time64(&slot.dist_jitter, *argv)) { //get_time64 calls
strtod() which could set dist_jitter -ve
explain1("slot jitter");
return -1;
}
if (slot.dist_jitter <= 0) { // we reject -ve values
fprintf(stderr, "Non-positive jitter\n");
return -1;
}
cheers,
jamal
^ permalink raw reply
* [syzbot ci] Re: vsock/virtio: fix memory leak in virtio_transport_recv_listen()
From: syzbot ci @ 2026-04-24 20:17 UTC (permalink / raw)
To: davem, edumazet, eperezma, horms, jasowang, kartikey406, kuba,
kvm, linux-kernel, mst, netdev, pabeni, sgarzare, stefanha,
syzbot, virtualization, xuanzhuo
Cc: syzbot, syzkaller-bugs
In-Reply-To: <20260424150310.57228-1-kartikey406@gmail.com>
syzbot ci has tested the following series
[v1] vsock/virtio: fix memory leak in virtio_transport_recv_listen()
https://lore.kernel.org/all/20260424150310.57228-1-kartikey406@gmail.com
* [PATCH] vsock/virtio: fix memory leak in virtio_transport_recv_listen()
and found the following issue:
possible deadlock in virtio_transport_recv_listen
Full report is available here:
https://ci.syzbot.org/series/e5f3f5f1-8e83-492f-833b-dc526b61d0ef
***
possible deadlock in virtio_transport_recv_listen
tree: net-next
URL: https://kernel.googlesource.com/pub/scm/linux/kernel/git/netdev/net-next.git
base: e728258debd553c95d2e70f9cd97c9fde27c7130
arch: amd64
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
config: https://ci.syzbot.org/builds/bcc67f3f-b441-4d11-8573-f26ca268da65/config
syz repro: https://ci.syzbot.org/findings/fce9fa9b-692a-420c-956f-12c7e6d75e2e/syz_repro
============================================
WARNING: possible recursive locking detected
syzkaller #0 Not tainted
--------------------------------------------
kworker/1:5/6007 is trying to acquire lock:
ffff88817492e2a0 (sk_lock-AF_VSOCK){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1713 [inline]
ffff88817492e2a0 (sk_lock-AF_VSOCK){+.+.}-{0:0}, at: virtio_transport_recv_listen+0x13a5/0x2230 net/vmw_vsock/virtio_transport_common.c:1593
but task is already holding lock:
ffff88817492e2a0 (sk_lock-AF_VSOCK){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1713 [inline]
ffff88817492e2a0 (sk_lock-AF_VSOCK){+.+.}-{0:0}, at: virtio_transport_recv_pkt+0xfde/0x2bb0 net/vmw_vsock/virtio_transport_common.c:1671
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(sk_lock-AF_VSOCK);
lock(sk_lock-AF_VSOCK);
*** DEADLOCK ***
May be due to missing lock nesting notation
3 locks held by kworker/1:5/6007:
#0: ffff888112391940 ((wq_completion)vsock-loopback){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3277 [inline]
#0: ffff888112391940 ((wq_completion)vsock-loopback){+.+.}-{0:0}, at: process_scheduled_works+0xa35/0x1860 kernel/workqueue.c:3385
#1: ffffc900030dfc40 ((work_completion)(&vsock->pkt_work)){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3278 [inline]
#1: ffffc900030dfc40 ((work_completion)(&vsock->pkt_work)){+.+.}-{0:0}, at: process_scheduled_works+0xa70/0x1860 kernel/workqueue.c:3385
#2: ffff88817492e2a0 (sk_lock-AF_VSOCK){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1713 [inline]
#2: ffff88817492e2a0 (sk_lock-AF_VSOCK){+.+.}-{0:0}, at: virtio_transport_recv_pkt+0xfde/0x2bb0 net/vmw_vsock/virtio_transport_common.c:1671
stack backtrace:
CPU: 1 UID: 0 PID: 6007 Comm: kworker/1:5 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Workqueue: vsock-loopback vsock_loopback_work
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
print_deadlock_bug+0x279/0x290 kernel/locking/lockdep.c:3041
check_deadlock kernel/locking/lockdep.c:3093 [inline]
validate_chain kernel/locking/lockdep.c:3895 [inline]
__lock_acquire+0x253f/0x2cf0 kernel/locking/lockdep.c:5237
lock_acquire+0x106/0x350 kernel/locking/lockdep.c:5868
lock_sock_nested+0x41/0x100 net/core/sock.c:3783
lock_sock include/net/sock.h:1713 [inline]
virtio_transport_recv_listen+0x13a5/0x2230 net/vmw_vsock/virtio_transport_common.c:1593
virtio_transport_recv_pkt+0x174b/0x2bb0 net/vmw_vsock/virtio_transport_common.c:1695
vsock_loopback_work+0x32c/0x3f0 net/vmw_vsock/vsock_loopback.c:142
process_one_work kernel/workqueue.c:3302 [inline]
process_scheduled_works+0xb5d/0x1860 kernel/workqueue.c:3385
worker_thread+0xa53/0xfc0 kernel/workqueue.c:3466
kthread+0x388/0x470 kernel/kthread.c:436
ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
***
If these findings have caused you to resend the series or submit a
separate fix, please add the following tag to your commit message:
Tested-by: syzbot@syzkaller.appspotmail.com
---
This report is generated by a bot. It may contain errors.
syzbot ci engineers can be reached at syzkaller@googlegroups.com.
To test a patch for this bug, please reply with `#syz test`
(should be on a separate line).
The patch should be attached to the email.
Note: arguments like custom git repos and branches are not supported.
^ permalink raw reply
* Re: [ANNOUNCE] iproute2 7.0 release
From: Sergei Trofimovich @ 2026-04-24 20:32 UTC (permalink / raw)
To: stephen; +Cc: netdev
> Download:
> https://www.kernel.org/pub/linux/utils/net/iproute2/iproute2-7.0.0.tar.gz
This URL is 404. Looking at https://www.kernel.org/pub/linux/utils/net/iproute2/
it looks like tarballs slightly changed their naming and now prepend `v`:
iproute2-6.19.0.tar.gz 18-Feb-2026 15:36 1M
iproute2-6.19.0.tar.sign 18-Feb-2026 15:36 566
iproute2-6.19.0.tar.xz 18-Feb-2026 15:36 936K
...
iproute2-v7.0.0.tar.gz 13-Apr-2026 19:31 1M
iproute2-v7.0.0.tar.sign 13-Apr-2026 19:31 566
iproute2-v7.0.0.tar.xz 13-Apr-2026 19:31 940K
Should `v` be there? Worth removing at least for next releases?
--
Sergei
^ permalink raw reply
* Re: [PATCH 8/8] ARM: dts: qcom: Add Samsung Galaxy S4
From: Linus Walleij @ 2026-04-24 20:45 UTC (permalink / raw)
To: contact
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Guru Das Srinagesh,
Rob Clark, Joerg Roedel, Will Deacon, Robin Murphy, Kees Cook,
Tony Luck, Guilherme G. Piccoli, linux-arm-msm, devicetree,
linux-kernel, linux-gpio, iommu, phone-devel, Jakub Kicinski,
netdev
In-Reply-To: <20260421-mainline-send-v1-sending-v1-8-bcb0857724de@alex-min.fr>
Hi Alexandre,
On Tue, Apr 21, 2026 at 11:45 AM Alexandre MINETTE via B4 Relay
<devnull+contact.alex-min.fr@kernel.org> wrote:
> From: Alexandre MINETTE <contact@alex-min.fr>
>
> Add a device tree for the Samsung Galaxy S4, codenamed jflte.
>
> This has been tested on a Samsung Galaxy S4 GT-I9505. The initial support
> covers UART, USB peripheral mode with USB networking, the front LED and
> the physical buttons.
>
> Signed-off-by: Alexandre MINETTE <contact@alex-min.fr>
Which modem is in this phone?
I just briefly mentione the S4 in this message:
https://lore.kernel.org/phone-devel/CAD++jLmBxH1Zubh2avWrvMs4L0zv1NU7WEO3D8aeGiiVZo5AdQ@mail.gmail.com/T/#u
If this phone has one of the Ericsson CAIF modems it feels weird if
we add the DTS at the same time as we delete the modem support
code... (it can be resurrected easily of course)
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH net] net: mana: Optimize irq affinity for low vcpu configs
From: Yury Norov @ 2026-04-24 21:25 UTC (permalink / raw)
To: Shradha Gupta
Cc: Dexuan Cui, Wei Liu, Haiyang Zhang, K. Y. Srinivasan, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Konstantin Taranov, Simon Horman, Erni Sri Satya Vennela,
Dipayaan Roy, Shiraz Saleem, Michael Kelley, Long Li, Yury Norov,
linux-hyperv, linux-kernel, netdev, Paul Rosswurm, Shradha Gupta,
Saurabh Singh Sengar, stable
In-Reply-To: <20260424061702.1442618-1-shradhagupta@linux.microsoft.com>
On Thu, Apr 23, 2026 at 11:17:00PM -0700, Shradha Gupta wrote:
> In mana driver, the number of IRQs allocated are capped by the
> min(num_cpu + 1, queue count). In cases, where the IRQ count is greater
> than the vcpu count, we want to utilize all the vcpus, irrespective of
> their NUMA/core bindings.
>
> This is important, especially in the envs where number of vcpus are so
> few that the softIRQ handling overhead on two IRQs on the same vcpu is
> much more than their overheads if they were spread across sibling vcpus
>
> This behaviour is more evident with dynamic IRQ allocation. Since MANA
> IRQs are assigned at a later stage compared to static allocation, other
> device IRQs may already be affinitized to the vCPUs. As a result, IRQ
> weights become imbalanced, causing multiple MANA IRQs to land on the
> same vCPU.
>
> In such cases when many parallel TCP connections are tested, the
> throughput drops significantly
>
> Test envs:
> =======================================================
> Case 1: without this patch
> =======================================================
> 4 vcpu(2 cores), 5 MANA IRQs (1 HWC + 4 Queue)
>
> TYPE effective vCPU aff
> =======================================================
> IRQ0: HWC 0
> IRQ1: mana_q1 0
> IRQ2: mana_q2 2
> IRQ3: mana_q3 0
> IRQ4: mana_q4 3
>
> %soft on each vCPU(mpstat -P ALL 1) on receiver
> vCPU 0 1 2 3
> =======================================================
> pass 1: 38.85 0.03 24.89 24.65
> pass 2: 39.15 0.03 24.57 25.28
> pass 3: 40.36 0.03 23.20 23.17
>
> =======================================================
> Case 2: with this patch
> =======================================================
> 4 vcpu(2 cores), 5 MANA IRQs (1 HWC + 4 Queue)
>
> TYPE effective vCPU aff
> =======================================================
> IRQ0: HWC 0
> IRQ1: mana_q1 0
> IRQ2: mana_q2 1
> IRQ3: mana_q3 2
> IRQ4: mana_q4 3
>
> %soft on each vCPU(mpstat -P ALL 1) on receiver
> vCPU 0 1 2 3
> =======================================================
> pass 1: 15.42 15.85 14.99 14.51
> pass 2: 15.53 15.94 15.81 15.93
> pass 3: 16.41 16.35 16.40 16.36
>
> =======================================================
> Throughput Impact(in Gbps, same env)
> =======================================================
> TCP conn with patch w/o patch
> 20480 15.65 7.73
> 10240 15.63 8.93
> 8192 15.64 9.69
> 6144 15.64 13.16
> 4096 15.69 15.75
> 2048 15.69 15.83
> 1024 15.71 15.28
>
> Fixes: 755391121038 ("net: mana: Allocate MSI-X vectors dynamically")
> Cc: stable@vger.kernel.org
> Signed-off-by: Shradha Gupta <shradhagupta@linux.microsoft.com>
> Signed-off-by: Erni Sri Satya Vennela <ernis@linux.microsoft.com>
> Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
> ---
> .../net/ethernet/microsoft/mana/gdma_main.c | 35 +++++++++++++++++--
> 1 file changed, 33 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/microsoft/mana/gdma_main.c b/drivers/net/ethernet/microsoft/mana/gdma_main.c
> index 098fbda0d128..433c044d53c6 100644
> --- a/drivers/net/ethernet/microsoft/mana/gdma_main.c
> +++ b/drivers/net/ethernet/microsoft/mana/gdma_main.c
> @@ -1672,6 +1672,23 @@ static int irq_setup(unsigned int *irqs, unsigned int len, int node,
> return 0;
> }
>
> +static int irq_setup_linear(unsigned int *irqs, unsigned int len)
> +{
> + int cpu;
> +
> + rcu_read_lock();
> + for_each_online_cpu(cpu) {
> + if (len <= 0)
> + break;
> +
> + irq_set_affinity_and_hint(*irqs++, cpumask_of(cpu));
> + len--;
> + }
> + rcu_read_unlock();
> +
> + return 0;
> +}
> +
> static int mana_gd_setup_dyn_irqs(struct pci_dev *pdev, int nvec)
> {
> struct gdma_context *gc = pci_get_drvdata(pdev);
> @@ -1722,10 +1739,24 @@ static int mana_gd_setup_dyn_irqs(struct pci_dev *pdev, int nvec)
> * first CPU sibling group since they are already affinitized to HWC IRQ
> */
> cpus_read_lock();
> - if (gc->num_msix_usable <= num_online_cpus())
> + if (gc->num_msix_usable <= num_online_cpus()) {
> skip_first_cpu = true;
> + err = irq_setup(irqs, nvec, gc->numa_node, skip_first_cpu);
Then you don't need the 'skip_first_cpu' variable.
> + } else {
> + /*
> + * In case our IRQs are more than num_online_cpus, we try to
> + * make sure we are using all vcpus. In such a case NUMA or
> + * CPU core affinity does not matter.
> + * Note that in this case the total mana IRQ should always be
> + * num_online_cpu + 1. The first HWC IRQ is already handled
> + * in HWC setup calls
> + * So, the nvec value in this path should always be equal to
> + * num_online_cpu
> + */
> + WARN_ON(nvec > num_online_cpus());
That sounds weird. If you don't support IRQs more than CPUs , and want to
warn about it, you'd do that earlier in the function, and align the other
logic accordingly. For example:
if (WARN_ON(nvec > num_online_cpus()))
nvec = num_online_cpus();
irqs = kmalloc_objs(int, nvec);
if (!irqs)
return -ENOMEM;
...
So you'll decrease pressure on allocator.
What would happen with those IRQs beyond num_online_cpus()? Can you explain
it in the comment? I'm not an expert in your driver, but usually if you pass
a vector to function, and the function is able to handle only a part of it,
it returns the number of processed elements.
Thanks,
Yury
> + err = irq_setup_linear(irqs, nvec);
> + }
>
> - err = irq_setup(irqs, nvec, gc->numa_node, skip_first_cpu);
> if (err) {
> cpus_read_unlock();
> goto free_irq;
>
> base-commit: e728258debd553c95d2e70f9cd97c9fde27c7130
> --
> 2.34.1
^ permalink raw reply
* Re: [PATCH 1/9] bitfield: add FIELD_GET_SIGNED()
From: David Laight @ 2026-04-24 21:37 UTC (permalink / raw)
To: Yury Norov
Cc: Johannes Berg, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Andy Lutomirski, Peter Zijlstra,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Ping-Ke Shih, Richard Cochran, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Alexandre Belloni,
Yury Norov, Rasmus Villemoes, Hans de Goede, Linus Walleij,
Sakari Ailus, Salah Triki, Achim Gratz, Ben Collins, linux-kernel,
linux-iio, linux-wireless, netdev, linux-rtc
In-Reply-To: <aeub59FBHbCy-KKP@yury>
On Fri, 24 Apr 2026 12:35:51 -0400
Yury Norov <ynorov@nvidia.com> wrote:
...
> > Any chance it'd be simple to generate u32_get_bits_signed() etc.? Could
> > be especially useful for le32_get_bits_signed() for example, to have the
> > endian conversion built-in unlike FIELD_GET_SIGNED().
>
> Maybe this:
>
> x = FIELD_GET_SIGNED(mask, le32_to_cpu(reg))
But if you are going to follow it by:
x1 = FIELD_GET_SIGNED(mask1, le32_to_cpu(reg))
you really want to to the byteswap once, best as:
reg = le32_to_cpu(struct->member);
David
>
> Thanks,
> Yury
>
^ permalink raw reply
* Re: [ANNOUNCE] iproute2 7.0 release
From: Stephen Hemminger @ 2026-04-24 22:01 UTC (permalink / raw)
To: Sergei Trofimovich; +Cc: netdev
In-Reply-To: <20260424213233.4dabf6bf@nz.home>
On Fri, 24 Apr 2026 21:32:33 +0100
Sergei Trofimovich <slyich@gmail.com> wrote:
> > Download:
> > https://www.kernel.org/pub/linux/utils/net/iproute2/iproute2-7.0.0.tar.gz
>
> This URL is 404. Looking at https://www.kernel.org/pub/linux/utils/net/iproute2/
> it looks like tarballs slightly changed their naming and now prepend `v`:
>
> iproute2-6.19.0.tar.gz 18-Feb-2026 15:36 1M
> iproute2-6.19.0.tar.sign 18-Feb-2026 15:36 566
> iproute2-6.19.0.tar.xz 18-Feb-2026 15:36 936K
> ...
> iproute2-v7.0.0.tar.gz 13-Apr-2026 19:31 1M
> iproute2-v7.0.0.tar.sign 13-Apr-2026 19:31 566
> iproute2-v7.0.0.tar.xz 13-Apr-2026 19:31 940K
>
> Should `v` be there? Worth removing at least for next releases?
The v ones should not be there. It was a typo
^ permalink raw reply
* [RFC PATCH net-next 1/3] net: macb: flush PCIe posted write after TSTART doorbell
From: Lukasz Raczylo @ 2026-04-24 22:38 UTC (permalink / raw)
To: netdev
Cc: Nicolas Ferre, Claudiu Beznea, Andrew Lunn, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, linux-kernel,
linux-arm-kernel, linux-rpi-kernel
In-Reply-To: <cover.1777064117.git.lukasz@raczylo.com>
macb_start_xmit() and macb_tx_restart() kick transmission by
OR-ing MACB_BIT(TSTART) into NCR. On PCIe-attached macb instances
(BCM2712 + RP1 PCIe south bridge on Raspberry Pi 5 is the setup we
have in front of us), writes to NCR are posted PCIe writes: they
are not guaranteed to reach the device before the issuing CPU
returns. If the TSTART doorbell does not reach the MAC, no TX
begins, no TCOMP completion arrives, and the ring remains
quiescent without any kernel-visible indication.
Note that the raspberrypi/linux vendor fork carries a local patch
around the TSTART site (a queue->tx_pending breadcrumb that is
promoted to queue->txubr_pending by the next TCOMP interrupt,
triggering macb_tx_restart()). That workaround makes the loss
recoverable under traffic, but it cannot help if TCOMP itself is
not raised because no TX started -- which is exactly the case we
are targeting here. The handshake is not present in mainline.
Add a read-back of NCR after each TSTART write in macb_start_xmit()
and macb_tx_restart(). The read is an architected PCIe read
barrier for earlier posted writes on the same path; it ensures the
doorbell has reached the MAC before the functions return.
We do not yet have direct hardware evidence that TSTART is being
lost on the RP1 path (that would require a PCIe protocol analyser,
or at minimum a before/after counter on queue->tx_stall_last_tail
with and without this patch applied in isolation). This patch is
one of a three-patch series ("candidate fixes for silent TX stall
on BCM2712/RP1"); see the cover letter for context. We have
verified the series compiles and applies cleanly against mainline
HEAD and against raspberrypi/linux rpi-6.18.y @ f2f68e79f16f;
runtime verification is pending.
Link: https://github.com/cilium/cilium/issues/43198
Link: https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/2133877
Signed-off-by: Lukasz Raczylo <lukasz@raczylo.com>
---
drivers/net/ethernet/cadence/macb_main.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index a12aa2124..b6cca55ad 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -1922,6 +1922,13 @@ static void macb_tx_restart(struct macb_queue *queue)
spin_lock(&bp->lock);
macb_writel(bp, NCR, macb_readl(bp, NCR) | MACB_BIT(TSTART));
+ /*
+ * Flush the PCIe posted-write queue so the TSTART doorbell
+ * reliably reaches the MAC. Without this, the write can sit
+ * in the fabric and the MAC never advances, causing a silent
+ * TX stall.
+ */
+ (void)macb_readl(bp, NCR);
spin_unlock(&bp->lock);
out_tx_ptr_unlock:
@@ -2560,6 +2567,11 @@ static netdev_tx_t macb_start_xmit(struct sk_buff *skb, struct net_device *dev)
spin_lock(&bp->lock);
macb_tx_lpi_wake(bp);
macb_writel(bp, NCR, macb_readl(bp, NCR) | MACB_BIT(TSTART));
+ /*
+ * Flush the PCIe posted-write queue; see the comment in
+ * macb_tx_restart() for the reasoning.
+ */
+ (void)macb_readl(bp, NCR);
spin_unlock(&bp->lock);
if (CIRC_SPACE(queue->tx_head, queue->tx_tail, bp->tx_ring_size) < 1)
--
2.53.0
^ permalink raw reply related
* [RFC PATCH net-next 2/3] net: macb: re-check ISR after IER re-enable in macb_tx_poll
From: Lukasz Raczylo @ 2026-04-24 22:38 UTC (permalink / raw)
To: netdev
Cc: Nicolas Ferre, Claudiu Beznea, Andrew Lunn, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, linux-kernel,
linux-arm-kernel, linux-rpi-kernel
In-Reply-To: <cover.1777064117.git.lukasz@raczylo.com>
macb_tx_poll() runs with TCOMP masked, drains the TX ring, then
calls napi_complete_done() and re-enables TCOMP via IER. An
existing comment in the function notes:
/* Packet completions only seem to propagate to raise
* interrupts when interrupts are enabled at the time, so if
* packets were sent while interrupts were disabled,
* they will not cause another interrupt to be generated when
* interrupts are re-enabled.
*/
and mitigates this by calling macb_tx_complete_pending(), which
inspects driver-visible ring state (descriptor->ctrl, after rmb())
and reschedules NAPI if a completion is observable in memory.
On PCIe-attached parts (BCM2712 + RP1 on Raspberry Pi 5 is the
setup we have in front of us), the descriptor DMA write that sets
TX_USED may not have retired to system memory at the point
macb_tx_complete_pending() runs. The rmb() synchronises the CPU
view of earlier CPU writes; it is not sufficient to retire an
in-flight peripheral DMA write. Under that ordering the in-memory
descriptor can still read TX_USED=0 when the hardware has in fact
completed the frame; the check returns false; NAPI exits; the
quirk above prevents the re-enabled IER from re-firing; the ring
goes quiescent.
Add an explicit ISR read after the IER write. The MMIO read
serves two independent purposes:
(1) It is an architected PCIe read barrier for earlier
peripheral-originated DMA writes on the same path, so a
subsequent macb_tx_complete_pending() observes any TX_USED
write that was in flight at the time of the barrier.
(2) It samples the hardware ISR directly, so a TCOMP bit that
the hardware set while TCOMP was masked is visible here,
independently of whether the descriptor DMA has retired.
If either signal indicates pending work, reschedule NAPI via the
same path as the existing check.
This patch addresses one of three candidate races for the silent
TX stall described in the cover letter. Whether it is sufficient
by itself, or whether it requires the PCIe posted-write flush in
patch 1/3 to cover the observed behaviour, we have not yet
verified at runtime.
Link: https://github.com/cilium/cilium/issues/43198
Link: https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/2133877
Signed-off-by: Lukasz Raczylo <lukasz@raczylo.com>
---
drivers/net/ethernet/cadence/macb_main.c | 28 +++++++++++++++---------
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index b6cca55ad..ea231b1c5 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -1973,17 +1973,25 @@ static int macb_tx_poll(struct napi_struct *napi, int budget)
if (work_done < budget && napi_complete_done(napi, work_done)) {
queue_writel(queue, IER, MACB_BIT(TCOMP));
- /* Packet completions only seem to propagate to raise
- * interrupts when interrupts are enabled at the time, so if
- * packets were sent while interrupts were disabled,
- * they will not cause another interrupt to be generated when
- * interrupts are re-enabled.
- * Check for this case here to avoid losing a wakeup. This can
- * potentially race with the interrupt handler doing the same
- * actions if an interrupt is raised just after enabling them,
- * but this should be harmless.
+ /*
+ * TCOMP events that fire while the interrupt is masked do
+ * not re-fire when IER is re-enabled. Catch this two ways
+ * to avoid losing a wakeup:
+ *
+ * (1) Read ISR -- catches completions the hardware flagged
+ * but that we did not see as an interrupt. The MMIO
+ * read doubles as a PCIe read barrier, flushing any
+ * in-flight descriptor TX_USED DMA writes into memory.
+ * (2) macb_tx_complete_pending() inspects the ring after
+ * that flush, catching a descriptor whose TX_USED is
+ * now visible as a result of the barrier.
+ *
+ * This can race with the interrupt handler taking the same
+ * path if an interrupt fires just after the IER write;
+ * rescheduling NAPI in that case is harmless.
*/
- if (macb_tx_complete_pending(queue)) {
+ if ((queue_readl(queue, ISR) & MACB_BIT(TCOMP)) ||
+ macb_tx_complete_pending(queue)) {
queue_writel(queue, IDR, MACB_BIT(TCOMP));
macb_queue_isr_clear(bp, queue, MACB_BIT(TCOMP));
netdev_vdbg(bp->dev, "TX poll: packets pending, reschedule\n");
--
2.53.0
^ permalink raw reply related
* [RFC PATCH net-next 3/3] net: macb: add TX stall watchdog as defence-in-depth safety net
From: Lukasz Raczylo @ 2026-04-24 22:38 UTC (permalink / raw)
To: netdev
Cc: Nicolas Ferre, Claudiu Beznea, Andrew Lunn, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, linux-kernel,
linux-arm-kernel, linux-rpi-kernel
In-Reply-To: <cover.1777064117.git.lukasz@raczylo.com>
Patches 1/3 and 2/3 address two candidate races that could lead
to a TCOMP completion being missed on PCIe-attached macb
instances. This patch adds a defence-in-depth safety net, in
case a further race remains that we have not identified.
The watchdog is a per-queue delayed_work that runs once per
second. It snapshots queue->tx_tail; if the ring is non-empty
(queue->tx_head != queue->tx_tail) and tx_tail has not advanced
since the previous tick, it calls macb_tx_restart().
No new recovery logic is introduced. macb_tx_restart() already
exists in this file, is correctly locked (tx_ptr_lock, bp->lock),
and verifies that the hardware's TBQP is behind the driver's
head index before re-asserting TSTART. On a healthy ring it is
a no-op at the hardware level; the watchdog only supplies the
missing trigger.
On a healthy queue the per-tick cost is one spin_lock_irqsave()
/ spin_unlock_irqrestore() and one branch. The delayed_work is
only scheduled between macb_open() and macb_close(), and is
cancelled synchronously on close.
Context for submission: on our 24-node Raspberry Pi 5 fleet,
before this series, an out-of-band user-space watchdog
(monitoring tx_packets from /sys/class/net/.../statistics and
toggling the link down/up when it froze) was required to keep
nodes usable. We include this kernel-side watchdog as a cleaner
in-kernel equivalent for any residual stall that patches 1 and
2 do not cover. We are willing to drop this patch if the view
is that 1 and 2 should stand alone.
Link: https://github.com/cilium/cilium/issues/43198
Link: https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/2133877
Signed-off-by: Lukasz Raczylo <lukasz@raczylo.com>
---
drivers/net/ethernet/cadence/macb.h | 5 ++
drivers/net/ethernet/cadence/macb_main.c | 59 ++++++++++++++++++++++++
2 files changed, 64 insertions(+)
diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
index 2de56017e..9115f2b47 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -1278,6 +1278,11 @@ struct macb_queue {
dma_addr_t tx_ring_dma;
struct work_struct tx_error_task;
bool txubr_pending;
+
+ /* TX stall watchdog -- see macb_tx_stall_watchdog() in macb_main.c */
+ struct delayed_work tx_stall_watchdog_work;
+ unsigned int tx_stall_last_tail;
+
struct napi_struct napi_tx;
dma_addr_t rx_ring_dma;
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index ea231b1c5..ea2306ef7 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -2002,6 +2002,59 @@ static int macb_tx_poll(struct napi_struct *napi, int budget)
return work_done;
}
+#define MACB_TX_STALL_INTERVAL_MS 1000
+
+/*
+ * TX stall watchdog.
+ *
+ * Defence-in-depth against lost TCOMP interrupts. macb already has a
+ * recovery chain (tx_pending -> txubr_pending -> macb_tx_restart())
+ * that fires on TCOMP; if TCOMP itself is lost the TX ring stalls
+ * silently until something else kicks TSTART. This watchdog runs
+ * once per second per queue, snapshots tx_tail, and calls
+ * macb_tx_restart() if the ring is non-empty and tx_tail has not
+ * advanced since the previous tick.
+ *
+ * macb_tx_restart() already checks the hardware's TBQP against the
+ * driver's head index before re-asserting TSTART, so on a healthy
+ * ring this is a no-op at the hardware level. The watchdog only
+ * adds the missing trigger.
+ */
+static void macb_tx_stall_watchdog(struct work_struct *work)
+{
+ struct macb_queue *queue = container_of(to_delayed_work(work),
+ struct macb_queue,
+ tx_stall_watchdog_work);
+ struct macb *bp = queue->bp;
+ unsigned int cur_tail, cur_head;
+ bool stalled = false;
+ unsigned long flags;
+
+ if (!netif_running(bp->dev))
+ return;
+
+ spin_lock_irqsave(&queue->tx_ptr_lock, flags);
+ cur_tail = queue->tx_tail;
+ cur_head = queue->tx_head;
+ if (cur_head != cur_tail &&
+ cur_tail == queue->tx_stall_last_tail)
+ stalled = true;
+ else
+ queue->tx_stall_last_tail = cur_tail;
+ spin_unlock_irqrestore(&queue->tx_ptr_lock, flags);
+
+ if (stalled) {
+ netdev_warn_once(bp->dev,
+ "TX stall detected on queue %u (tail=%u head=%u); re-kicking TSTART\n",
+ (unsigned int)(queue - bp->queues),
+ cur_tail, cur_head);
+ macb_tx_restart(queue);
+ }
+
+ schedule_delayed_work(&queue->tx_stall_watchdog_work,
+ msecs_to_jiffies(MACB_TX_STALL_INTERVAL_MS));
+}
+
static void macb_hresp_error_task(struct work_struct *work)
{
struct macb *bp = from_work(bp, work, hresp_err_bh_work);
@@ -3190,6 +3243,9 @@ static int macb_open(struct net_device *dev)
for (q = 0, queue = bp->queues; q < bp->num_queues; ++q, ++queue) {
napi_enable(&queue->napi_rx);
napi_enable(&queue->napi_tx);
+ queue->tx_stall_last_tail = queue->tx_tail;
+ schedule_delayed_work(&queue->tx_stall_watchdog_work,
+ msecs_to_jiffies(MACB_TX_STALL_INTERVAL_MS));
}
macb_init_hw(bp);
@@ -3240,6 +3296,7 @@ static int macb_close(struct net_device *dev)
for (q = 0, queue = bp->queues; q < bp->num_queues; ++q, ++queue) {
napi_disable(&queue->napi_rx);
napi_disable(&queue->napi_tx);
+ cancel_delayed_work_sync(&queue->tx_stall_watchdog_work);
netdev_tx_reset_queue(netdev_get_tx_queue(dev, q));
}
@@ -4802,6 +4859,8 @@ static int macb_init_dflt(struct platform_device *pdev)
}
INIT_WORK(&queue->tx_error_task, macb_tx_error_task);
+ INIT_DELAYED_WORK(&queue->tx_stall_watchdog_work,
+ macb_tx_stall_watchdog);
q++;
}
--
2.53.0
^ permalink raw reply related
* [RFC PATCH net-next 0/3] net: macb: candidate fixes for silent TX stall on BCM2712/RP1
From: Lukasz Raczylo @ 2026-04-24 22:38 UTC (permalink / raw)
To: netdev
Cc: Nicolas Ferre, Claudiu Beznea, Andrew Lunn, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, linux-kernel,
linux-arm-kernel, linux-rpi-kernel
Hi netdev, Nicolas, Claudiu, linux-rpi,
This series proposes three candidate fixes for the silent TX stall
observed on Raspberry Pi 5 (BCM2712 SoC, Cadence GEM via RP1 PCIe
south bridge). The bug has been reported, with reproducers, at:
* https://github.com/cilium/cilium/issues/43198
* https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/2133877
Cilium #43198 reports reproduction on linux-raspi 6.17.0-1004, and
explicitly notes reproduction with both Cilium/eBPF and
Calico/nftables dataplanes (i.e. not CNI-specific). We observe the
same failure mode on kernel 6.18.24 built from raspberrypi/linux
rpi-6.18.y @ f2f68e79f16f, across a 24-node Raspberry Pi 5 fleet.
The 6.17/6.18 commonality and the two-CNI reproduction together
put the root cause below the packet-scheduling layer, in the macb
driver or the RP1 PCIe path.
Observed symptoms (our side, 6.18.24; consistent with the linked
reports):
* queue->tx_tail stops advancing at a single second;
* /sys/class/net/<iface>/statistics/tx_packets stops incrementing;
* qdisc backlog grows past zero; netif_stop_subqueue() is called;
* RX counters continue advancing; the MAC IRQ line continues to
fire (RX completions are handled);
* no kernel log line is produced for the duration of the stall;
* dev_watchdog does not fire: macb_netdev_ops has no
.ndo_tx_timeout, and our reading is that trans_start is kept
fresh by successful xmit prior to the ring filling;
* recovery on our side has required `ip link set <iface> down/up`
via an out-of-band watchdog DaemonSet.
Reading the current driver we identified three plausible races
between driver and hardware, each of which could independently
produce the observed behaviour. We did not determine which is the
actual root cause -- that likely requires either BCM2712/RP1
documentation we do not have, or dynamic tracing of the driver
during an in-situ stall. The series therefore attempts to close
all three, with each commit message stating which specific race
that patch is targeting.
Patch 1/3 -- flush PCIe posted write after TSTART doorbell.
Writes to NCR are posted PCIe writes and may not reach the MAC
before the driver returns. If the TSTART doorbell is lost, no
TX starts, no TCOMP arrives, and the ring goes quiescent. A
read-back of NCR after the write is a standard read-after-write
PCIe flush.
Patch 2/3 -- re-check ISR after IER re-enable in macb_tx_poll().
An existing comment in macb_tx_poll() notes that completions
raised while TCOMP is masked do not re-fire when IER is
re-enabled, and mitigates the window with macb_tx_complete_pending(),
which inspects driver-visible ring state only (after rmb()). On
PCIe-attached parts the descriptor DMA write that sets TX_USED
can remain in flight when that check runs; the rmb() orders CPU
writes but does not retire peripheral DMA. Reading ISR directly
after IER re-enable addresses this in two ways: (a) the MMIO read
is an architected PCIe read barrier for prior DMA writes, so a
subsequent macb_tx_complete_pending() sees up-to-date TX_USED
state; (b) it directly observes a pending TCOMP bit if the
hardware has one set. Either signal reschedules NAPI.
Patch 3/3 -- TX stall watchdog. Defence-in-depth. If patches
1 and 2 close the races we identified, this patch performs a
single spin_lock_irqsave/unlock and a branch per queue per
second with no other effect. If a further race remains that we
have not identified, it invokes the driver's own existing
macb_tx_restart(), which already verifies that TBQP is behind
tx_head before re-asserting TSTART. We include this patch
because we have empirically observed multi-minute stalls on this
hardware; we are willing to drop it if the preference is for
1 and 2 to stand alone.
Status and testing:
* Apply-tested against Linux net-next HEAD (this series is
generated from it) and against raspberrypi/linux rpi-6.18.y @
f2f68e79f16f (the fork our fleet runs): all three apply
cleanly on net-next; the rpi fork carries an additional local
`bool tx_pending` field on `struct macb_queue` that is not in
mainline, so we maintain a small rebased patch 3 hunk for it.
* Build-tested: the series compiles cleanly as part of our Talos
image build pipeline on arm64.
* Runtime-tested, early signal: ~4 h 20 min of post-patch uptime
on the canary node, ~3 h 15 min on the slowest (last master to
upgrade), ~95 node-hours cumulative across the 24-node fleet at
the time this cover letter was written. During that window the
fleet-wide counts are zero RECOVER events, zero `[tx-stall]`
partial markers (an out-of-band userspace detector that records
even transient one-second freezes that recover before the
3-second threshold), and zero ping-failure markers. Pre-patch
reference window (2026-04-24 14:00-18:10 UTC, when proper
monitoring was in place) observed multiple stalls per hour at
fleet level; at that rate we would expect on the order of 50
stalls in 95 node-hours, actual is zero. We will follow up
with a 24 h and a 1-week data point as the same observability
runs forward; the direction so far is consistent with patches
1 and 2 closing the underlying race(s) and patch 3 correctly
being a no-op on healthy hardware.
The series does not depend on any other in-flight work we are
aware of. Happy to split, rebase, or drop individual patches on
feedback. All three are independently revertable.
Lukasz Raczylo (3):
net: macb: flush PCIe posted write after TSTART doorbell
net: macb: re-check ISR after IER re-enable in macb_tx_poll
net: macb: add TX stall watchdog as defence-in-depth safety net
drivers/net/ethernet/cadence/macb.h | 5 ++
drivers/net/ethernet/cadence/macb_main.c | 99 +++++++++++++++++++++---
2 files changed, 94 insertions(+), 10 deletions(-)
--
2.53.0
^ permalink raw reply
* Re: [PATCH bpf-next v3 4/9] bpf: Refactor object relationship tracking and fix dynptr UAF bug
From: Eduard Zingerman @ 2026-04-24 22:48 UTC (permalink / raw)
To: Amery Hung, bpf
Cc: netdev, alexei.starovoitov, andrii, daniel, memxor, martin.lau,
mykyta.yatsenko5, kernel-team
In-Reply-To: <20260421221016.2967924-5-ameryhung@gmail.com>
On Tue, 2026-04-21 at 15:10 -0700, Amery Hung wrote:
Tbh, I find current state of affairs with id/ref_obj_id/parent_id hard
to follow. The release_reference() is an improvement, but the means by
which the fields are propagated to bpf_reg_state objects are convoluted.
I wonder if having a separate "object table" in bpf_verifier_state and
having bpf_reg_state->id refer to objects within this table would make
things more straight forward.
A few nits below.
[...]
> diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
[...]
> @@ -1323,6 +1335,7 @@ struct bpf_dynptr_desc {
> enum bpf_dynptr_type type;
> u32 id;
> u32 ref_obj_id;
> + u32 parent_id;
> };
Nit: would be nice to have a comment describing when the above fields
are populated.
>
> struct bpf_kfunc_call_arg_meta {
> @@ -1334,6 +1347,7 @@ struct bpf_kfunc_call_arg_meta {
> const char *func_name;
> /* Out parameters */
> u32 ref_obj_id;
> + u32 id;
Nit: would be nice to have a comment here too.
[...]
> diff --git a/kernel/bpf/states.c b/kernel/bpf/states.c
> index 8478d2c6ed5b..72bd3bcda5fb 100644
> --- a/kernel/bpf/states.c
> +++ b/kernel/bpf/states.c
> @@ -494,7 +494,8 @@ static bool regs_exact(const struct bpf_reg_state *rold,
> {
> return memcmp(rold, rcur, offsetof(struct bpf_reg_state, id)) == 0 &&
> check_ids(rold->id, rcur->id, idmap) &&
> - check_ids(rold->ref_obj_id, rcur->ref_obj_id, idmap);
> + check_ids(rold->ref_obj_id, rcur->ref_obj_id, idmap) &&
> + check_ids(rold->parent_id, rcur->parent_id, idmap);
Nit: these check_ids() become repetitive, maybe add a utility function
checking id/ref_obj_id/parent_id?
> }
>
> enum exact_level {
> @@ -619,7 +620,8 @@ static bool regsafe(struct bpf_verifier_env *env, struct bpf_reg_state *rold,
> range_within(rold, rcur) &&
> tnum_in(rold->var_off, rcur->var_off) &&
> check_ids(rold->id, rcur->id, idmap) &&
> - check_ids(rold->ref_obj_id, rcur->ref_obj_id, idmap);
> + check_ids(rold->ref_obj_id, rcur->ref_obj_id, idmap) &&
> + check_ids(rold->parent_id, rcur->parent_id, idmap);
> case PTR_TO_PACKET_META:
> case PTR_TO_PACKET:
> /* We must have at least as much range as the old ptr
> @@ -799,7 +801,8 @@ static bool stacksafe(struct bpf_verifier_env *env, struct bpf_func_state *old,
> cur_reg = &cur->stack[spi].spilled_ptr;
> if (old_reg->dynptr.type != cur_reg->dynptr.type ||
> old_reg->dynptr.first_slot != cur_reg->dynptr.first_slot ||
> - !check_ids(old_reg->ref_obj_id, cur_reg->ref_obj_id, idmap))
> + !check_ids(old_reg->ref_obj_id, cur_reg->ref_obj_id, idmap) ||
> + !check_ids(old_reg->parent_id, cur_reg->parent_id, idmap))
Not something changed by the current patch, but still a question:
this path ignores old_reg->id, is it a bug?
> return false;
> break;
> case STACK_ITER:
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 0313b7d5f6c9..908a3af0e7c4 100644
[...]
> @@ -241,6 +241,7 @@ struct bpf_call_arg_meta {
> int mem_size;
> u64 msize_max_value;
> int ref_obj_id;
> + u32 id;
Nit: please add a comment here as well.
[...]
> @@ -635,11 +636,12 @@ static int destroy_if_dynptr_stack_slot(struct bpf_verifier_env *env,
> struct bpf_func_state *state, int spi);
>
> static int mark_stack_slots_dynptr(struct bpf_verifier_env *env, struct bpf_reg_state *reg,
> - enum bpf_arg_type arg_type, int insn_idx, int clone_ref_obj_id)
> + enum bpf_arg_type arg_type, int insn_idx, int parent_id,
> + struct bpf_dynptr_desc *dynptr)
Having both parent_id and dynptr->parent_id as parameters of this
function is very confusing, but I don't have a suggestion on how to
better deal with it.
[...]
> @@ -8489,6 +8444,7 @@ static int check_func_arg(struct bpf_verifier_env *env, u32 arg,
> return -EACCES;
> }
> meta->ref_obj_id = reg->ref_obj_id;
> + meta->id = reg->id;
Could you please leave a comment here explaining when e.g.
meta->ref_obj_id and meta->id would have same or different ids here?
Maybe a few lines of BPF C code.
> }
>
> switch (base_type(arg_type)) {
> @@ -9111,26 +9067,75 @@ static int release_reference_nomark(struct bpf_verifier_state *state, int ref_ob
[...]
> +/* Release id and objects referencing the id iteratively in a DFS manner */
> +static int release_reference(struct bpf_verifier_env *env, int id)
> +{
> + u32 mask = (1 << STACK_SPILL) | (1 << STACK_DYNPTR);
> struct bpf_verifier_state *vstate = env->cur_state;
> + struct bpf_idmap *idstack = &env->idmap_scratch;
> + struct bpf_stack_state *stack;
> struct bpf_func_state *state;
> struct bpf_reg_state *reg;
> - int err;
> + int root_id = id, err;
>
> - err = release_reference_nomark(vstate, ref_obj_id);
> - if (err)
> - return err;
> + idstack->cnt = 0;
> + idstack_push(idstack, id);
>
> - bpf_for_each_reg_in_vstate(vstate, state, reg, ({
> - if (reg->ref_obj_id == ref_obj_id)
> - mark_reg_invalid(env, reg);
> - }));
> + if (find_reference_state(vstate, id))
> + WARN_ON_ONCE(release_reference_nomark(vstate, id));
> +
> + while ((id = idstack_pop(idstack))) {
> + bpf_for_each_reg_in_vstate_mask(vstate, state, reg, stack, mask, ({
> + if (reg->id != id && reg->parent_id != id && reg->ref_obj_id != id)
> + continue;
> +
> + if (reg->ref_obj_id && id != root_id) {
> + struct bpf_reference_state *ref_state;
> +
> + ref_state = find_reference_state(env->cur_state, reg->ref_obj_id);
> + verbose(env, "Unreleased reference id=%d alloc_insn=%d when releasing id=%d\n",
> + ref_state->id, ref_state->insn_idx, root_id);
> + return -EINVAL;
> + }
> +
> + if (reg->id != id) {
> + err = idstack_push(idstack, reg->id);
> + if (err)
> + return err;
> + }
> +
> + if (!stack || stack->slot_type[BPF_REG_SIZE - 1] == STACK_SPILL)
> + mark_reg_invalid(env, reg);
> + else if (stack->slot_type[BPF_REG_SIZE - 1] == STACK_DYNPTR)
> + invalidate_dynptr(env, state, stack);
invalidate_dynptr() rewrites to stack slots, can it be the case that
this body of bpf_for_each_reg_in_vstate_mask() is computed for first
and second dynptr stack slots, hence triggering invalidate_dynptr() to
rewrite three slots instead of two?
> + }));
> + }
>
> return 0;
> }
[...]
> @@ -12009,6 +12009,7 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_
> return -EFAULT;
> }
> meta->ref_obj_id = reg->ref_obj_id;
> + meta->id = reg->id;
And here a comment describing when this happens would be helpful.
[...]
> @@ -12171,15 +12171,10 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_
> }
>
> dynptr_arg_type |= (unsigned int)get_dynptr_type_flag(parent_type);
> - clone_ref_obj_id = meta->dynptr.ref_obj_id;
> - if (dynptr_type_refcounted(parent_type) && !clone_ref_obj_id) {
> - verifier_bug(env, "missing ref obj id for parent of clone");
> - return -EFAULT;
> - }
> }
>
> - ret = process_dynptr_func(env, regno, insn_idx, dynptr_arg_type, clone_ref_obj_id,
> - &meta->dynptr);
> + ret = process_dynptr_func(env, regno, insn_idx, dynptr_arg_type,
> + meta->ref_obj_id ? meta->id : 0, &meta->dynptr);
And an example here as well.
> if (ret < 0)
> return ret;
> break;
[...]
^ permalink raw reply
* Re: [PATCH net v8 4/6] net/sched: netem: validate slot configuration
From: Stephen Hemminger @ 2026-04-24 23:06 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Paolo Abeni, netdev, jiri, David S. Miller, Eric Dumazet,
Jakub Kicinski, Dave Taht, open list, Simon Horman
In-Reply-To: <CAM0EoM=mtYFyVJYLRiFULX1hpxvcwpUoTDGJvTyAskyCk_Oehw@mail.gmail.com>
On Fri, 24 Apr 2026 16:17:13 -0400
Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> () ncalls s
>
>
> On Fri, Apr 24, 2026 at 11:07 AM Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> >
> > On Thu, 23 Apr 2026 17:12:15 -0400
> > Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> >
> > > > > This is intended and explicitly explained in the cover letter.
> > > > Jamal, given the uAPI implication, could you please double check that
> > > > the change is fine?
> > > >
> > >
> > > It should be fine; at least iproute2 will never allow the kernel to
> > > receive a negative number.
> > > Stephen brought up the fact that strtod() could return a -ve number
> > > (but at least iproute2 makes sure negative numbers are not carried
> > > forward to the kernel).
> > >
> > > cheers,
> > > jamal
> >
> > Iproute2 blocks negative values kind of by accident.
> > The NEXT_IS_NUMBER() macro looks for digit at start of arg.
> > To hit this you need to either use raw netlink or change NEXT_IS_NUMBER()
> > to NEXT_IS_SIGNED_NUMBER() where slot values are parsed.
>
> For this specific attribute it was intentional:
> ...
> if (get_time64(&slot.dist_jitter, *argv)) { //get_time64 calls
> strtod() which could set dist_jitter -ve
> explain1("slot jitter");
> return -1;
> }
> if (slot.dist_jitter <= 0) { // we reject -ve values
> fprintf(stderr, "Non-positive jitter\n");
> return -1;
> }
>
> cheers,
> jamal
I see no cases where negative time value is a valid input.
Doing audit of netem:
- slot times
parsing rejects -10ms for min delay and -100ms for max delay
- delay
negative value is accepted, but internally acts like 0
- jitter
negative value is rejected (i.e What is "-2s")
- slot distribution delay
same as regular delay, accepted but internally acts like 0
negative jitter is rejected "Non positive jitter"
Gate:
Codel:
- setting negative target, interval or ce_threshold gives huge value
4.29e+03s
Pi:
- setting negative target gets absolute value
Hhf:
- setting negative value gets 4.29e+03s
So I can't see any valid use for negative intervals
^ permalink raw reply
* Re: [PATCH RFC bpf-next 0/8] bpf: add support for KASAN checks in JITed programs
From: Ihor Solodrai @ 2026-04-24 23:10 UTC (permalink / raw)
To: Alexis Lothoré (eBPF Foundation), 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, H. Peter Anvin, Shuah Khan, Maxime Coquelin,
Alexandre Torgue, Andrey Ryabinin, Alexander Potapenko,
Andrey Konovalov, Dmitry Vyukov, Vincenzo Frascino, Andrew Morton
Cc: ebpf, Bastien Curutchet, Thomas Petazzoni, Xu Kuohai, bpf,
linux-kernel, netdev, linux-kselftest, linux-stm32,
linux-arm-kernel, kasan-dev, linux-mm
In-Reply-To: <20260413-kasan-v1-0-1a5831230821@bootlin.com>
On 4/13/26 11:28 AM, Alexis Lothoré (eBPF Foundation) wrote:
> Hello,
> this series aims to bring basic support for KASAN checks to BPF JITed
> programs. This follows the first RFC posted in [1].
Hi Alexis,
Thank you for working on this, it's a real testing gap.
I have a few comments, see below.
The series doesn't apply cleanly on bpf-next right now, but I was able
to apply to a little older revision (eb5249b12507).
>
> KASAN allows to spot memory management mistakes by reserving a fraction
> of memory as "shadow memory" that will map to the rest of the memory and
> allow its monitoring. Each memory-accessing instruction is then
> instrumented at build time to call some ASAN check function, that will
> analyze the corresponding bits in shadow memory, and if it detects the
> access as invalid, trigger a detailed report. The goal of this series is
> to replicate this mechanism for BPF programs when they are being JITed
> into native instructions: that's then the (runtime) JIT compiler who is
> in charge of inserting calls to the corresponding kasan checks, when a
> program is being loaded into the kernel. This task involves:
> - identifying at program load time the instructions performing memory
> accesses
> - identifying those accesses properties (size ? read or write ?) to
> define the relevant kasan check function to call
> - just before the identified instructions:
> - perform the basic context saving (ie: saving registers)
> - inserting a call to the relevant kasan check function
> - restore context
> - whenever the instrumented program executes, if it performs an invalid
> access, it triggers a kasan report identical to those instrumented on
> kernel side at build time.
>
> As discussed in [1], this series is based on some choices and
> assumptions:
> - it focuses on x86_64 for now, and so only on KASAN_GENERIC
I wonder if it's feasible to implement KASAN support on the verifier
side in post-verification fixups. AI slop for illustration:
;; Original (1 BPF insn):
dst = *(u64 *)(src + off) ; BPF_LDX | BPF_MEM | BPF_DW
;; Rewrite (~7 BPF insns):
r_tmp1 = src ; BPF_MOV64_REG
r_tmp1 += off ; BPF_ALU64 | BPF_ADD | K (full address)
r_tmp2 = r_tmp1 ; copy
r_tmp2 >>= 3 ; KASAN_SHADOW_SCALE_SHIFT
r_tmp2 += KASAN_SHADOW_OFFSET ; shadow address
r_tmp3 = *(u8 *)(r_tmp2 + 0) ; BPF_LDX | BPF_B (load shadow byte)
if r_tmp3 != 0 goto +2 ; BPF_JNE | PC+2
dst = *(u64 *)(src + off) ; original access (fast path)
goto +1 ; skip slowpath
call __asan_report_load8 ; BPF kfunc
dst = *(u64 *)(src + off) ; retry the access after report (non-fatal)
A sort of inline kasan directly in BPF.
There are plenty of issues with it: instruction limit, exposing asan
API as kfuncs, etc. On the flip side we get cross-arch support out of
the box with no or mininal JIT changes.
Honestly I'm not excited about this approach, but curious if anyone
thought about this, or maybe it was already discussed?
> - not all memory accessing BPF instructions are being instrumented:
> - it focuses on STX/LDX instructions
> - it discards instructions accessing BPF program stack (already
> monitored by page guards)
> - it discards possibly faulting instructions, like BPF_PROBE_MEM or
> BPF_PROBE_ATOMIC insns
>
> The series is marked and sent as RFC:
> - to allow collecting feedback early and make sure that it goes into the
> right direction
> - because it depends on Xu's work to pass data between the verifier and
> JIT compilers. This work is not merged yet, see [2]. I have been
> tracking the various revisions he sent on the ML and based my local
> branch on his work
> - because tests brought by this series currently can't run on BPF CI:
> they expect kasan multishot to be enabled, otherwise the first test
> will make all other kasan-related tests fail.
AFAICT this can be trivially fixed on BPF CI side, we just need to set
kasan_multi_shot for the VMs running the tests. I will do that, your
next revision doesn't have to be and RFC.
> - because some cases like atomic loads/stores are not instrumented yet
> (and are still making me scratch my head)
> - because it will hopefully provide a good basis to discuss the topic at
> LSFMMBPF (see [3])
Apparently, KASAN reporting routine takes a lock [1]:
__asan_load()
-> check_region_inline()
-> kasan_report()
-> start_report()
-> raw_spin_lock_irqsave(&report_lock, *flags);
BPF programs can run in NMI context, and so it appears to be possible
to get an unflagged (because of lockdep_off() in start_report)
deadlock, if an NMI fires on a CPU already holding report_lock.
Although I guess you'd need two KASAN bugs to happen
simultaneously for that to occur?... A rare event, I would hope.
It could be addressed with either in_nmi() check at runtime, or
forbidding kasan for NMI-runnable BPF program types.
That said, this may be a case of being overly defensive to appease the
ai overlords.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/kasan/report.c?h=v7.0#n204
>
> Despite this series not being ready for integration yet, anyone
> interested in running it locally can perform the following steps to run
> the JITed KASAN instrumentation selftests:
> - rebasing locally this series on [2]
> - building and running the corresponding kernel with kasan_multi_shot
> enabled
> - running `test_progs -a kasan`
>
> And should get a variety of KASAN tests executed for BPF programs:
>
> #162/1 kasan/bpf_kasan_uaf_read_1:OK
> #162/2 kasan/bpf_kasan_uaf_read_2:OK
> #162/3 kasan/bpf_kasan_uaf_read_4:OK
> #162/4 kasan/bpf_kasan_uaf_read_8:OK
> #162/5 kasan/bpf_kasan_uaf_write_1:OK
> #162/6 kasan/bpf_kasan_uaf_write_2:OK
> #162/7 kasan/bpf_kasan_uaf_write_4:OK
> #162/8 kasan/bpf_kasan_uaf_write_8:OK
> #162/9 kasan/bpf_kasan_oob_read_1:OK
> #162/10 kasan/bpf_kasan_oob_read_2:OK
> #162/11 kasan/bpf_kasan_oob_read_4:OK
> #162/12 kasan/bpf_kasan_oob_read_8:OK
> #162/13 kasan/bpf_kasan_oob_write_1:OK
> #162/14 kasan/bpf_kasan_oob_write_2:OK
> #162/15 kasan/bpf_kasan_oob_write_4:OK
> #162/16 kasan/bpf_kasan_oob_write_8:OK
> #162 kasan:OK
> Summary: 1/16 PASSED, 0 SKIPPED, 0 FAILED
>
> [1] https://lore.kernel.org/bpf/DG7UG112AVBC.JKYISDTAM30T@bootlin.com/
> [2] https://lore.kernel.org/bpf/cover.1776062885.git.xukuohai@hotmail.com/
> [3] https://lore.kernel.org/bpf/DGGNCXX79H8O.2P6K8L1QW1M8K@bootlin.com/
>
> Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
> ---
> Alexis Lothoré (eBPF Foundation) (8):
> kasan: expose generic kasan helpers
> bpf: mark instructions accessing program stack
> bpf: add BPF_JIT_KASAN for KASAN instrumentation of JITed programs
> bpf, x86: add helper to emit kasan checks in x86 JITed programs
> bpf, x86: emit KASAN checks into x86 JITed programs
> selftests/bpf: do not run verifier JIT tests when BPF_JIT_KASAN is enabled
> bpf, x86: enable KASAN for JITed programs on x86
> selftests/bpf: add tests to validate KASAN on JIT programs
>
> arch/x86/Kconfig | 1 +
> arch/x86/net/bpf_jit_comp.c | 106 +++++++++++++
> include/linux/bpf.h | 2 +
> include/linux/bpf_verifier.h | 2 +
> include/linux/kasan.h | 13 ++
> kernel/bpf/Kconfig | 9 ++
> kernel/bpf/core.c | 10 ++
> kernel/bpf/verifier.c | 7 +
> mm/kasan/kasan.h | 10 --
> tools/testing/selftests/bpf/prog_tests/kasan.c | 165 +++++++++++++++++++++
> tools/testing/selftests/bpf/progs/kasan.c | 146 ++++++++++++++++++
> .../testing/selftests/bpf/test_kmods/bpf_testmod.c | 79 ++++++++++
> tools/testing/selftests/bpf/test_loader.c | 5 +
> tools/testing/selftests/bpf/unpriv_helpers.c | 5 +
> tools/testing/selftests/bpf/unpriv_helpers.h | 1 +
> 15 files changed, 551 insertions(+), 10 deletions(-)
> ---
> base-commit: 7990a071b32887a1a883952e8cf60134b6d6fea0
> change-id: 20260126-kasan-fcd68f64cd7b
>
> Best regards,
> --
> Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
>
^ permalink raw reply
* Re: [PATCH RFC bpf-next 2/8] bpf: mark instructions accessing program stack
From: Ihor Solodrai @ 2026-04-24 23:18 UTC (permalink / raw)
To: Alexis Lothoré (eBPF Foundation), 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, H. Peter Anvin, Shuah Khan, Maxime Coquelin,
Alexandre Torgue, Andrey Ryabinin, Alexander Potapenko,
Andrey Konovalov, Dmitry Vyukov, Vincenzo Frascino, Andrew Morton
Cc: ebpf, Bastien Curutchet, Thomas Petazzoni, Xu Kuohai, bpf,
linux-kernel, netdev, linux-kselftest, linux-stm32,
linux-arm-kernel, kasan-dev, linux-mm
In-Reply-To: <20260413-kasan-v1-2-1a5831230821@bootlin.com>
On 4/13/26 11:28 AM, Alexis Lothoré (eBPF Foundation) wrote:
> In order to prepare to emit KASAN checks in JITed programs, JIT
> compilers need to be aware about whether some load/store instructions
> are targeting the bpf program stack, as those should not be monitored
> (we already have guard pages for that, and it is difficult anyway to
> correctly monitor any kind of data passed on stack).
>
> To support this need, make the BPF verifier mark the instructions that
> access program stack:
> - add a setter that allows the verifier to mark instructions accessing
> the program stack
> - add a getter that allows JIT compilers to check whether instructions
> being JITed are accessing the stack
>
> Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
> ---
> include/linux/bpf.h | 2 ++
> include/linux/bpf_verifier.h | 2 ++
> kernel/bpf/core.c | 10 ++++++++++
> kernel/bpf/verifier.c | 7 +++++++
> 4 files changed, 21 insertions(+)
>
> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index b4b703c90ca9..774a0395c498 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
> @@ -1543,6 +1543,8 @@ void bpf_jit_uncharge_modmem(u32 size);
> bool bpf_prog_has_trampoline(const struct bpf_prog *prog);
> bool bpf_insn_is_indirect_target(const struct bpf_verifier_env *env, const struct bpf_prog *prog,
> int insn_idx);
> +bool bpf_insn_accesses_stack(const struct bpf_verifier_env *env,
> + const struct bpf_prog *prog, int insn_idx);
> #else
> static inline int bpf_trampoline_link_prog(struct bpf_tramp_link *link,
> struct bpf_trampoline *tr,
> diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
> index b148f816f25b..ab99ed4c4227 100644
> --- a/include/linux/bpf_verifier.h
> +++ b/include/linux/bpf_verifier.h
> @@ -660,6 +660,8 @@ struct bpf_insn_aux_data {
> u16 const_reg_map_mask;
> u16 const_reg_subprog_mask;
> u32 const_reg_vals[10];
> + /* instruction accesses stack */
> + bool accesses_stack;
> };
>
> #define MAX_USED_MAPS 64 /* max number of maps accessed by one eBPF program */
> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> index 8b018ff48875..340abfdadbed 100644
> --- a/kernel/bpf/core.c
> +++ b/kernel/bpf/core.c
> @@ -1582,6 +1582,16 @@ bool bpf_insn_is_indirect_target(const struct bpf_verifier_env *env, const struc
> insn_idx += prog->aux->subprog_start;
> return env->insn_aux_data[insn_idx].indirect_target;
> }
> +
> +bool bpf_insn_accesses_stack(const struct bpf_verifier_env *env,
> + const struct bpf_prog *prog, int insn_idx)
> +{
> + if (!env)
> + return false;
> + insn_idx += prog->aux->subprog_start;
> + return env->insn_aux_data[insn_idx].accesses_stack;
> +}
> +
> #endif /* CONFIG_BPF_JIT */
>
> /* Base function for offset calculation. Needs to go into .text section,
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 1e36b9e91277..7bce4fb4e540 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -3502,6 +3502,11 @@ static void mark_indirect_target(struct bpf_verifier_env *env, int idx)
> env->insn_aux_data[idx].indirect_target = true;
> }
>
> +static void mark_insn_accesses_stack(struct bpf_verifier_env *env, int idx)
> +{
> + env->insn_aux_data[idx].accesses_stack = true;
> +}
> +
> #define LR_FRAMENO_BITS 3
> #define LR_SPI_BITS 6
> #define LR_ENTRY_BITS (LR_SPI_BITS + LR_FRAMENO_BITS + 1)
> @@ -6490,6 +6495,8 @@ static int check_mem_access(struct bpf_verifier_env *env, int insn_idx, u32 regn
> else
> err = check_stack_write(env, regno, off, size,
> value_regno, insn_idx);
> +
> + mark_insn_accesses_stack(env, insn_idx);
I am not sure this can be done unconditionally here.
It may be possible in different states to have different pointer
types for the affected reg (PTR_TO_STACK in one execution path and say
PTR_TO_MAP_VALUE in another). And if set uncoditionally,
instrumentation may be skipped for legitimate targets.
Maybe reset by default in check_mem_access()?
> } else if (reg_is_pkt_pointer(reg)) {
> if (t == BPF_WRITE && !may_access_direct_pkt_data(env, NULL, t)) {
> verbose(env, "cannot write into packet\n");
>
^ permalink raw reply
* [PATCH iproute2] remove hamradio protocols
From: Stephen Hemminger @ 2026-04-24 23:24 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger
The ax25, rose, and netrom have been removed upstream.
Drop support for those protocols from iproute2.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
Makefile | 9 ---
include/uapi/linux/ax25.h | 117 --------------------------------------
include/uapi/linux/rose.h | 91 -----------------------------
include/utils.h | 6 --
lib/ax25_ntop.c | 82 --------------------------
lib/ll_addr.c | 6 --
lib/netrom_ntop.c | 23 --------
lib/rose_ntop.c | 56 ------------------
8 files changed, 390 deletions(-)
delete mode 100644 include/uapi/linux/ax25.h
delete mode 100644 include/uapi/linux/rose.h
delete mode 100644 lib/ax25_ntop.c
delete mode 100644 lib/netrom_ntop.c
delete mode 100644 lib/rose_ntop.c
diff --git a/Makefile b/Makefile
index 1bebf08f..6f5d4765 100644
--- a/Makefile
+++ b/Makefile
@@ -45,18 +45,9 @@ DEFINES+=-DCONF_USR_DIR=\"$(CONF_USR_DIR)\" \
-DARPDDIR=\"$(ARPDDIR)\" \
-DCONF_COLOR=$(CONF_COLOR)
-#options for AX.25
-ADDLIB+=ax25_ntop.o
-
-#options for AX.25
-ADDLIB+=rose_ntop.o
-
#options for mpls
ADDLIB+=mpls_ntop.o mpls_pton.o
-#options for NETROM
-ADDLIB+=netrom_ntop.o
-
CC := gcc
HOSTCC ?= $(CC)
DEFINES += -D_GNU_SOURCE
diff --git a/include/uapi/linux/ax25.h b/include/uapi/linux/ax25.h
deleted file mode 100644
index b496b9d8..00000000
--- a/include/uapi/linux/ax25.h
+++ /dev/null
@@ -1,117 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-/*
- * These are the public elements of the Linux kernel AX.25 code. A similar
- * file netrom.h exists for the NET/ROM protocol.
- */
-
-#ifndef AX25_KERNEL_H
-#define AX25_KERNEL_H
-
-#include <linux/socket.h>
-
-#define AX25_MTU 256
-#define AX25_MAX_DIGIS 8
-
-#define AX25_WINDOW 1
-#define AX25_T1 2
-#define AX25_N2 3
-#define AX25_T3 4
-#define AX25_T2 5
-#define AX25_BACKOFF 6
-#define AX25_EXTSEQ 7
-#define AX25_PIDINCL 8
-#define AX25_IDLE 9
-#define AX25_PACLEN 10
-#define AX25_IAMDIGI 12
-
-#define AX25_KILL 99
-
-#define SIOCAX25GETUID (SIOCPROTOPRIVATE+0)
-#define SIOCAX25ADDUID (SIOCPROTOPRIVATE+1)
-#define SIOCAX25DELUID (SIOCPROTOPRIVATE+2)
-#define SIOCAX25NOUID (SIOCPROTOPRIVATE+3)
-#define SIOCAX25OPTRT (SIOCPROTOPRIVATE+7)
-#define SIOCAX25CTLCON (SIOCPROTOPRIVATE+8)
-#define SIOCAX25GETINFOOLD (SIOCPROTOPRIVATE+9)
-#define SIOCAX25ADDFWD (SIOCPROTOPRIVATE+10)
-#define SIOCAX25DELFWD (SIOCPROTOPRIVATE+11)
-#define SIOCAX25DEVCTL (SIOCPROTOPRIVATE+12)
-#define SIOCAX25GETINFO (SIOCPROTOPRIVATE+13)
-
-#define AX25_SET_RT_IPMODE 2
-
-#define AX25_NOUID_DEFAULT 0
-#define AX25_NOUID_BLOCK 1
-
-typedef struct {
- char ax25_call[7]; /* 6 call + SSID (shifted ascii!) */
-} ax25_address;
-
-struct sockaddr_ax25 {
- __kernel_sa_family_t sax25_family;
- ax25_address sax25_call;
- int sax25_ndigis;
- /* Digipeater ax25_address sets follow */
-};
-
-#define sax25_uid sax25_ndigis
-
-struct full_sockaddr_ax25 {
- struct sockaddr_ax25 fsa_ax25;
- ax25_address fsa_digipeater[AX25_MAX_DIGIS];
-};
-
-struct ax25_routes_struct {
- ax25_address port_addr;
- ax25_address dest_addr;
- unsigned char digi_count;
- ax25_address digi_addr[AX25_MAX_DIGIS];
-};
-
-struct ax25_route_opt_struct {
- ax25_address port_addr;
- ax25_address dest_addr;
- int cmd;
- int arg;
-};
-
-struct ax25_ctl_struct {
- ax25_address port_addr;
- ax25_address source_addr;
- ax25_address dest_addr;
- unsigned int cmd;
- unsigned long arg;
- unsigned char digi_count;
- ax25_address digi_addr[AX25_MAX_DIGIS];
-};
-
-/* this will go away. Please do not export to user land */
-struct ax25_info_struct_deprecated {
- unsigned int n2, n2count;
- unsigned int t1, t1timer;
- unsigned int t2, t2timer;
- unsigned int t3, t3timer;
- unsigned int idle, idletimer;
- unsigned int state;
- unsigned int rcv_q, snd_q;
-};
-
-struct ax25_info_struct {
- unsigned int n2, n2count;
- unsigned int t1, t1timer;
- unsigned int t2, t2timer;
- unsigned int t3, t3timer;
- unsigned int idle, idletimer;
- unsigned int state;
- unsigned int rcv_q, snd_q;
- unsigned int vs, vr, va, vs_max;
- unsigned int paclen;
- unsigned int window;
-};
-
-struct ax25_fwd_struct {
- ax25_address port_from;
- ax25_address port_to;
-};
-
-#endif
diff --git a/include/uapi/linux/rose.h b/include/uapi/linux/rose.h
deleted file mode 100644
index 19aa4693..00000000
--- a/include/uapi/linux/rose.h
+++ /dev/null
@@ -1,91 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-/*
- * These are the public elements of the Linux kernel Rose implementation.
- * For kernel AX.25 see the file ax25.h. This file requires ax25.h for the
- * definition of the ax25_address structure.
- */
-
-#ifndef ROSE_KERNEL_H
-#define ROSE_KERNEL_H
-
-#include <linux/socket.h>
-#include <linux/ax25.h>
-
-#define ROSE_MTU 251
-
-#define ROSE_MAX_DIGIS 6
-
-#define ROSE_DEFER 1
-#define ROSE_T1 2
-#define ROSE_T2 3
-#define ROSE_T3 4
-#define ROSE_IDLE 5
-#define ROSE_QBITINCL 6
-#define ROSE_HOLDBACK 7
-
-#define SIOCRSGCAUSE (SIOCPROTOPRIVATE+0)
-#define SIOCRSSCAUSE (SIOCPROTOPRIVATE+1)
-#define SIOCRSL2CALL (SIOCPROTOPRIVATE+2)
-#define SIOCRSSL2CALL (SIOCPROTOPRIVATE+2)
-#define SIOCRSACCEPT (SIOCPROTOPRIVATE+3)
-#define SIOCRSCLRRT (SIOCPROTOPRIVATE+4)
-#define SIOCRSGL2CALL (SIOCPROTOPRIVATE+5)
-#define SIOCRSGFACILITIES (SIOCPROTOPRIVATE+6)
-
-#define ROSE_DTE_ORIGINATED 0x00
-#define ROSE_NUMBER_BUSY 0x01
-#define ROSE_INVALID_FACILITY 0x03
-#define ROSE_NETWORK_CONGESTION 0x05
-#define ROSE_OUT_OF_ORDER 0x09
-#define ROSE_ACCESS_BARRED 0x0B
-#define ROSE_NOT_OBTAINABLE 0x0D
-#define ROSE_REMOTE_PROCEDURE 0x11
-#define ROSE_LOCAL_PROCEDURE 0x13
-#define ROSE_SHIP_ABSENT 0x39
-
-typedef struct {
- char rose_addr[5];
-} rose_address;
-
-struct sockaddr_rose {
- __kernel_sa_family_t srose_family;
- rose_address srose_addr;
- ax25_address srose_call;
- int srose_ndigis;
- ax25_address srose_digi;
-};
-
-struct full_sockaddr_rose {
- __kernel_sa_family_t srose_family;
- rose_address srose_addr;
- ax25_address srose_call;
- unsigned int srose_ndigis;
- ax25_address srose_digis[ROSE_MAX_DIGIS];
-};
-
-struct rose_route_struct {
- rose_address address;
- unsigned short mask;
- ax25_address neighbour;
- char device[16];
- unsigned char ndigis;
- ax25_address digipeaters[AX25_MAX_DIGIS];
-};
-
-struct rose_cause_struct {
- unsigned char cause;
- unsigned char diagnostic;
-};
-
-struct rose_facilities_struct {
- rose_address source_addr, dest_addr;
- ax25_address source_call, dest_call;
- unsigned char source_ndigis, dest_ndigis;
- ax25_address source_digis[ROSE_MAX_DIGIS];
- ax25_address dest_digis[ROSE_MAX_DIGIS];
- unsigned int rand;
- rose_address fail_addr;
- ax25_address fail_call;
-};
-
-#endif
diff --git a/include/utils.h b/include/utils.h
index b68d6bc4..e4e318e2 100644
--- a/include/utils.h
+++ b/include/utils.h
@@ -199,15 +199,9 @@ int matches(const char *prefix, const char *string);
int inet_addr_match(const inet_prefix *a, const inet_prefix *b, int bits);
int inet_addr_match_rta(const inet_prefix *m, const struct rtattr *rta);
-const char *ax25_ntop(int af, const void *addr, char *str, socklen_t len);
-
-const char *rose_ntop(int af, const void *addr, char *buf, socklen_t buflen);
-
const char *mpls_ntop(int af, const void *addr, char *str, size_t len);
int mpls_pton(int af, const char *src, void *addr, size_t alen);
-const char *netrom_ntop(int af, const void *addr, char *str, socklen_t len);
-
extern int __iproute2_hz_internal;
int __get_hz(void);
diff --git a/lib/ax25_ntop.c b/lib/ax25_ntop.c
deleted file mode 100644
index 3a72a43e..00000000
--- a/lib/ax25_ntop.c
+++ /dev/null
@@ -1,82 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-
-#include <errno.h>
-#include <sys/socket.h>
-#include <linux/ax25.h>
-
-#include "utils.h"
-
-const char *ax25_ntop1(const ax25_address *src, char *dst, socklen_t size);
-
-/*
- * AX.25 addresses are based on Amateur radio callsigns followed by an SSID
- * like XXXXXX-SS where the callsign consists of up to 6 ASCII characters
- * which are either letters or digits and the SSID is a decimal number in the
- * range 0..15.
- * Amateur radio callsigns are assigned by a country's relevant authorities
- * and are 3..6 characters though a few countries have assigned callsigns
- * longer than that. AX.25 is not able to handle such longer callsigns.
- * There are further restrictions on the format of valid callsigns by
- * applicable national and international law. Linux doesn't need to care and
- * will happily accept anything that consists of 6 ASCII characters in the
- * range of A-Z and 0-9 for a callsign such as the default AX.25 MAC address
- * LINUX-1 and the default broadcast address QST-0.
- * The SSID is just a number and not encoded in ASCII digits.
- *
- * Being based on HDLC AX.25 encodes addresses by shifting them one bit left
- * thus zeroing bit 0, the HDLC extension bit for all but the last bit of
- * a packet's address field but for our purposes here we're not considering
- * the HDLC extension bit that is it will always be zero.
- *
- * Linux' internal representation of AX.25 addresses in Linux is very similar
- * to this on the on-air or on-the-wire format. The callsign is padded to
- * 6 octets by adding spaces, followed by the SSID octet then all 7 octets
- * are left-shifted by one bit.
- *
- * For example, for the address "LINUX-1" the callsign is LINUX and SSID is 1
- * the internal format is 98:92:9c:aa:b0:40:02.
- */
-
-const char *ax25_ntop1(const ax25_address *src, char *dst, socklen_t size)
-{
- char c, *s;
- int n;
-
- for (n = 0, s = dst; n < 6; n++) {
- c = (src->ax25_call[n] >> 1) & 0x7f;
- if (c != ' ')
- *s++ = c;
- }
-
- *s++ = '-';
-
- n = ((src->ax25_call[6] >> 1) & 0x0f);
- if (n > 9) {
- *s++ = '1';
- n -= 10;
- }
-
- *s++ = n + '0';
- *s++ = '\0';
-
- if (*dst == '\0' || *dst == '-') {
- dst[0] = '*';
- dst[1] = '\0';
- }
-
- return dst;
-}
-
-const char *ax25_ntop(int af, const void *addr, char *buf, socklen_t buflen)
-{
- switch (af) {
- case AF_AX25:
- errno = 0;
- return ax25_ntop1((ax25_address *)addr, buf, buflen);
-
- default:
- errno = EAFNOSUPPORT;
- }
-
- return NULL;
-}
diff --git a/lib/ll_addr.c b/lib/ll_addr.c
index 5e924591..7a9eb3a4 100644
--- a/lib/ll_addr.c
+++ b/lib/ll_addr.c
@@ -35,12 +35,6 @@ const char *ll_addr_n2a(const unsigned char *addr, int alen, int type,
if (alen == 16 && (type == ARPHRD_TUNNEL6 || type == ARPHRD_IP6GRE))
return inet_ntop(AF_INET6, addr, buf, blen);
- if (alen == 7 && type == ARPHRD_AX25)
- return ax25_ntop(AF_AX25, addr, buf, blen);
- if (alen == 7 && type == ARPHRD_NETROM)
- return netrom_ntop(AF_NETROM, addr, buf, blen);
- if (alen == 5 && type == ARPHRD_ROSE)
- return rose_ntop(AF_ROSE, addr, buf, blen);
snprintf(buf, blen, "%02x", addr[0]);
for (i = 1, l = 2; i < alen && l < blen; i++, l += 3)
diff --git a/lib/netrom_ntop.c b/lib/netrom_ntop.c
deleted file mode 100644
index 3dd6cb0b..00000000
--- a/lib/netrom_ntop.c
+++ /dev/null
@@ -1,23 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-
-#include <sys/socket.h>
-#include <errno.h>
-#include <linux/ax25.h>
-
-#include "utils.h"
-
-const char *ax25_ntop1(const ax25_address *src, char *dst, socklen_t size);
-
-const char *netrom_ntop(int af, const void *addr, char *buf, socklen_t buflen)
-{
- switch (af) {
- case AF_NETROM:
- errno = 0;
- return ax25_ntop1((ax25_address *)addr, buf, buflen);
-
- default:
- errno = EAFNOSUPPORT;
- }
-
- return NULL;
-}
diff --git a/lib/rose_ntop.c b/lib/rose_ntop.c
deleted file mode 100644
index c9ba712c..00000000
--- a/lib/rose_ntop.c
+++ /dev/null
@@ -1,56 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-
-#include <stdio.h>
-#include <stdlib.h>
-#include <unistd.h>
-#include <fcntl.h>
-#include <sys/ioctl.h>
-#include <sys/socket.h>
-#include <netinet/in.h>
-#include <arpa/inet.h>
-#include <string.h>
-#include <errno.h>
-
-#include <linux/netdevice.h>
-#include <linux/if_arp.h>
-#include <linux/sockios.h>
-#include <linux/rose.h>
-
-#include "rt_names.h"
-#include "utils.h"
-
-static const char *rose_ntop1(const rose_address *src, char *dst,
- socklen_t size)
-{
- char *p = dst;
- int i;
-
- if (size < 10)
- return NULL;
-
- for (i = 0; i < 5; i++) {
- *p++ = '0' + ((src->rose_addr[i] >> 4) & 0xf);
- *p++ = '0' + ((src->rose_addr[i] ) & 0xf);
- }
-
- if (size == 10)
- return dst;
-
- *p = '\0';
-
- return dst;
-}
-
-const char *rose_ntop(int af, const void *addr, char *buf, socklen_t buflen)
-{
- switch (af) {
- case AF_ROSE:
- errno = 0;
- return rose_ntop1((rose_address *)addr, buf, buflen);
-
- default:
- errno = EAFNOSUPPORT;
- }
-
- return NULL;
-}
--
2.53.0
^ permalink raw reply related
* Re: [PATCH RFC bpf-next 0/8] bpf: add support for KASAN checks in JITed programs
From: Alexei Starovoitov @ 2026-04-24 23:28 UTC (permalink / raw)
To: Ihor Solodrai
Cc: Alexis Lothoré (eBPF Foundation), 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,
Andrey Konovalov, 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: <71fb19ff-6dde-43f4-a0e9-5c8cf2ba4ed4@linux.dev>
On Fri, Apr 24, 2026 at 4:10 PM Ihor Solodrai <ihor.solodrai@linux.dev> wrote:
>
> I wonder if it's feasible to implement KASAN support on the verifier
> side in post-verification fixups. AI slop for illustration:
>
> ;; Original (1 BPF insn):
> dst = *(u64 *)(src + off) ; BPF_LDX | BPF_MEM | BPF_DW
>
> ;; Rewrite (~7 BPF insns):
> r_tmp1 = src ; BPF_MOV64_REG
> r_tmp1 += off ; BPF_ALU64 | BPF_ADD | K (full address)
> r_tmp2 = r_tmp1 ; copy
> r_tmp2 >>= 3 ; KASAN_SHADOW_SCALE_SHIFT
> r_tmp2 += KASAN_SHADOW_OFFSET ; shadow address
> r_tmp3 = *(u8 *)(r_tmp2 + 0) ; BPF_LDX | BPF_B (load shadow byte)
> if r_tmp3 != 0 goto +2 ; BPF_JNE | PC+2
> dst = *(u64 *)(src + off) ; original access (fast path)
> goto +1 ; skip slowpath
> call __asan_report_load8 ; BPF kfunc
> dst = *(u64 *)(src + off) ; retry the access after report (non-fatal)
>
> A sort of inline kasan directly in BPF.
>
> There are plenty of issues with it: instruction limit, exposing asan
> API as kfuncs, etc. On the flip side we get cross-arch support out of
> the box with no or mininal JIT changes.
>
> Honestly I'm not excited about this approach, but curious if anyone
> thought about this, or maybe it was already discussed?
We discussed this.
It won't work because we don't have that many temp registers for once
and second it has to preserve all (both callee and caller saved regs).
This is arch specific.
Second, we do not want other archs. This feature is x86-64 only.
It's being added to find _verifier_ bugs. To do that one arch is enough.
>
> > - not all memory accessing BPF instructions are being instrumented:
> > - it focuses on STX/LDX instructions
> > - it discards instructions accessing BPF program stack (already
> > monitored by page guards)
> > - it discards possibly faulting instructions, like BPF_PROBE_MEM or
> > BPF_PROBE_ATOMIC insns
> >
> > The series is marked and sent as RFC:
> > - to allow collecting feedback early and make sure that it goes into the
> > right direction
> > - because it depends on Xu's work to pass data between the verifier and
> > JIT compilers. This work is not merged yet, see [2]. I have been
> > tracking the various revisions he sent on the ML and based my local
> > branch on his work
> > - because tests brought by this series currently can't run on BPF CI:
> > they expect kasan multishot to be enabled, otherwise the first test
> > will make all other kasan-related tests fail.
>
> AFAICT this can be trivially fixed on BPF CI side, we just need to set
> kasan_multi_shot for the VMs running the tests. I will do that, your
> next revision doesn't have to be and RFC.
+1
> > - because some cases like atomic loads/stores are not instrumented yet
> > (and are still making me scratch my head)
> > - because it will hopefully provide a good basis to discuss the topic at
> > LSFMMBPF (see [3])
>
> Apparently, KASAN reporting routine takes a lock [1]:
>
> __asan_load()
> -> check_region_inline()
> -> kasan_report()
> -> start_report()
> -> raw_spin_lock_irqsave(&report_lock, *flags);
>
> BPF programs can run in NMI context, and so it appears to be possible
> to get an unflagged (because of lockdep_off() in start_report)
> deadlock, if an NMI fires on a CPU already holding report_lock.
> Although I guess you'd need two KASAN bugs to happen
> simultaneously for that to occur?... A rare event, I would hope.
>
> It could be addressed with either in_nmi() check at runtime, or
> forbidding kasan for NMI-runnable BPF program types.
We don't need that. If this bpf KASAN finds a bug, it means that
it found a verifier bug. All things are out of the window.
kasan_report() splat can just as well be the last thing that users will see.
^ 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