netdev - Re: [PATCHv2] ipv6: ip6mr: Recalc UDP checksum before forwarding

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20171215.132728.1988249158186497781.davem@davemloft.net>
Date:   Fri, 15 Dec 2017 13:27:28 -0500 (EST)
From:   David Miller <davem@...emloft.net>
To:     redmcg@...mandi.dyndns.org
Cc:     eric.dumazet@...il.com, marcelo.leitner@...il.com,
        kuznet@....inr.ac.ru, yoshfuji@...ux-ipv6.org,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCHv2] ipv6: ip6mr: Recalc UDP checksum before forwarding

From: Brendan McGrath <redmcg@...mandi.dyndns.org>
Date: Thu, 14 Dec 2017 22:37:03 +1100

> Currently, when forwarding a multicast packet originating from a
> Virtual Interface on a Multicast Router to one of its Physical
> Interfaces, ip_summed is set to a value of CHECKSUM_UNNECESSARY and
> the UDP checksum is not calculated.
> 
> The checksum value of the forwarded packet is left as is and
> therefore rejected by the receiving machine(s).
> 
> This patch ensures the checksum is recalculated before forwarding.
> 
> Signed-off-by: Brendan McGrath <redmcg@...mandi.dyndns.org>

I still don't like this, UDP can't be the only protocol that goes
over multicast and might therefore have this problem.

Actually, I'm still also having trouble figuring out how this happens
in the first place.

Please draw a specific detailed network diagram, show the exact
configuration of each interface and exactly what driver runs that
interface, and show where the packet comes from, who creates it, and
where these checksum settings are done that lead to this problem.

Like Eric, I'm very suspicious and I think that there is some problem
with whoever builds or modifies this packet, and the code you are
touching has no business "fixing it up"

Thank you.