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]
Date:   Thu, 19 Oct 2023 04:44:04 +0000
From:   gus Gusenleitner Klaus <gus@...a.com>
To:     Al Viro <viro@....linux.org.uk>,
        Thomas Gleixner <tglx@...utronix.de>
CC:     lkml <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...hat.com>, "bp@...en8.de" <bp@...en8.de>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        "dsahern@...nel.org" <dsahern@...nel.org>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>
Subject: AW: [PATCH] amd64: Fix csum_partial_copy_generic()

> On Wed, Oct 18, 2023 at 06:18:05AM +0000, gus Gusenleitner Klaus wrote:
> > The checksum calculation is wrong in case of an source buffer
> > containing zero bytes only. The expected return value is 0, the
> > actual return value is 0xfffffff.
> 
> Expected where?  The actual checksum is defined modulo 0xffff, so
> 0 and 0xffffffff represent the same final value.
> 
> The only twist is that in some situations we internally use 0 for
> "not calculated yet".
> 
> > This problem occurs when a ICMP echo reply is sent that has set
> > zero identifier, sequence number and data.
> 
> What problem?  Could you please either point to specific RFC or
> show that packets are rejected by some existing system, or...?

Here's our situation:
Our device gets pinged by a third party manufacturer robot controller.
We have updated the kernel in our device to 5.15 from 4.9, the robot
controller is kept unchanged. At 4.9, our device's ping reply is accepted
by the robot controller, at 5.15 it's not.

Wireshark shows a bad checksum warning:
 'Checksum: 0x0000 incorrect, should be 0xffff' 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ