netdev - Re: [PATCH net-next 1/5] sctp: Bring SCTP_MAXSEG socket option into ietf API extension compliance

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: <20081226.111532.190275285.davem@davemloft.net>
Date:	Fri, 26 Dec 2008 11:15:32 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	vladislav.yasevich@...com
Cc:	netdev@...r.kernel.org, linux-sctp@...r.kernel.org,
	yjwei@...fujitsu.com
Subject: Re: [PATCH net-next 1/5] sctp: Bring SCTP_MAXSEG socket option
 into ietf API extension compliance

From: Vlad Yasevich <vladislav.yasevich@...com>
Date: Fri, 26 Dec 2008 12:04:14 -0500

> David Miller wrote:
> > From: Vlad Yasevich <vladislav.yasevich@...com>
> > Date: Fri, 19 Dec 2008 20:47:48 -0500
> > 
> >> From: Wei Yongjun <yjwei@...fujitsu.com>
> >>
> >> Brings maxseg socket option set/get into line with the latest ietf socket
> >> extensions API draft, while maintaining backwards compatibility.
> >>
> >> Signed-off-by: Wei Yongjun <yjwei@...fujitsu.com>
> >> Signed-off-by: Vlad Yasevich <vladislav.yasevich@...com>
> > 
> > Applied.  But I really dislike this scheme used by the compat code.
> > Half-way initializing a structure and then depending upon the logic in
> > the rest of the function to make sure the rest of the struct (the
> > uninitialized part) is never accessed?
> > 
> > Give me a break, programming, auditing, and bug fixing is hard enough
> > as it is without sloppy code like this.
> 
> Yes, it sucks but the since the draft keeps breaking the ABI between revisions,
> it leaves us a between a rock (no support) and a hard place (crappy code).

In this specific case we could have simply memset() the on-stack
structure to zero and there would be no confusion about whether the
object is initialized in some way in all code paths.

Or, in the main initial conditional we could explicitly assign both
members of this structure in both branches.

This is not about the compatibility issues, it's about how this code
was written.


--
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