| Message ID | 20260927223436.269024-2-pablo@netfilter.org |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [net-next,01/11] netfilter: synproxy: fix reset of ct seqadj when reopening a connection | expand |
Hi! This is an automated message. This series looks like a fix, but its commit messages seem to be missing some information: - How the issue was discovered, e.g. hit in production, hit during development, syzbot report, manual code inspection, LLM or static analysis tool scan. - Whether the issue was actually triggered, or is only theoretical (e.g. found by code inspection). If it was triggered please include the symptoms, like the stack trace or error messages. Please do not repost the series just to address the above. Instead, reply to this email with the missing information, so that reviewers can take it into account. If the series needs another revision for other reasons, please include the information in the commit messages then. The evaluation is done by an LLM so it may be wrong, if you think that is the case please reply and explain.
Hi, On Sun, Sep 27, 2026 at 10:40:44PM +0000, netdev-bot+sinfo@kernel.org wrote: > Hi! > > This is an automated message. This series looks like a fix, but its > commit messages seem to be missing some information: > > - How the issue was discovered, e.g. hit in production, hit during > development, syzbot report, manual code inspection, LLM or static > analysis tool scan. > > - Whether the issue was actually triggered, or is only theoretical > (e.g. found by code inspection). If it was triggered please include > the symptoms, like the stack trace or error messages. > > Please do not repost the series just to address the above. Instead, > reply to this email with the missing information, so that reviewers > can take it into account. If the series needs another revision for > other reasons, please include the information in the commit messages > then. > > The evaluation is done by an LLM so it may be wrong, if you think > that is the case please reply and explain. This are correctness fixes (no crashes to my knowledged, hence I decided to target net-next) as the cover letter specifies: Patch #1 TCP sequence tracking issue was reported by sashiko as the cover letter says. Patch #2 Just documentation update to fix incorrect information about the maximum number of expectations. Patch #3 Just a cleanup patch to remove a break; Patch #4 Just a cleanup, typos in comments. Patch #5 and #6 are the result of a human triggered review of the conntrack error stats by Phil Sutter, I think. Patch #7 is a preparation patch for #8. Patch #8 removes a unnecessary workqueue flush, submitter does not specify if it is visible in production, I suspect with a very large number of netns it must be. Author does not claim LLM assistance. Patch #9 is a fix triggered by sashiko report IIRC, I deemed it too large for net so I am routing this rework-fix to net-next. Patch #10 is a feature fix, IPv6 filtering does not work. I suspect it was found when trying to use this (broken) feature by the submitter. Patch #11 Ilya Maximets reports the CTA_ZONE filtering feature is not easy to infer from userspace, I don't think LLM triggered this, it looks more like an improvement to help userspace tools discover this feature. This is human written reply, my cover letter has been generated by me too to provide more context on these patches. Thanks!
Hello: This series was applied to netdev/net-next.git (main) by Pablo Neira Ayuso <pablo@netfilter.org>: On Mon, 28 Sep 2026 00:34:26 +0200 you wrote: > From: Fernando Fernandez Mancera <fmancera@suse.de> > > SYNPROXY is resetting conntrack seqadj when a closed connection is > re-opened, but it was using nf_ct_seqadj_init() which is a no-op for a > zero offset. > > This patch introduces nf_ct_seqadj_reset() which sets the offset values > directly to zero and avoid setting IPS_SEQ_ADJUST_BIT flag, it changes > SYNPROXY code to use it when needed. > > [...] Here is the summary with links: - [net-next,01/11] netfilter: synproxy: fix reset of ct seqadj when reopening a connection https://git.kernel.org/netdev/net-next/c/a8708aa9fe10 - [net-next,02/11] netfilter: conntrack: fix nf_conntrack_expect_max default value in documentation https://git.kernel.org/netdev/net-next/c/409df11c5674 - [net-next,03/11] netfilter: osf: remove unreachable break in nf_osf_ttl() https://git.kernel.org/netdev/net-next/c/32cbf7a8e556 - [net-next,04/11] netfilter: fix several typos in comments https://git.kernel.org/netdev/net-next/c/d8cefdc18124 - [net-next,05/11] netfilter: conntrack: Untangle insert_failed counter from others https://git.kernel.org/netdev/net-next/c/96ed91f5773a - [net-next,06/11] netfilter: conntrack: Untangle drop and invalid counters https://git.kernel.org/netdev/net-next/c/2ac41d7009c7 - [net-next,07/11] net/sched: act_ct: set net pointer before publishing flowtable https://git.kernel.org/netdev/net-next/c/d4548625f38b - [net-next,08/11] netfilter: flowtable: check namespace before iterating flows https://git.kernel.org/netdev/net-next/c/c48fdf027a72 - [net-next,09/11] netfilter: nfnetlink: Fix for interrupted hook dumps https://git.kernel.org/netdev/net-next/c/d3950004ba90 - [net-next,10/11] netfilter: ctnetlink: fix inverted IPv6 address match in dump filter https://git.kernel.org/netdev/net-next/c/1ae2d094b020 - [net-next,11/11] netfilter: conntrack: make filtering by zone discoverable https://git.kernel.org/netdev/net-next/c/46da6029bf46 You are awesome, thank you!
Hi, Just a gentle bump to this net-next PR containing Netfilter updates. Let me know if there is anything that needs to be addressed. Thanks. On Mon, Sep 28, 2026 at 01:04:07AM +0200, Pablo Neira Ayuso wrote: > Hi, > > On Sun, Sep 27, 2026 at 10:40:44PM +0000, netdev-bot+sinfo@kernel.org wrote: > > Hi! > > > > This is an automated message. This series looks like a fix, but its > > commit messages seem to be missing some information: > > > > - How the issue was discovered, e.g. hit in production, hit during > > development, syzbot report, manual code inspection, LLM or static > > analysis tool scan. > > > > - Whether the issue was actually triggered, or is only theoretical > > (e.g. found by code inspection). If it was triggered please include > > the symptoms, like the stack trace or error messages. > > > > Please do not repost the series just to address the above. Instead, > > reply to this email with the missing information, so that reviewers > > can take it into account. If the series needs another revision for > > other reasons, please include the information in the commit messages > > then. > > > > The evaluation is done by an LLM so it may be wrong, if you think > > that is the case please reply and explain. > > This are correctness fixes (no crashes to my knowledged, hence I > decided to target net-next) as the cover letter specifies: > > Patch #1 TCP sequence tracking issue was reported by sashiko as the > cover letter says. > > Patch #2 Just documentation update to fix incorrect information > about the maximum number of expectations. > > Patch #3 Just a cleanup patch to remove a break; > > Patch #4 Just a cleanup, typos in comments. > > Patch #5 and #6 are the result of a human triggered review of the > conntrack error stats by Phil Sutter, I think. > > Patch #7 is a preparation patch for #8. > > Patch #8 removes a unnecessary workqueue flush, submitter does not > specify if it is visible in production, I suspect with > a very large number of netns it must be. Author does not > claim LLM assistance. > > Patch #9 is a fix triggered by sashiko report IIRC, I deemed it too > large for net so I am routing this rework-fix to net-next. > > Patch #10 is a feature fix, IPv6 filtering does not work. > I suspect it was found when trying to use this (broken) > feature by the submitter. > > Patch #11 Ilya Maximets reports the CTA_ZONE filtering feature is > not easy to infer from userspace, I don't think LLM > triggered this, it looks more like an improvement to help > userspace tools discover this feature. > > This is human written reply, my cover letter has been generated by me > too to provide more context on these patches. > > Thanks! >
FWOn 10/4/26 9:26 PM, Pablo Neira Ayuso wrote: > Hi, > > Just a gentle bump to this net-next PR containing Netfilter updates. > > Let me know if there is anything that needs to be addressed. AFAICT, this PR was merged to net-next on the 29th: https://git.kernel.org/netdev/net-next/c/0a1a3898ab64fd4f7b90816fc61186d8eb5302a7 The bot was a little confused, but the reply was actually sent: https://lore.kernel.org/all/179064961102.229594.11396134169189168960.git-patchwork-notify@kernel.org/ Best regards, Ilya Maximets. > > Thanks. > > On Mon, Sep 28, 2026 at 01:04:07AM +0200, Pablo Neira Ayuso wrote: >> Hi, >> >> On Sun, Sep 27, 2026 at 10:40:44PM +0000, netdev-bot+sinfo@kernel.org wrote: >>> Hi! >>> >>> This is an automated message. This series looks like a fix, but its >>> commit messages seem to be missing some information: >>> >>> - How the issue was discovered, e.g. hit in production, hit during >>> development, syzbot report, manual code inspection, LLM or static >>> analysis tool scan. >>> >>> - Whether the issue was actually triggered, or is only theoretical >>> (e.g. found by code inspection). If it was triggered please include >>> the symptoms, like the stack trace or error messages. >>> >>> Please do not repost the series just to address the above. Instead, >>> reply to this email with the missing information, so that reviewers >>> can take it into account. If the series needs another revision for >>> other reasons, please include the information in the commit messages >>> then. >>> >>> The evaluation is done by an LLM so it may be wrong, if you think >>> that is the case please reply and explain. >> >> This are correctness fixes (no crashes to my knowledged, hence I >> decided to target net-next) as the cover letter specifies: >> >> Patch #1 TCP sequence tracking issue was reported by sashiko as the >> cover letter says. >> >> Patch #2 Just documentation update to fix incorrect information >> about the maximum number of expectations. >> >> Patch #3 Just a cleanup patch to remove a break; >> >> Patch #4 Just a cleanup, typos in comments. >> >> Patch #5 and #6 are the result of a human triggered review of the >> conntrack error stats by Phil Sutter, I think. >> >> Patch #7 is a preparation patch for #8. >> >> Patch #8 removes a unnecessary workqueue flush, submitter does not >> specify if it is visible in production, I suspect with >> a very large number of netns it must be. Author does not >> claim LLM assistance. >> >> Patch #9 is a fix triggered by sashiko report IIRC, I deemed it too >> large for net so I am routing this rework-fix to net-next. >> >> Patch #10 is a feature fix, IPv6 filtering does not work. >> I suspect it was found when trying to use this (broken) >> feature by the submitter. >> >> Patch #11 Ilya Maximets reports the CTA_ZONE filtering feature is >> not easy to infer from userspace, I don't think LLM >> triggered this, it looks more like an improvement to help >> userspace tools discover this feature. >> >> This is human written reply, my cover letter has been generated by me >> too to provide more context on these patches. >> >> Thanks! >>
On Mon, Oct 05, 2026 at 03:04:18PM +0200, Ilya Maximets wrote: > FWOn 10/4/26 9:26 PM, Pablo Neira Ayuso wrote: > > Hi, > > > > Just a gentle bump to this net-next PR containing Netfilter updates. > > > > Let me know if there is anything that needs to be addressed. > > AFAICT, this PR was merged to net-next on the 29th: > https://git.kernel.org/netdev/net-next/c/0a1a3898ab64fd4f7b90816fc61186d8eb5302a7 > > The bot was a little confused, but the reply was actually sent: > https://lore.kernel.org/all/179064961102.229594.11396134169189168960.git-patchwork-notify@kernel.org/ Indeed, all then, thanks!
diff --git a/include/net/netfilter/nf_conntrack_seqadj.h b/include/net/netfilter/nf_conntrack_seqadj.h index 883c414b768e..0f5bbb14a25a 100644 --- a/include/net/netfilter/nf_conntrack_seqadj.h +++ b/include/net/netfilter/nf_conntrack_seqadj.h @@ -33,6 +33,7 @@ static inline struct nf_conn_seqadj *nfct_seqadj_ext_add(struct nf_conn *ct) int nf_ct_seqadj_init(struct nf_conn *ct, enum ip_conntrack_info ctinfo, s32 off); +void nf_ct_seqadj_reset(struct nf_conn *ct, enum ip_conntrack_info ctinfo); int nf_ct_seqadj_set(struct nf_conn *ct, enum ip_conntrack_info ctinfo, __be32 seq, s32 off); void nf_ct_tcp_seqadj_set(struct sk_buff *skb, struct nf_conn *ct, diff --git a/net/netfilter/nf_conntrack_seqadj.c b/net/netfilter/nf_conntrack_seqadj.c index d75e8dafb189..b7b166a8ad58 100644 --- a/net/netfilter/nf_conntrack_seqadj.c +++ b/net/netfilter/nf_conntrack_seqadj.c @@ -31,6 +31,23 @@ int nf_ct_seqadj_init(struct nf_conn *ct, enum ip_conntrack_info ctinfo, } EXPORT_SYMBOL_GPL(nf_ct_seqadj_init); +void nf_ct_seqadj_reset(struct nf_conn *ct, enum ip_conntrack_info ctinfo) +{ + struct nf_conn_seqadj *seqadj = nfct_seqadj(ct); + enum ip_conntrack_dir dir = CTINFO2DIR(ctinfo); + struct nf_ct_seqadj *this_way; + + if (unlikely(!seqadj)) + return; + + spin_lock_bh(&ct->lock); + this_way = &seqadj->seq[dir]; + this_way->offset_before = 0; + this_way->offset_after = 0; + spin_unlock_bh(&ct->lock); +} +EXPORT_SYMBOL_GPL(nf_ct_seqadj_reset); + int nf_ct_seqadj_set(struct nf_conn *ct, enum ip_conntrack_info ctinfo, __be32 seq, s32 off) { diff --git a/net/netfilter/nf_synproxy_core.c b/net/netfilter/nf_synproxy_core.c index 9fc959ba2030..401ce5a13f3f 100644 --- a/net/netfilter/nf_synproxy_core.c +++ b/net/netfilter/nf_synproxy_core.c @@ -686,7 +686,7 @@ ipv4_synproxy_hook(void *priv, struct sk_buff *skb, * adjustments, they will get initialized once the connection is * reestablished. */ - nf_ct_seqadj_init(ct, ctinfo, 0); + nf_ct_seqadj_reset(ct, ctinfo); synproxy->tsoff = 0; this_cpu_inc(snet->stats->conn_reopened); fallthrough; @@ -1116,7 +1116,7 @@ ipv6_synproxy_hook(void *priv, struct sk_buff *skb, * adjustments, they will get initialized once the connection is * reestablished. */ - nf_ct_seqadj_init(ct, ctinfo, 0); + nf_ct_seqadj_reset(ct, ctinfo); synproxy->tsoff = 0; this_cpu_inc(snet->stats->conn_reopened); fallthrough;