* [PATCH] net/sched: act_pedit: require matching IPv4 L4 protocol @ 2026-06-05 19:46 Samuel Moelius 2026-06-06 21:29 ` Jamal Hadi Salim 0 siblings, 1 reply; 7+ messages in thread From: Samuel Moelius @ 2026-06-05 19:46 UTC (permalink / raw) To: Jamal Hadi Salim Cc: Samuel Moelius, Jiri Pirko, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman, open list:TC subsystem, open list The extended IPv4 L4 header mode in act_pedit can select TCP or UDP header fields without confirming that the IPv4 protocol field matches the selected transport header. That lets a rule written for TCP or UDP modify unrelated payload bytes in a packet carrying a different protocol. Verify the IPv4 protocol before applying TCP or UDP extended header edits. Assisted-by: Codex:gpt-5.5-cyber-preview Signed-off-by: Samuel Moelius <sam.moelius@trailofbits.com> --- net/sched/act_pedit.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/sched/act_pedit.c b/net/sched/act_pedit.c index bc20f08a2789..9a4590451f7e 100644 --- a/net/sched/act_pedit.c +++ b/net/sched/act_pedit.c @@ -341,6 +341,8 @@ static int pedit_l4_skb_offset(struct sk_buff *skb, int *hoffset, const int head if (!iph) goto out; + if (iph->ihl < 5 || iph->protocol != header_type) + goto out; *hoffset = noff + iph->ihl * 4; ret = 0; break; -- 2.43.0 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] net/sched: act_pedit: require matching IPv4 L4 protocol 2026-06-05 19:46 [PATCH] net/sched: act_pedit: require matching IPv4 L4 protocol Samuel Moelius @ 2026-06-06 21:29 ` Jamal Hadi Salim 2026-06-07 14:33 ` Samuel Moelius 0 siblings, 1 reply; 7+ messages in thread From: Jamal Hadi Salim @ 2026-06-06 21:29 UTC (permalink / raw) To: Samuel Moelius Cc: Jiri Pirko, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman, open list:TC subsystem, open list On Fri, Jun 5, 2026 at 3:46 PM Samuel Moelius <sam.moelius@trailofbits.com> wrote: > > The extended IPv4 L4 header mode in act_pedit can select TCP or UDP > header fields without confirming that the IPv4 protocol field matches > the selected transport header. > > That lets a rule written for TCP or UDP modify unrelated payload bytes > in a packet carrying a different protocol. > > Verify the IPv4 protocol before applying TCP or UDP extended header > edits. > > Assisted-by: Codex:gpt-5.5-cyber-preview > Signed-off-by: Samuel Moelius <sam.moelius@trailofbits.com> > --- > net/sched/act_pedit.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/net/sched/act_pedit.c b/net/sched/act_pedit.c > index bc20f08a2789..9a4590451f7e 100644 > --- a/net/sched/act_pedit.c > +++ b/net/sched/act_pedit.c > @@ -341,6 +341,8 @@ static int pedit_l4_skb_offset(struct sk_buff *skb, int *hoffset, const int head > > if (!iph) > goto out; > + if (iph->ihl < 5 || iph->protocol != header_type) > + goto out; From inspection the fix looks reasonable. At first glance it seems that the only fix that resolves the issue you are describing is to check the protocol header. header length seems to be an extra thing. But let's do what the v6 side seems to and skip frags as well? Something maybe along the lines of: if (iph->ihl < 5 || iph->protocol != header_type || (iph->frag_off & htons(IP_OFFSET))) goto out; Are you able to describe how someone would configure a tc rule that will allow this to happen? IOW, how did you verify the problem and then validate that your fix works? cheers, jamal > *hoffset = noff + iph->ihl * 4; > ret = 0; > break; > -- > 2.43.0 > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] net/sched: act_pedit: require matching IPv4 L4 protocol 2026-06-06 21:29 ` Jamal Hadi Salim @ 2026-06-07 14:33 ` Samuel Moelius 2026-06-08 10:46 ` Jamal Hadi Salim 0 siblings, 1 reply; 7+ messages in thread From: Samuel Moelius @ 2026-06-07 14:33 UTC (permalink / raw) To: Jamal Hadi Salim Cc: Jiri Pirko, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman, open list:TC subsystem, open list On Sat, Jun 6, 2026 at 5:29 PM Jamal Hadi Salim <jhs@mojatatu.com> wrote: > > On Fri, Jun 5, 2026 at 3:46 PM Samuel Moelius > <sam.moelius@trailofbits.com> wrote: > > > > The extended IPv4 L4 header mode in act_pedit can select TCP or UDP > > header fields without confirming that the IPv4 protocol field matches > > the selected transport header. > > > > That lets a rule written for TCP or UDP modify unrelated payload bytes > > in a packet carrying a different protocol. > > > > Verify the IPv4 protocol before applying TCP or UDP extended header > > edits. > > > > Assisted-by: Codex:gpt-5.5-cyber-preview > > Signed-off-by: Samuel Moelius <sam.moelius@trailofbits.com> > > --- > > net/sched/act_pedit.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/net/sched/act_pedit.c b/net/sched/act_pedit.c > > index bc20f08a2789..9a4590451f7e 100644 > > --- a/net/sched/act_pedit.c > > +++ b/net/sched/act_pedit.c > > @@ -341,6 +341,8 @@ static int pedit_l4_skb_offset(struct sk_buff *skb, int *hoffset, const int head > > > > if (!iph) > > goto out; > > + if (iph->ihl < 5 || iph->protocol != header_type) > > + goto out; > > From inspection the fix looks reasonable. > At first glance it seems that the only fix that resolves the issue you > are describing is to check the protocol header. > header length seems to be an extra thing. But let's do what the v6 > side seems to and skip frags as well? Something maybe along the lines > of: > > if (iph->ihl < 5 || iph->protocol != header_type || (iph->frag_off & > htons(IP_OFFSET))) > goto out; I will submit an updated patch. > Are you able to describe how someone would configure a tc rule that > will allow this to happen? > IOW, how did you verify the problem and then validate that your fix works? The bug was validated using a custom init script in QEMU. The specific line used was: /usr/sbin/tc filter add dev veth0 egress protocol ip pref 1 matchall action pedit ex munge udp dport set 18053 An IPv4 TCP packet with destination port 2222 was sent through that path. With the unpatched kernel, the packet was received with TCP destination port 18053. With the patched kernel, the same packet was received unchanged. I can provide more details or artifacts if you would like. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] net/sched: act_pedit: require matching IPv4 L4 protocol 2026-06-07 14:33 ` Samuel Moelius @ 2026-06-08 10:46 ` Jamal Hadi Salim 2026-06-08 14:40 ` Victor Nogueira 0 siblings, 1 reply; 7+ messages in thread From: Jamal Hadi Salim @ 2026-06-08 10:46 UTC (permalink / raw) To: Samuel Moelius Cc: Jiri Pirko, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman, open list:TC subsystem, open list, Victor Nogueira On Sun, Jun 7, 2026 at 10:33 AM Samuel Moelius <sam.moelius@trailofbits.com> wrote: > > On Sat, Jun 6, 2026 at 5:29 PM Jamal Hadi Salim <jhs@mojatatu.com> wrote: > > > > On Fri, Jun 5, 2026 at 3:46 PM Samuel Moelius > > <sam.moelius@trailofbits.com> wrote: > > > > > > The extended IPv4 L4 header mode in act_pedit can select TCP or UDP > > > header fields without confirming that the IPv4 protocol field matches > > > the selected transport header. > > > > > > That lets a rule written for TCP or UDP modify unrelated payload bytes > > > in a packet carrying a different protocol. > > > > > > Verify the IPv4 protocol before applying TCP or UDP extended header > > > edits. > > > > > > Assisted-by: Codex:gpt-5.5-cyber-preview > > > Signed-off-by: Samuel Moelius <sam.moelius@trailofbits.com> > > > --- > > > net/sched/act_pedit.c | 2 ++ > > > 1 file changed, 2 insertions(+) > > > > > > diff --git a/net/sched/act_pedit.c b/net/sched/act_pedit.c > > > index bc20f08a2789..9a4590451f7e 100644 > > > --- a/net/sched/act_pedit.c > > > +++ b/net/sched/act_pedit.c > > > @@ -341,6 +341,8 @@ static int pedit_l4_skb_offset(struct sk_buff *skb, int *hoffset, const int head > > > > > > if (!iph) > > > goto out; > > > + if (iph->ihl < 5 || iph->protocol != header_type) > > > + goto out; > > > > From inspection the fix looks reasonable. > > At first glance it seems that the only fix that resolves the issue you > > are describing is to check the protocol header. > > header length seems to be an extra thing. But let's do what the v6 > > side seems to and skip frags as well? Something maybe along the lines > > of: > > > > if (iph->ihl < 5 || iph->protocol != header_type || (iph->frag_off & > > htons(IP_OFFSET))) > > goto out; > > I will submit an updated patch. > > > Are you able to describe how someone would configure a tc rule that > > will allow this to happen? > > IOW, how did you verify the problem and then validate that your fix works? > > The bug was validated using a custom init script in QEMU. The specific > line used was: > > /usr/sbin/tc filter add dev veth0 egress protocol ip pref 1 matchall > action pedit ex munge udp dport set 18053 > > An IPv4 TCP packet with destination port 2222 was sent through that > path. With the unpatched kernel, the packet was received with TCP > destination port 18053. With the patched kernel, the same packet was > received unchanged. > > I can provide more details or artifacts if you would like. A tdc test case is better. Victor or I can create one for you if you dont know how. cheers, jamal ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] net/sched: act_pedit: require matching IPv4 L4 protocol 2026-06-08 10:46 ` Jamal Hadi Salim @ 2026-06-08 14:40 ` Victor Nogueira 2026-06-09 13:57 ` Samuel Moelius 0 siblings, 1 reply; 7+ messages in thread From: Victor Nogueira @ 2026-06-08 14:40 UTC (permalink / raw) To: Jamal Hadi Salim Cc: Samuel Moelius, Jiri Pirko, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman, open list:TC subsystem, open list [-- Attachment #1: Type: text/plain, Size: 3210 bytes --] On Mon, Jun 8, 2026 at 7:46 AM Jamal Hadi Salim <jhs@mojatatu.com> wrote: > > On Sun, Jun 7, 2026 at 10:33 AM Samuel Moelius > <sam.moelius@trailofbits.com> wrote: > > > > On Sat, Jun 6, 2026 at 5:29 PM Jamal Hadi Salim <jhs@mojatatu.com> wrote: > > > > > > On Fri, Jun 5, 2026 at 3:46 PM Samuel Moelius > > > <sam.moelius@trailofbits.com> wrote: > > > > > > > > The extended IPv4 L4 header mode in act_pedit can select TCP or UDP > > > > header fields without confirming that the IPv4 protocol field matches > > > > the selected transport header. > > > > > > > > That lets a rule written for TCP or UDP modify unrelated payload bytes > > > > in a packet carrying a different protocol. > > > > > > > > Verify the IPv4 protocol before applying TCP or UDP extended header > > > > edits. > > > > > > > > Assisted-by: Codex:gpt-5.5-cyber-preview > > > > Signed-off-by: Samuel Moelius <sam.moelius@trailofbits.com> > > > > --- > > > > net/sched/act_pedit.c | 2 ++ > > > > 1 file changed, 2 insertions(+) > > > > > > > > diff --git a/net/sched/act_pedit.c b/net/sched/act_pedit.c > > > > index bc20f08a2789..9a4590451f7e 100644 > > > > --- a/net/sched/act_pedit.c > > > > +++ b/net/sched/act_pedit.c > > > > @@ -341,6 +341,8 @@ static int pedit_l4_skb_offset(struct sk_buff *skb, int *hoffset, const int head > > > > > > > > if (!iph) > > > > goto out; > > > > + if (iph->ihl < 5 || iph->protocol != header_type) > > > > + goto out; > > > > > > From inspection the fix looks reasonable. > > > At first glance it seems that the only fix that resolves the issue you > > > are describing is to check the protocol header. > > > header length seems to be an extra thing. But let's do what the v6 > > > side seems to and skip frags as well? Something maybe along the lines > > > of: > > > > > > if (iph->ihl < 5 || iph->protocol != header_type || (iph->frag_off & > > > htons(IP_OFFSET))) > > > goto out; > > > > I will submit an updated patch. > > > > > Are you able to describe how someone would configure a tc rule that > > > will allow this to happen? > > > IOW, how did you verify the problem and then validate that your fix works? > > > > The bug was validated using a custom init script in QEMU. The specific > > line used was: > > > > /usr/sbin/tc filter add dev veth0 egress protocol ip pref 1 matchall > > action pedit ex munge udp dport set 18053 > > > > An IPv4 TCP packet with destination port 2222 was sent through that > > path. With the unpatched kernel, the packet was received with TCP > > destination port 18053. With the patched kernel, the same packet was > > received unchanged. > > > > I can provide more details or artifacts if you would like. > > A tdc test case is better. Victor or I can create one for you if you > dont know how. It seems like v2 isn't applying so you'll have to send a new version. When you do, after waiting for the 24h period, can you resend with the attached patch (containing the tdc test)? Since this is a fix, in the new version, remember to target net and add a proper fixes tag. cheers, Victor [-- Attachment #2: 0001-selftests-tc-testing-Verify-pedit-does-not-mangle-mi.patch --] [-- Type: text/x-patch, Size: 3031 bytes --] From 9fc039564addac0312ceb9c9210cb93ea44e8a9f Mon Sep 17 00:00:00 2001 From: Victor Nogueira <victor@mojatatu.com> Date: Mon, 8 Jun 2026 11:10:05 -0300 Subject: [PATCH net v3] selftests/tc-testing: Verify pedit does not mangle mismatched L4 protocol Add a tdc test that checks the act_pedit extended L4 header mode does not edit a packet whose IPv4 protocol does not match the selected transport header. The test installs an ingress pedit rule that sets the UDP destination port, then injects a TCP packet with dport 2222. The UDP and TCP destination ports sit at the same L4 offset, so a buggy kernel rewrites the TCP dport. A second flower filter matches TCP dport 2222 and drops the packet through an indexed gact action; the test then verifies via JSON that this action saw exactly one packet, i.e. the dport was left untouched and still matched 2222. Signed-off-by: Victor Nogueira <victor@mojatatu.com> --- .../tc-testing/tc-tests/actions/pedit.json | 49 +++++++++++++++++++ 1 file changed, 49 insertions(+) diff --git a/tools/testing/selftests/tc-testing/tc-tests/actions/pedit.json b/tools/testing/selftests/tc-testing/tc-tests/actions/pedit.json index 37c4103321749..d8b685cfc62de 100644 --- a/tools/testing/selftests/tc-testing/tc-tests/actions/pedit.json +++ b/tools/testing/selftests/tc-testing/tc-tests/actions/pedit.json @@ -1920,5 +1920,54 @@ "teardown": [ "$TC actions flush action pedit" ] + }, + { + "id": "1a4f", + "name": "Pedit udp dport should not mangle TCP packet dport", + "category": [ + "actions", + "pedit" + ], + "plugins": { + "requires": [ + "nsPlugin", + "scapyPlugin" + ] + }, + "setup": [ + "$TC qdisc add dev $DEV1 clsact", + "$TC filter add dev $DEV1 ingress protocol ip pref 1 matchall action pedit ex munge udp dport set 18053 continue" + ], + "cmdUnderTest": "$TC filter add dev $DEV1 ingress protocol ip pref 2 flower ip_proto tcp dst_port 2222 action drop index 1", + "scapy": { + "iface": "$DEV0", + "count": 1, + "packet": "Ether()/IP(dst='10.10.10.1')/TCP(dport=2222)" + }, + "expExitCode": "0", + "verifyCmd": "$TC -j -s actions get action gact index 1", + "matchJSON": [ + { + "total acts": 0 + }, + { + "actions": [ + { + "order": 1, + "kind": "gact", + "control_action": { + "type": "drop" + }, + "index": 1, + "stats": { + "packets": 1 + } + } + ] + } + ], + "teardown": [ + "$TC qdisc del dev $DEV1 clsact" + ] } ] -- 2.54.0 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] net/sched: act_pedit: require matching IPv4 L4 protocol 2026-06-08 14:40 ` Victor Nogueira @ 2026-06-09 13:57 ` Samuel Moelius 2026-06-09 14:14 ` Victor Nogueira 0 siblings, 1 reply; 7+ messages in thread From: Samuel Moelius @ 2026-06-09 13:57 UTC (permalink / raw) To: Victor Nogueira Cc: Jamal Hadi Salim, Jiri Pirko, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman, open list:TC subsystem, open list On Mon, Jun 8, 2026 at 10:41 AM Victor Nogueira <victor@mojatatu.com> wrote: > > On Mon, Jun 8, 2026 at 7:46 AM Jamal Hadi Salim <jhs@mojatatu.com> wrote: > > > > On Sun, Jun 7, 2026 at 10:33 AM Samuel Moelius > > <sam.moelius@trailofbits.com> wrote: > > > > > > On Sat, Jun 6, 2026 at 5:29 PM Jamal Hadi Salim <jhs@mojatatu.com> wrote: > > > > > > > > On Fri, Jun 5, 2026 at 3:46 PM Samuel Moelius > > > > <sam.moelius@trailofbits.com> wrote: > > > > > > > > > > The extended IPv4 L4 header mode in act_pedit can select TCP or UDP > > > > > header fields without confirming that the IPv4 protocol field matches > > > > > the selected transport header. > > > > > > > > > > That lets a rule written for TCP or UDP modify unrelated payload bytes > > > > > in a packet carrying a different protocol. > > > > > > > > > > Verify the IPv4 protocol before applying TCP or UDP extended header > > > > > edits. > > > > > > > > > > Assisted-by: Codex:gpt-5.5-cyber-preview > > > > > Signed-off-by: Samuel Moelius <sam.moelius@trailofbits.com> > > > > > --- > > > > > net/sched/act_pedit.c | 2 ++ > > > > > 1 file changed, 2 insertions(+) > > > > > > > > > > diff --git a/net/sched/act_pedit.c b/net/sched/act_pedit.c > > > > > index bc20f08a2789..9a4590451f7e 100644 > > > > > --- a/net/sched/act_pedit.c > > > > > +++ b/net/sched/act_pedit.c > > > > > @@ -341,6 +341,8 @@ static int pedit_l4_skb_offset(struct sk_buff *skb, int *hoffset, const int head > > > > > > > > > > if (!iph) > > > > > goto out; > > > > > + if (iph->ihl < 5 || iph->protocol != header_type) > > > > > + goto out; > > > > > > > > From inspection the fix looks reasonable. > > > > At first glance it seems that the only fix that resolves the issue you > > > > are describing is to check the protocol header. > > > > header length seems to be an extra thing. But let's do what the v6 > > > > side seems to and skip frags as well? Something maybe along the lines > > > > of: > > > > > > > > if (iph->ihl < 5 || iph->protocol != header_type || (iph->frag_off & > > > > htons(IP_OFFSET))) > > > > goto out; > > > > > > I will submit an updated patch. > > > > > > > Are you able to describe how someone would configure a tc rule that > > > > will allow this to happen? > > > > IOW, how did you verify the problem and then validate that your fix works? > > > > > > The bug was validated using a custom init script in QEMU. The specific > > > line used was: > > > > > > /usr/sbin/tc filter add dev veth0 egress protocol ip pref 1 matchall > > > action pedit ex munge udp dport set 18053 > > > > > > An IPv4 TCP packet with destination port 2222 was sent through that > > > path. With the unpatched kernel, the packet was received with TCP > > > destination port 18053. With the patched kernel, the same packet was > > > received unchanged. > > > > > > I can provide more details or artifacts if you would like. > > > > A tdc test case is better. Victor or I can create one for you if you > > dont know how. > > It seems like v2 isn't applying so you'll have to send a new version. > When you do, after waiting for the 24h period, can you resend with > the attached patch (containing the tdc test)? Since this is a > fix, in the new version, remember to target net and add a proper fixes > tag. I'm sorry, I'm not quite following. I should send a multipart patch with the patch you shared as one of the parts? ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] net/sched: act_pedit: require matching IPv4 L4 protocol 2026-06-09 13:57 ` Samuel Moelius @ 2026-06-09 14:14 ` Victor Nogueira 0 siblings, 0 replies; 7+ messages in thread From: Victor Nogueira @ 2026-06-09 14:14 UTC (permalink / raw) To: Samuel Moelius Cc: Jamal Hadi Salim, Jiri Pirko, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman, open list:TC subsystem, open list On Tue, Jun 9, 2026 at 10:57 AM Samuel Moelius <sam.moelius@trailofbits.com> wrote: > > On Mon, Jun 8, 2026 at 10:41 AM Victor Nogueira <victor@mojatatu.com> wrote: > > > > On Mon, Jun 8, 2026 at 7:46 AM Jamal Hadi Salim <jhs@mojatatu.com> wrote: > > > > > > On Sun, Jun 7, 2026 at 10:33 AM Samuel Moelius > > > <sam.moelius@trailofbits.com> wrote: > > > > > > > > On Sat, Jun 6, 2026 at 5:29 PM Jamal Hadi Salim <jhs@mojatatu.com> wrote: > > > > > > > > > > On Fri, Jun 5, 2026 at 3:46 PM Samuel Moelius > > > > > <sam.moelius@trailofbits.com> wrote: > > > > > > > > > > > > The extended IPv4 L4 header mode in act_pedit can select TCP or UDP > > > > > > header fields without confirming that the IPv4 protocol field matches > > > > > > the selected transport header. > > > > > > > > > > > > That lets a rule written for TCP or UDP modify unrelated payload bytes > > > > > > in a packet carrying a different protocol. > > > > > > > > > > > > Verify the IPv4 protocol before applying TCP or UDP extended header > > > > > > edits. > > > > > > > > > > > > Assisted-by: Codex:gpt-5.5-cyber-preview > > > > > > Signed-off-by: Samuel Moelius <sam.moelius@trailofbits.com> > > > > > > --- > > > > > > net/sched/act_pedit.c | 2 ++ > > > > > > 1 file changed, 2 insertions(+) > > > > > > > > > > > > diff --git a/net/sched/act_pedit.c b/net/sched/act_pedit.c > > > > > > index bc20f08a2789..9a4590451f7e 100644 > > > > > > --- a/net/sched/act_pedit.c > > > > > > +++ b/net/sched/act_pedit.c > > > > > > @@ -341,6 +341,8 @@ static int pedit_l4_skb_offset(struct sk_buff *skb, int *hoffset, const int head > > > > > > > > > > > > if (!iph) > > > > > > goto out; > > > > > > + if (iph->ihl < 5 || iph->protocol != header_type) > > > > > > + goto out; > > > > > > > > > > From inspection the fix looks reasonable. > > > > > At first glance it seems that the only fix that resolves the issue you > > > > > are describing is to check the protocol header. > > > > > header length seems to be an extra thing. But let's do what the v6 > > > > > side seems to and skip frags as well? Something maybe along the lines > > > > > of: > > > > > > > > > > if (iph->ihl < 5 || iph->protocol != header_type || (iph->frag_off & > > > > > htons(IP_OFFSET))) > > > > > goto out; > > > > > > > > I will submit an updated patch. > > > > > > > > > Are you able to describe how someone would configure a tc rule that > > > > > will allow this to happen? > > > > > IOW, how did you verify the problem and then validate that your fix works? > > > > > > > > The bug was validated using a custom init script in QEMU. The specific > > > > line used was: > > > > > > > > /usr/sbin/tc filter add dev veth0 egress protocol ip pref 1 matchall > > > > action pedit ex munge udp dport set 18053 > > > > > > > > An IPv4 TCP packet with destination port 2222 was sent through that > > > > path. With the unpatched kernel, the packet was received with TCP > > > > destination port 18053. With the patched kernel, the same packet was > > > > received unchanged. > > > > > > > > I can provide more details or artifacts if you would like. > > > > > > A tdc test case is better. Victor or I can create one for you if you > > > dont know how. > > > > It seems like v2 isn't applying so you'll have to send a new version. > > When you do, after waiting for the 24h period, can you resend with > > the attached patch (containing the tdc test)? Since this is a > > fix, in the new version, remember to target net and add a proper fixes > > tag. > > I'm sorry, I'm not quite following. > > I should send a multipart patch with the patch you shared as one of the parts? Yes, please send a patchset with patch 1 being your fix and patch 2 the tdc test. cheers, Victor ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2026-06-09 14:14 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2026-06-05 19:46 [PATCH] net/sched: act_pedit: require matching IPv4 L4 protocol Samuel Moelius 2026-06-06 21:29 ` Jamal Hadi Salim 2026-06-07 14:33 ` Samuel Moelius 2026-06-08 10:46 ` Jamal Hadi Salim 2026-06-08 14:40 ` Victor Nogueira 2026-06-09 13:57 ` Samuel Moelius 2026-06-09 14:14 ` Victor Nogueira
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®