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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 21 Aug 2020 14:46:44 -0700
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Steffen Klassert <steffen.klassert@...unet.com>,
        David Miller <davem@...emloft.net>
Cc:     Herbert Xu <herbert@...dor.apana.org.au>, netdev@...r.kernel.org
Subject: Re: [PATCH 6/6] xfrm: add espintcp (RFC 8229)



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() ?

Same remark for final kfree_skb() in espintcp_recvmsg()

Thanks.


Powered by blists - more mailing lists