蝉は、やがて死ぬる午後に気づいた。ああ、私たち、もっと仕合せになってよかったのだ。:2010年03月28日分

2010/03/28(Sun)

[NetBSD] TODOs 消化中

とりあえず _locale_cache_t を将来的にexposedにした場合でなおかつ
nl_items が増えた場合に発生するであろうバイナリ互換性問題の対策 done.
なので ftp に放置プレイしてる multi-locale 実装も修正する必要があるのだけど
まぁこれは 6.0向けの作業が終わったら本気だすので後回し。

直後に去年おいらがしでかした s/Augst/August/ の間違いをchristos@が直してくれたのですが

fix tpo.

という commit log の再帰感がたまらなく好きです。

mbstate_t/wctype_t/wctrans_t の MI 化も done.

そんで MB_LEN_MAX の MI 化も片付けようと思ったのだけどこれが困った。

ただの人間には興味ありません。この中にNetBSD/hp700使いで、ja_JP.ISO-2022- JP、
ja_JP.ISO-2022-JP2、ja_JP.ct localeを常用してる人がいたら、あたしのところに来なさい。
以上。

この条件に当てはまる人はもれなく buffer overrun の可能性があります。
こんなん世に何人いるかというと、非実在青少年認定してもいいレベルだよなー

実在しました

かつて NetBSD では Citrus の merge に先立って、multibyte locale が使用できるよう
それまで MB_LEN_MAX=1 だったものを32に増やしたのですが( このへん参照)、386BSD由来のコードでMB_LEN_MAXは
MDとして宣言されてたものまでは修正していなかったので、2002年つまり Citrus merge 後に
portingされた CPUARCH=hppa な NetBSD/hp700 ではどうやら FreeBSD の limits.h の実装を参考にしたのか
MB_LEN_MAX=6 として commitされてしまいよってます(FreeBSD に hppa なんてないのにな、なんでだー)
ところが src/libc/locale/setlocale32.c では __mb_len_max_runtime の値を32でハードコードしてるので
buffer overrunする可能性が。

39 char *
40 __setlocale_mb_len_max_32(category, locale)
41 	int category;
42 	const char *locale;
43 {
44
45 	/* locale may be NULL */
46
47 	__mb_len_max_runtime = 32;
48 	return __setlocale(category, locale);
49 }

まぁ ISO-2022-JP なら冗長な escape sequence が発生しなければ最長6バイトなので
これまた悪意のある冗長なエスケープシーケンスを送り付けない限り問題にもならないので
多分今日まで一度もこのバグは踏まれたことはないであろうレベル。

ということでとりあえずは s/32/MB_LEN_MAX/ してbuffer overrunを防いで
hppa の MB_LEN_MAX 6 -> 32 化と MB_LEN_MAX 自体の MI化は libc major bump
のタイミングまでお預けということにしますか。