There&#39;s a bug in the current HEAD of rrdtool (and I suppose going back to mid-2007, from the <font face="&#39;courier new&#39;, monospace">svn blame</font> output) which causes it to segfault if you point it at an rrdcached socket which isn&#39;t writable. I&#39;ve attached a patch against trunk, and reproduction steps are below:<div>

<br></div><div><font face="&#39;courier new&#39;, monospace">cd ~</font></div><div><font face="&#39;courier new&#39;, monospace">mkdir rrds/</font></div><div><font face="&#39;courier new&#39;, monospace">rrdtool create rrds/test.rrd DS:data:GAUGE:360:U:U RRA:MAX:0.5:1:120 -s 1 </font></div>

<div><font face="&#39;courier new&#39;, monospace">rrdtool update rrds/test.rrd N:0</font></div><div><div><font face="&#39;courier new&#39;, monospace">rrdtool xport --start $(( $(date +%s) - 120)) --end $(date +%s) DEF:ds0=$HOME/rrds/test.rrd:data:MAX XPORT:ds0</font><font face="arial, helvetica, sans-serif">     <i>(this one should work)</i></font></div>

<div><font face="&#39;courier new&#39;, monospace">rrdtool xport --start $(( $(date +%s) - 120)) --end $(date +%s) --daemon $HOME/this_path_does_not_exist.sock DEF:ds0=$HOME/rrds/test.rrd:data:MAX XPORT:ds0</font><font face="arial, helvetica, sans-serif">    <i>(this one should segfault)</i></font></div>

<div><br></div><div>rrdtool is assuming that rrd_xport will always return -1 on failure; however, rrd_xport returns errno (which is, generally, not -1) if rrd_client fails. I figured it was easier to change rrdtool than to change everything in rrd_client. For good measure, I also changed the checks on the calls to rrd_fetch and rrd_graph. I&#39;m not sure if they&#39;re susceptible to the same problem, but, well, better to check for the one thing you do what you want than to enumerate all the possible things you don&#39;t want.</div>

<div><br></div><div>This segfault is caused by an uninitialized variable use (in particular, legend_v and col_cnt end up being used and passed to printf uninitialized). Nothing offhand jumped out at me as easily-exploitable to do code injection, but I only spent five or so minutes looking at it, so there very well may be a security problem hiding behind this.</div>

<div><br></div><div>Cheers,</div>-- <br>James Brown<div>Systems Engineer</div><div>Yelp, Inc.</div><br>
</div>