lists.openwall.net | 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
| ||
|
Date: Tue, 11 Oct 2022 11:03:25 +0200 From: Thorsten Leemhuis <regressions@...mhuis.info> To: netdev@...r.kernel.org, "regressions@...ts.linux.dev" <regressions@...ts.linux.dev> 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: bugzilla-daemon@...nel.org > To: stephen@...workplumber.org > Subject: [Bug 216557] New: tcp connection not working over ip_vti interface > > > https://bugzilla.kernel.org/show_bug.cgi?id=216557 > > 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: stephen@...workplumber.org > Reporter: monil191989@...il.com > 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 <eyal.birger@...il.com> 2022-05-13 23:34:02 +0300 > committer Greg Kroah-Hartman <gregkh@...uxfoundation.org> 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 ^ https://bugzilla.kernel.org/show_bug.cgi?id=216557 #regzbot title [Bug 216557] New: tcp connection not working over ip_vti interface #regzbot monitor: https://lore.kernel.org/all/20221009191643.297623-1-eyal.birger@gmail.com/ #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: https://linux-regtracking.leemhuis.info/tracked-regression/ 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