netdev - Re: bug: tpacket_snd can cause data corruption

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: <CAF=yD-J-17g_riv367tCC7Go_iuqW4wqE=ye+=kKCxJ=oEXaiA@mail.gmail.com>
Date:   Thu, 4 Jul 2019 18:59:44 -0400
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Frank de Brabander <debrabander@...il.com>
Cc:     "David S . Miller" <davem@...emloft.net>,
        Willem de Bruijn <willemb@...gle.com>,
        Network Development <netdev@...r.kernel.org>
Subject: Re: bug: tpacket_snd can cause data corruption

> > Can you reproduce the issue when running the modified test in a
> > network namespace (./in_netns.sh ./txring_overwrite)?

> But even when running the test with ./in_netns.sh it shows
> "wrong pattern", this time without length mismatches:
>
> wrong pattern: 0x62 != 0x61
> wrong pattern: 0x62 != 0x61
> wrong pattern: 0x62 != 0x61
> wrong pattern: 0x62 != 0x61
> wrong pattern: 0x62 != 0x61
> wrong pattern: 0x62 != 0x61
> wrong pattern: 0x62 != 0x61
> wrong pattern: 0x62 != 0x61
> wrong pattern: 0x62 != 0x61
> wrong pattern: 0x62 != 0x61
>
> As already mentioned, it seems to trigger mainly (only ?) when
> an USB device is connected. The PC I'm testing this on has an
> USB hub with many ports and connected devices. When connecting
> this USB hub, the amount of "wrong pattern" errors that are
> shown seems to correlate to the amount of new devices
> that the kernel should detect. Connecting in a single USB device
> also triggers the error, but not on every attempt.
>
> Unfortunately have not found any other way to force the
> error to trigger. E.g. running stress-ng to generate CPU load or
> timer interrupts does not seem to have any impact.

Interesting, thanks for testing. No exact idea so far. The USB devices
are not necessarily network devices, I suppose? I don't immediately
have a setup to test the usb hotplug, so cannot yet reproduce the bug.