ClamAV - clamd の OnAccessExtraScanning 機能のメモリリークをレポートした

ClamAV - clamd の OnAccessExtraScanning を使う際にメモリリークする不具合を見つけたのでバグレポートをだした

https://bugzilla.clamav.net/show_bug.cgi?id=12048

fix が入る前に公表してよいものか?

当初は 🔑 付きの issue として閲覧が制限されていたが、 担当者によって public な issue に変えられた。脆弱性としては扱われなかったようだ。

よって、本エントリで公言しても問題なかろうと判断している。

サマリ

環境や再現手順の詳細はリンク先を参照して欲しい。 このエントリではサマリを書いておこう

OnAccessExtraScanning とは ?

clamd で OnAccessExtraScanning yes にすると OnAccessIncludePathディレクトリ以下をオンアクセススキャンの対象とすることができ。 OnAccessIncludePathディレクトリ配下に新たなファイルやサブディレクトリを作る/移動/ リネームすると、 clamd が変更を検知してくれてスキャンしてくれるのだ

どういう不具合ですか?

  • clamd は動的にスキャン対象を追加する処理を pthread_create(3) して別スレッドに処理を委譲する設計としている
  • その際に pthread_attr_setdetachstate(..., PTHREAD_CREATE_JOINABLE) を指定してスレッドを作る
  • が、生成したスレッドを pthread_join(3) しないため pthread_create 内部で割り当てたメモリリージョンがリークする

どうやったら直りそうですか?

  1. pthread_join(3) しない設計のままメモリリークを解決するなら PTHREAD_CREATE_DETACHED を指定すべきだろう
  2. pthread_join(3) したまま設計を変える。1よりも粒度の大きい変更になるだろう
  3. そもそも スレッド使う設計をやめる

ぱっと、3択が考えられた。2 と 3 はちと粒度が大きすぎて自分が fix 案を提案できる感じではなかった。

最初に 1 を進言してみて最初は担当者にも同意してもらえていたが、問題を起こすことが発覚して 2 を選択する計画にしたようだ。PTHREAD_CREATE_DETACHED に変えてメモリリークを直すことだけにフォーカスしていて、副作用をだしていたことまでは把握できなかった。

0.100.0 を飛ばして 0.100.1 で fix されるというステータスになっているのが今ここのステータス

感想

  • 再現手順が単純なステップだったので、突き止めるのもスムーズに行った。
  • 不具合の再現を取っていて困ったのは、再現を取る中で 別の メモリリークが起きるのと clamd が SIGABORT するケースも併発しており、これらをどうやって切り離してレポートを書くかだった。(1レポートでは1つの不具合にフォーカスした方がよいだろうという考え)

なお、 調査は業務の一貫として行っております 😊