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  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 21 Aug 2018 07:53:21 -0700
From:   Doron Roberts-Kedes <doronrk@...com>
To:     Dominique Martinet <asmadeus@...ewreck.org>
CC:     Tom Herbert <tom@...ntonium.net>, Dave Watson <davejwatson@...com>,
        "David S. Miller" <davem@...emloft.net>, <netdev@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] strparser: remove any offset before parsing messages

On Tue, Aug 21, 2018 at 02:51:46PM +0200, Dominique Martinet wrote:
> Offset is not well handled by strparser users right now.
> 
> Out of the current strparser users, we have:
>  - tls, that handles offset properly in parse and rcv callbacks
>  - kcm, that handles offset in rcv but not in parse
>  - bpf sockmap, that does not seem to handle offset anywhere
> 
> Calling pskb_pull() on new skb ensures that the offset will be 0
> everywhere in practice, and in particular for the parse function,
> unless the user modifies it themselves like tls does.
> 
> This fixes a bug which can be exhibited by implementing a simple kcm
> parser that looks for the packet size in the first word of the packet,
> and sending two such packets in a single write() call on the other side:
> the second message will be cut at the length of the first message.
> Since this is a stream protocol, all the following messages will also
> be corrupt since it will start looking for the next offset at a wrong
> position.
> 
> Signed-off-by: Dominique Martinet <asmadeus@...ewreck.org>
> ---

There are a few issues with this patch. First, it seems like you're
trying to fix bugs in users of strparser by changing an implementation
detail of strparser. Second, this implementation change can add malloc's
and copies where there were none before. 

If strparser users do not handle non-zero offset properly, then that
doesn't motivate changing the implementation of strparser to copy
around data to accomodate those buggy users. 

Why not submit a patch that handles offset properly in the code you
pointed out? 

Powered by blists - more mailing lists