There's a bug in the current HEAD of rrdtool (and I suppose going back to mid-2007, from the <font face="'courier new', monospace">svn blame</font> output) which causes it to segfault if you point it at an rrdcached socket which isn't writable. I've attached a patch against trunk, and reproduction steps are below:<div>
<br></div><div><font face="'courier new', monospace">cd ~</font></div><div><font face="'courier new', monospace">mkdir rrds/</font></div><div><font face="'courier new', 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="'courier new', monospace">rrdtool update rrds/test.rrd N:0</font></div><div><div><font face="'courier new', 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="'courier new', 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'm not sure if they'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'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>