BIND 10 #271: build failure with sunstudio in rrttl_python.cc and rrtype_python.cc

[BIND 10 Development]

#271: build failure with sunstudio in rrttl_python.cc and rrtype_python.cc
---------------------------+------------------------------------------------
 Reporter:  jreed          |        Owner:  jelte                      
     Type:  defect         |       Status:  reviewing                  
 Priority:  major          |    Milestone:  06. 4th Incremental Release
Component:  DNSPacket API  |   Resolution:                             
 Keywords:                 |    Sensitive:  0                          
---------------------------+------------------------------------------------

Comment(by jinmei):

 Replying to [comment:3 jelte]:
 >
 > using a vector on the stack makes it less susceptible to memory leaks,
 but not exception-safe (at least, not without an exception-safe allocator
 thrown into its constructor), it would only result in a different type of
 bad_alloc being thrown.

 I'm not sure what kind of failure mode you're talking about...do you mean
 the construction of vector could throw an exception?  If so, that's true,
 and, realistically, the pythong program calling this wrapper would simply
 die in that case.  I wouldn't bother to solve this failure mode, and this
 is not what I meant by "exception-safe" (I'd use "exception-free" in that
 sense).  Maybe we are using different definitions of exception-safe?

 On the other hand, the original 271.diff has a more critical problem, if I
 understand it correctly.  See, for example, RRTTL_init().  This is called
 in the context of "from-wire" construction, right?  So if the wire data is
 bogus and (e.g.) has an insufficent length of data, the RRTTL constructor
 will throw an exception, and the temporarily allocated memory will leak.
 This can be a remotely exploitable DoS.  (although it wouldn't happen as
 long as we use the RRTTL constructor via a DNS message parser).  The
 vector version doesn't have this problem.

-- 
Ticket URL: <http://bind10.isc.org/ticket/271#comment:4>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development