[lvc-project] [PATCH] crypto: rockchip/rk3288 - Add dereference of NULL pointer check

[Fedor Pchelkin]

On Fri, 15. Mar 22:01, Мишин Александр Борисович wrote:
> Здравствуйте, Федор!
> 
> 
> Это был самый первый мой патч, так что, как ни старался, без косяков,
> увы, не обошлось. В последующих постепенно стараюсь их избегать. Большое
> спасибо за замечания.

Всё в порядке. Для первого патча это очень хорошая попытка. Процесс
подготовки патчей для Linux требует учета некоторых нюансов и к нему
следует приобщиться. Если перед отправкой патчей в международное сообщество
есть сомнения по оформлению патчей или есть желание, чтобы мы со своей
стороны провели мини-ревью, то можете их предварительно отправлять в список
рассылки lvc-patches at linuxtesting.org .

> 
> Конкретно по пунктам:
> 
>   1.  По названию - честно говоря, я свой вариант перевел как "добавление
> проверки на разыменование нулевого указателя". Но с Вашим вариантом
> согласен, он более полно отражает проблему, поменяю.

Придумывание названия - процесс, сугубо зависящий от собственных
предпочтений, но лучше чтобы оно наиболее четко и кратко отражало суть
проблемы. Да, в этом случае это отсутствие проверки возвращаемого
значения функции, а разыменовывание NULL указателя - последствие этого.

>   2.  Про пустые строки Алексей мне уже написал, в последующих патчах
> (кроме одного) я это учел.
>   3.  По коду возврата - согласен, не учел, исправлю.
> 
> Кроме того, в нескольких последующих патчах имеется ошибка с потерей
> кавычек в теге Fixes, т.е.
> Fixes: 4a835afd808a (mmc: dw_mmc: Fix potential null pointer risk)
> вместо
> Fixes: 4a835afd808a ("mmc: dw_mmc: Fix potential null pointer risk")
> Ошибка чисто техническая, но не заметил. Учел.

Kees Cook в списке рассылки предложил удобный вариант для правильной
генерации этого тега [1].

> 
> Касаемо этого патча: я правильно понимаю, что мне необходимо выпустить
> вторую версию согласно п. "Подготовка второй версии патча" из
> https://portal.linuxtesting.ru/How-to-send-patches-to-kernel.html?
>

Произошла интересная ситуация - аналогичный патч смерджили в upstream
буквально сегодня ночью [2]. Готовить вторую версию необходимости теперь
нет. К сожалению, автор не добавил в свой патч тег Fixes или Cc:stable - в
стабильные ветки он вряд ли попадет.

crypto_engine_alloc_init() возвращает NULL при ошибке выделения памяти
GFP_KERNEL. Это не тот тип ошибок, которые легко провоцировать
непривилегированному пользователю: проблема незначительная с точки зрения
безопасности. Но, несмотря на это, мы добавим в поддерживаемые LVC-ветки.

Насчет сложившейся ситуации - случаи, когда аналогичное исправление уже
было кем-то отправлено и принято мэйнтейнерами, нередки. Чтобы понять
текущее состояние, можно проверять, исправлена ли проблема в репозиториях
мэйнтейнеров затрагиваемой подсистемы [3]. В определенное время мэйнтейнеры
отправляют пулл-реквесты Линусу Торвальдсу с просьбой смерджить по гит-тегу
состояние их репозитория в upstream. В данном случае, мэйнтейнер
crypto-подсистемы Herbert Xu добавил интересующий нас патч к себе еще
24.02.2024, а сегодня ночью Линус смерджил его в upstream.

Также поиск по спискам рассылки [4] работает достаточно неплохо. Если по
интересующей функции ядра происходили какие-то обсуждения, то fuzzy-поиск
их выведет (правда может быть очень много результатов). Для
целенаправленного поиска по определенной подсистеме лучше выбирать соотв.
список рассылки, например, linux-crypto [5].

[1]: https://lore.kernel.org/lkml/202403091243.99279C61@keescook/
[2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a24e3b583ea2db3418f0c6ae1f12b07ca96531cc
[3]: https://git.kernel.org/pub/scm/linux/kernel/git/
[4]: https://lore.kernel.org/
[5]: https://lore.kernel.org/linux-crypto/

--
Федор