netdev - Re: KCM - recvmsg() mangles packets?

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:   Sat, 4 Aug 2018 04:08:06 +0200
From:   Dominique Martinet <asmadeus@...ewreck.org>
To:     Tom Herbert <tom@...ntonium.net>
Cc:     Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: KCM - recvmsg() mangles packets?

Dominique Martinet wrote on Sat, Aug 04, 2018:
> Actually, now I'm looking closer to the timing, it looks specific to the
> connection setup. This send loop works:
>         int i = 1;
>         while(i <= 1000) {
>                 int len = (i++ * 1312739ULL) % 31 + 1;
>                 my_msg.hdr.len = htonl(len);
>                 for (int j = 0; j < len; ) {
>                         j += snprintf(my_msg.data + j, len - j,
>                                       "%i", i - 1);
>                 }
>                 my_msg.data[len-1] = '\0';
>                 //printf("%d: writing %d\n", i-1, len);
>                 len = write(s, &my_msg, sizeof(my_msg.hdr) + len);
>                 if (error == -1)
>                         err(EXIT_FAILURE, "write");
>                 if (i == 2)
>                         usleep(1);
>         }
> 
> But removing the usleep(1) after the first packet makes recvmsg()
> "fail": it reads the content of the second packet with the size of the
> first.

I talked too fast, I can get this to fail on later packets e.g.
Got 18, expected 31 on 452nd message: 453453453453453453; flags: 80

The content is 453 in a loop so this really is the 453rd packet...

But being slower e.g. doing that usleep after every single packets and I
could let the loop run until 100k without a hintch.

There really has to be something wrong, I just can't tell what from
looking at the code with my naive eyes.
Maybe we need to lock both the tcp and the kcm sockets?

Thanks,
-- 
Dominique