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  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:	Mon, 7 Jul 2014 08:54:07 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Daniel Borkmann' <dborkman@...hat.com>,
	"davem@...emloft.net" <davem@...emloft.net>
CC:	"geirola@...il.com" <geirola@...il.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-sctp@...r.kernel.org" <linux-sctp@...r.kernel.org>
Subject: RE: [PATCH net-next 3/5] net: sctp: implement rfc6458, 5.3.5.
 SCTP_RCVINFO cmsg support

From: Daniel Borkmann
> From: Geir Ola Vaagland <geirola@...il.com>
> 
> This patch implements section 5.3.5. of RFC6458, that is, support
> for 'SCTP Receive Information Structure' (SCTP_RCVINFO) which is
> placed into ancillary data cmsghdr structure for each recvmsg()
> call.
> 
> This option can be enabled/disabled via setsockopt(2) on SOL_SCTP
> level by setting an int value with 1/0 for SCTP_RECVRCVINFO in user
> space applications as per RFC6458, section 8.1.29.
> 
> The sctp_rcvinfo structure is defined as per RFC as below ...
> 
>   struct sctp_rcvinfo {
>     uint16_t rcv_sid;
>     uint16_t rcv_ssn;
>     uint16_t rcv_flags;
>     <-- 2 bytes hole  -->
>     uint32_t rcv_ppid;
>     uint32_t rcv_tsn;
>     uint32_t rcv_cumtsn;
>     uint32_t rcv_context;
>     sctp_assoc_t rcv_assoc_id;
>   };
> 
> ... and provided under cmsg_level IPPROTO_SCTP, cmsg_type
> SCTP_RCVINFO, while cmsg_data[] contains struct sctp_rcvinfo.
> An sctp_rcvinfo item always corresponds to the data in msg_iov.
> 
> Joint work with Daniel Borkmann.
...
> +/* RFC6458, Section 5.3.5 SCTP Receive Information Structure
> + * (SCTP_SNDRCV)
> + */
> +void sctp_ulpevent_read_rcvinfo(const struct sctp_ulpevent *event,
> +				struct msghdr *msghdr)
> +{
> +	struct sctp_rcvinfo rinfo;
> +
> +	if (sctp_ulpevent_is_notification(event))
> +		return;
> +
> +	memset(&rinfo, 0, sizeof(struct sctp_rcvinfo));
> +	rinfo.rcv_sid = event->stream;
> +	rinfo.rcv_ssn = event->ssn;
> +	rinfo.rcv_ppid = event->ppid;
> +	rinfo.rcv_flags = event->flags;
> +	rinfo.rcv_tsn = event->tsn;
> +	rinfo.rcv_cumtsn = event->cumtsn;
> +	rinfo.rcv_assoc_id = sctp_assoc2id(event->asoc);
> +	rinfo.rcv_context = event->asoc->default_rcv_context;
> +
> +	put_cmsg(msghdr, IPPROTO_SCTP, SCTP_RCVINFO,
> +		 sizeof(rinfo), &rinfo);
> +}

This gets called for every receive data chunk (since the user needs to
verify the ssn and stream).

It really ought to be possible to write the 'cmsg' data with quite so
many memory accesses.

Perhaps you should add named fields for the pads so they can be explicitly zeroed.

It also seems that put_cmsg() should be able to return the pointer to
where the data should be written - instead on copying the data itself.

	David



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists