linux-kernel - Re: [PATCH] lib/checksum.c: fix carry in csum_tcpudp

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20150127220332.GZ29656@ZenIV.linux.org.uk>
Date:	Tue, 27 Jan 2015 22:03:32 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Karl Beldan <karl.beldan@...il.com>
Cc:	Karl Beldan <karl.beldan@...ierawaves.com>,
	Mike Frysinger <vapier@...too.org>,
	Arnd Bergmann <arnd@...db.de>, linux-kernel@...r.kernel.org,
	Stable <stable@...r.kernel.org>
Subject: Re: [PATCH] lib/checksum.c: fix carry in csum_tcpudp_nofold

On Tue, Jan 27, 2015 at 04:25:16PM +0100, Karl Beldan wrote:
> The carry from the 64->32bits folding was dropped, e.g with:
> saddr=0xFFFFFFFF daddr=0xFF0000FF len=0xFFFF proto=0 sum=1
> 
> Signed-off-by: Karl Beldan <karl.beldan@...ierawaves.com>
> Cc: Mike Frysinger <vapier@...too.org>
> Cc: Arnd Bergmann <arnd@...db.de>
> Cc: linux-kernel@...r.kernel.org
> Cc: Stable <stable@...r.kernel.org>
> ---
>  lib/checksum.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/checksum.c b/lib/checksum.c
> index 129775e..4b5adf2 100644
> --- a/lib/checksum.c
> +++ b/lib/checksum.c
> @@ -195,8 +195,8 @@ __wsum csum_tcpudp_nofold(__be32 saddr, __be32 daddr,
>  #else
>  	s += (proto + len) << 8;
>  #endif
> -	s += (s >> 32);
> -	return (__force __wsum)s;
> +	s += (s << 32) + (s >> 32);
> +	return (__force __wsum)(s >> 32);

Umm...  I _think_ it's correct, but it needs a better commit message.  AFAICS,
what we have is that s is guaranteed to be (a << 32) + b, with a being small.
What we want is something congruent to a + b modulo 0xffff.  And yes, in case
when a + b >= 2^32, the original variant fails - it yields a + b - 2^32, which
is one less than what's needed.  New one results first in
(a + b)(2^32+1)mod 2^64, then that divided by 2^32.  If a + b <= 2^32 - 1,
the first product is less than 2^64 and dividing it by 2^32 yields a + b.
If a + b = 2^32 + c, c is guaranteed to be small and we first get
2^32 * c + 2^32 + 1, then c + 1, i.e. a + b - 0xffffffff, i.e.
a + b - 0x10001 * 0xffff, so the congruence holds in all cases.

IOW, I think the fix is correct, but it really needs analysis in the commit
message.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/