В ядре Linux устранена следующая уязвимость: ethtool: Избегайте переполнения буфера пользовательского пространства по запросу статистики Ко…

В ядре Linux устранена следующая уязвимость: ethtool: Избегайте переполнения буфера пользовательского пространства по запросу статистики Команда ethtool -S действует по трем витольным вызовам: ETHTOOL_GSSET_INFO для размера, ETHTOOL_GSTRINGS для имен, и ETHTOOL_GSTATS для ценностей. Если количество статистических данных изменяется между этими вызовами (например, из-за устройства реконфигурация), распределение буфера пользователя будет неправиленным, потенциально приводит к переполнению буфера. Ожидается, что водители будут поддерживать стабильные статистические показатели, но некоторые водители (например, mlx5, bnx2x, bna, ksz884x) используют динамические счетчики, делая Этот сценарий возможен. Некоторые водители пытаются справиться с этим внутренне: - bnad_get_ethtool_stats() возвращается досрочно в случае, если статистика.n_stats не это равнозначно статистике водителя. -micrel/ksz884x также следит за тем, чтобы не писать ничего, кроме Стат.n_stats и переполняет буфер. Тем не менее, оба используют stats.n_stats, которая уже присваивается со значением вернулся с get_sset_count(), следовательно, не решит описанную проблему Здесь. Изменить ethtool_get_strings(), ethtool_get_stats(), ethtool_get_phy_stats() не возвращать ничего в случае несоответствия между размером пользователя и get_sset_size(), для предотвращения буфера Переполнение. Вернувшийся n_stats значение будет равно нулю, чтобы отразить это Ничего не было возвращено. Это может привести к одному из двух случаев при использовании upstream ethool, в зависимости от того, когда обнаружено изменение размера: 1. 1. При обнаружении в ethtool_get_strings(): # ethtool -S eth2 нет статистики доступно 2. 2. При обнаружении в статистике все статистические показатели будут сообщаться как нулевая. Оба случая, предположительно, являются преходящими, и последующий вызов ethtool Он должен добиться успеха. Помимо избегания переполнения, эти два случая очень очевидны (нет) выходной/очищенной статистики), что, возможно, лучше, чем представление неправильная/перемещенная статистика. Я также рассматривал возможность возвращения ошибки вместо «молчаливого» ответа, но Это кажется более разрушительным для приложений пользовательского пространства. Примечания: - Этот патч не претендует на исправление присущей расы, он только гарантирует что мы не переполняем буфер пользовательского пространства и делаем больше Предсказуемое поведение. - Замок RTNL удерживается во время каждого номера, гонок существует между Отдельные звонки ioctl, когда замок освобожден. - ethtool Userspace всегда заполняет статистику.n_stats, но вполне вероятно, что эти статистические значения реализованы в других приложениях пространства пользователя который может его не заполнить. Добавленный код проверяет, что это не ноль, Чтобы предотвратить любые регрессии.