netdev - Re: [PATCH 6/6] xfrm: add espintcp (RFC 8229)

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] [day] [month] [year] [list]

Message-ID: <20200824085318.GQ20687@gauss3.secunet.de>
Date:   Mon, 24 Aug 2020 10:53:18 +0200
From:   Steffen Klassert <steffen.klassert@...unet.com>
To:     Eric Dumazet <eric.dumazet@...il.com>
CC:     David Miller <davem@...emloft.net>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        <netdev@...r.kernel.org>, Sabrina Dubroca <sd@...asysnail.net>
Subject: Re: [PATCH 6/6] xfrm: add espintcp (RFC 8229)

Ccing Sabrina.

On Fri, Aug 21, 2020 at 02:46:44PM -0700, Eric Dumazet wrote:
> 
> 
> On 1/20/20 11:38 PM, Steffen Klassert wrote:
> > From: Sabrina Dubroca <sd@...asysnail.net>
> > 
> > TCP encapsulation of IKE and IPsec messages (RFC 8229) is implemented
> > as a TCP ULP, overriding in particular the sendmsg and recvmsg
> > operations. A Stream Parser is used to extract messages out of the TCP
> > stream using the first 2 bytes as length marker. Received IKE messages
> > are put on "ike_queue", waiting to be dequeued by the custom recvmsg
> > implementation. Received ESP messages are sent to XFRM, like with UDP
> > encapsulation
> 
> ...
> 
> > +
> > +static int espintcp_sendskb_locked(struct sock *sk, struct espintcp_msg *emsg,
> > +				   int flags)
> > +{
> > +	do {
> > +		int ret;
> > +
> > +		ret = skb_send_sock_locked(sk, emsg->skb,
> > +					   emsg->offset, emsg->len);
> > +		if (ret < 0)
> > +			return ret;
> > +
> > +		emsg->len -= ret;
> > +		emsg->offset += ret;
> > +	} while (emsg->len > 0);
> > +
> > +	kfree_skb(emsg->skb);
> > +	memset(emsg, 0, sizeof(*emsg));
> > +
> > +	return 0;
> > +}
> 
> 
> Is there any particular reason we use kfree_skb() here instead of consume_skb() ?

I guess not. The skb in not dropped due to an error, so
consume_skb() seems to be more appropriate.

> 
> Same remark for final kfree_skb() in espintcp_recvmsg()
>