tanum****@nttda*****
tanum****@nttda*****
2011年 3月 8日 (火) 13:38:03 JST
田沼と申します。 私の方でも事象が確認できました。 X-Forwarded-For フィールドを追加する設定で 受信データ用バッファいっぱいまで recv した場合に 落ちるとみて間違いないと思います。 >> ja; rv:1.9.2.12) Gecko/20101026"..., cldata_len = 20512, >> cldata_bufsize = 20480, cmss = 1448, sorry_conn_flag = 0, old_dest = 上記は cldata_bufsize = 20480 なのに cldata_len = 20512 と超えています。 バッファサイズのデフォルト値の 20KB のデータを一度に recv するのが 難しかったので include/l7vs_conn.h のバッファサイズの最小を #define L7VS_CONN_READ_BUFSIZE_MIN 256 とかに下げて、/etc/l7vs/l7vs.cf に [conn] read_bufsize = 256 のような設定をいれてバッファサイズを小さくすると容易に事象が再現できます。 対処についてもとりあえず高館様の考えた方法で問題ないと思います。 X-Forwarded-For のフィールドは X-Forwarded-For: XXX.XXX.XXX.XXX\r\n 上記34バイトの追加が最大のはずなので、48バイトあれば 問題ないはずです。 同様にバッファサイズはそのままで conn.c:2511 の recv するサイズを 小さくするという手でも大丈夫かと思われますが、事前に多く確保して おいたほうがいいと思います。 > -----Original Message----- > From: ultra****@lists***** > [mailto:ultra****@lists*****] On Behalf Of > yosuke takadate > Sent: Monday, March 07, 2011 7:22 PM > To: ultra****@lists***** > Subject: [Ultramonkey-l7-users 395] Re: l7vsdプロセスが落ちる問題 > > 黒様様 > > 高舘です。 > 有用な情報ありがとうございます。 > X-Forwarded-For 、確かに気になっておりました。 > 要件上はずす事ができないのですが・・ > > &conn->cldata[20511]には文字列が格納されています。 > --- > (gdb) print &conn->cldata[20511] > $9 = 0x180920ef "4" > (gdb) print &conn->cldata[20480] > $7 = 0x180920d0 "94972114362627419947849511552144" > --- > > 原因がX-Forwarded-Forヘッダの追加による領域外アクセスならば > conn.c 253行目を以下のように変更すれば、もしかして問題は解決する > のでしょうか？ > --- > conn->cldata = (char *)malloc(conn->cldata_bufsize); > --- > #define X_FORWARDED_FOR_LENGTH 48 > 〜 > conn->cldata = (char *)malloc(conn->cldata_bufsize + > X_FORWARDED_FOR_LENGTH); > --- > > 2011年3月5日13:19 KUROSAWA Takahiro <takah****@gmail*****>: > > 黒沢と申します． > > > > At Fri, 4 Mar 2011 14:43:28 +0900, > > yosuke takadate wrote: > > > >> cldataのアドレスは取得できているので、 > >> "error / can not allocate memory for buffer"という > >> エラーログは出力されておりません。 > >> connの内容は以下のようになっています。 > >> > >> (gdb) print *conn > >> $1 = {lsock = 0x17b15160, srv = 0x17b151d0, dest = 0x17b23dc0, splice > >> = 0, caddr = {sin_family = 2, > >> sin_port = 53934, sin_addr = {s_addr = 3894339786}, sin_zero = > >> "\000\000\000\000\000\000\000"}, raddr = { > >> sin_family = 0, sin_port = 0, sin_addr = {s_addr = 0}, sin_zero = > >> "\000\000\000\000\000\000\000"}, > >> vaddr = {sin_family = 0, sin_port = 0, sin_addr = {s_addr = 0}, > >> sin_zero = "\000\000\000\000\000\000\000"}, > >> laddr = {sin_family = 0, sin_port = 0, sin_addr = {s_addr = 0}, > >> sin_zero = "\000\000\000\000\000\000\000"}, > >> ciom = 0x17afe9a0, riom = 0x17afe9c0, proto = 6 '\006', state = 0, > >> cldata = 0x1808d0d0 "POST /HOGE/upload > >> HTTP/1.1\r\nX-Forwarded-For: 111.222.333.444\r\nHost: > >> hoge.jp:8831\r\nUser-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; > >> ja; rv:1.9.2.12) Gecko/20101026"..., cldata_len = 20512, > >> cldata_bufsize = 20480, cmss = 1448, sorry_conn_flag = 0, old_dest = > >> 0x0} > >> > >> この状態で、conn.c:2923のfreeで落ちてしまうということは、 > >> cldataへの格納時点で、(マルチパートリクエスト時に起きやすい > >> 何らかの原因で)バッファ溢れが起きているのでしょうか。 > >> MALLOC_CHECKなどでmessageを検出できるように試してみたいと思います。 > > > > 久々に l7vsd のコードを見るので外しているかもしれませんが， > > X-Forwarded-For の追加処理で領域外アクセスを起こすように見えます． > > 上の core に対し，gdb から > > print &conn->cldata[20511] > > を実行して文字列が表示されるようだと，領域外アクセスが起きている > > 可能性が高そうです． > > > > 可能でしたら，ですが，l7directord.cf の --forwarded-for の設定を > > 外すとひとまず問題は回避できるかもしれません． > > > > _______________________________________________ > Ultramonkey-l7-users mailing list > Ultra****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/ultramonkey-l7-users
UltraMonkey-L7
Fork