lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 11 Oct 2022 11:03:25 +0200
From:   Thorsten Leemhuis <>
        "" <>
Subject: Re: Fw: [Bug 216557] New: tcp connection not working over ip_vti
 interface #forregzbot

[Note: this mail is primarily send for documentation purposes and/or for
regzbot, my Linux kernel regression tracking bot. That's why I removed
most or all folks from the list of recipients, but left any that looked
like a mailing lists. These mails usually contain '#forregzbot' in the
subject, to make them easy to spot and filter out.]

[TLDR: I'm adding this regression report to the list of tracked
regressions; all text from me you find below is based on a few templates
paragraphs you might have encountered already already in similar form.]

Hi, this is your Linux kernel regression tracker.

On 07.10.22 23:17, Stephen Hemminger wrote:

> Begin forwarded message:
> Date: Fri, 07 Oct 2022 20:51:12 +0000
> From:
> To:
> Subject: [Bug 216557] New: tcp connection not working over ip_vti interface
>             Bug ID: 216557
>            Summary: tcp connection not working over ip_vti interface
>            Product: Networking
>            Version: 2.5
>     Kernel Version: 5.15.53
>           Hardware: All
>                 OS: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: high
>           Priority: P1
>          Component: IPV4
>           Assignee:
>           Reporter:
>         Regression: No
> TCP protocol is not working, when ipsec tunnel has been setup and ip_vti tunnel
> is used for route based ipsec.
> After the below changes merged with latest kernel. xfrm4_policy_check in
> tcp_v4_rcv drops all packets except first syn packet under XfrmInTmplMismatch
> when local destined packets are received over ip_vti tunnel.
> author  Eyal Birger <>     2022-05-13 23:34:02 +0300
> committer       Greg Kroah-Hartman <> 2022-05-25
> 09:57:30 +0200
> commit  952c2464963895271c31698970e7ec1ad6f0fe45 (patch)
> tree    9e8300c45a0eb5a9555eae017f8ae561f3e8bc51 /include/net/xfrm.h
> parent  36d8cca5b46fe41b59f8011553495ede3b693703 (diff)
> download        linux-952c2464963895271c31698970e7ec1ad6f0fe45.tar.gz
> xfrm: fix "disable_policy" flag use when arriving from different devices
> setup:
> 1) create road warrior ipsec tunnel with local ip x.x.x.x remote ip y.y.y.y.
> 2) create vti interface using ip tunnel add vti_test local x.x.x.x remote
> y.y.y.y mode vti 
> 3) echo 1 > /proc/sys/net/ipv4/conf/vti_test/disable_policy
> 4) Add default route over vti_test.
> 5) ping remote ip, ping works.
> 6) ssh remote ip, ssh dont work. check tcp connection not working.
> Root cause:
> -> with above mentioned commit, now xfrm4_policy_check depends on skb's  
> IPSKB_NOPOLICY flag which need to be set per skb and it only gets set in
> ip_route_input_noref .
> -> before above change, xfrm4_policy_check was using DST_NOPOLICY which was  
> checked against dst set in skb.
> -> ip_rcv_finish_core calls ip_route_input_noref only if dst is not valid in  
> skb.
> -> By default in kernel sysctl_ip_early_demux = 1, which means when skb with  
> syn is received, tcp stack will set DST from skb to sk and in subsequent
> packets it will copy dst from sk to skb and skip calling ip_route_input_nore
> inside ip_rcv_finish_core.
> -> so for all the subsequent  received packets, IPSKB_NOPOLICY will not get set  
> and they will get drop.
> workaround:
> only work-aroud is to disable early tcp demux.
> echo 0 > /proc/sys/net/ipv4/ip_early_demux

Thanks for the report. To be sure below issue doesn't fall through the
cracks unnoticed, I'm adding it to regzbot, my Linux kernel regression
tracking bot:

#regzbot introduced e6175a2ed1f1 ^
#regzbot title [Bug 216557] New: tcp connection not working over ip_vti
#regzbot monitor:
#regzbot ignore-activity

This isn't a regression? This issue or a fix for it are already
discussed somewhere else? It was fixed already? You want to clarify when
the regression started to happen? Or point out I got the title or
something else totally wrong? Then just reply -- ideally with also
telling regzbot about it, as explained here:

Reminder for developers: When fixing the issue, add 'Link:' tags
pointing to the report (the mail this one replies to), as explained for
in the Linux kernel's documentation; above webpage explains why this is
important for tracked regressions.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)

P.S.: As the Linux kernel's regression tracker I deal with a lot of
reports and sometimes miss something important when writing mails like
this. If that's the case here, don't hesitate to tell me in a public
reply, it's in everyone's interest to set the public record straight.

Powered by blists - more mailing lists