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]

Message-ID: <20180805141253.GA22780@nautica>
Date:   Sun, 5 Aug 2018 16:12:53 +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 Sun, Aug 05, 2018:
> (I'm not sure about offset, since we pass the full skb to parse message,
> wouldn't it look at the start of the buffer everytime? Well, offset
> seems to be 0 everytime the first time that check fails so I can
> probably ignore that for now...)

Oh, this might actually not have been such a bad remark; if I have the
client write two "messages" in a single write() kcm seems to reliably
fail the same way...

Conversely, if I setsockopt(s, IPPROTO_TCP, TCP_NODELAY...) on the
sender socket, *and* make it wait till the kcm socket has been created
to start sending data, then it dramatically reduces the probability of
this happening (I had to let the reproducer run in a loop for 5 minutes,
wheras it used to happen within seconds).

So I think the problem is packet aggregation, and strparser not handling
that properly... The first packet still fails with TCP_NODELAY but
there's probably aggregation on the recv side as well before the socket
is attached to the multiplexor... I guess the low probability failure
that is still happening could be similar.
(I also noticed that I've mistakedly believed that the problem was the
first packet contained the 2nd packet's data because of an off-by-one in
the receiver, it really is the second packet, it only has the first
packet's length)

I've moved my check from kcm_rcv_strparser to just before parse_msg in
__strp_recv and surely enough it fails everytime there's an offset.

It's getting late but I'll try adding a pskb_pull in there tomorrow, it
would be better to make the bpf program start with an offset but I don't
think that'll be easy to change...

I'm almost done spamming, thanks for being a good rubber duck! :p
-- 
Dominique Martinet