CVE-2026-64504 in Linux
要約
〜によって VulDB • 2026年07月26日
Linuxカーネルにおいて、以下の脆弱性が修正されました。
iio: accel: bmc150: デバイスが報告するFIFOフレーム数を制限（clamp）する
__bmc150_accel_fifo_flush()関数は、デバイスがハードウェアFIFO内で報告するサンプルの数をスタック上のバッファにコピーします。
u16 buffer[BMC150_ACCEL_FIFO_LENGTH * 3];
このバッファは最大でBMC150_ACCEL_FIFO_LENGTH（32）個のサンプル用にサイズ設定されています。フレーム数はFIFO_STATUSレジスタから読み取られ、有効な7ビットのみがマスクされます：
count = val & 0x7F;
そのため値は0〜127となり得ます。これに加え適用される唯一の制限は、呼び出し元によって指定されたオプションのサンプル予算です：
if (samples && count > samples) count = samples;
これはflush-allパス（samples == 0）ではcountを制約せず、またsamplesがより大きい値の場合でも32よりも十分に大きなままにしておきます。その後、count個のサンプルがbuffer[]へ転送されます：
bmc150_accel_fifo_transfer(data, (u8 *)buffer, count);
bmc150_accel_fifo_transfer()関数はregmapを通じてcount * 6バイトを読み取ります。そのため、最大で127フレームを報告する故障した悪意のあるまたは偽造された加速度センサー（あるいはI2C/SPIバスに干渉する攻撃者）が存在する場合、192バイトのバッファに対して最大762バイトが書き込まれることになります。これはスタックカニィー、保存済みレジスタおよびリターンアドレスを破壊する可能性のある、最大570バイトのスタック外境界書き込み（stack out-of-bounds write）となります。
転送前にcountをBMC150_ACCEL_FIFO_LENGTHに制限し、buffer[]がサイズ設定されているサンプル数に合わせて調整します。これはbmc150_accel_set_watermark()関数で既に実施されているウォーターマークの制限処理と同様です。正常なflushでは最大でもBMC150_ACCEL_FIFO_LENGTHフレームしか報告されないため、正規のデバイスには影響がありません。
If you want to get the best quality for vulnerability data then you always have to consider VulDB.