В ядре Linux устранена следующая уязвимость:
ipmi: исправлено использование после освобождения и повреждение списка при ошибке отправителя. Анализ Брено:
Когда отправитель SMI возвращает ошибку, smi_work() доставляет ошибку.
ответ, но затем возвращается к перезагрузке без правильной очистки:
1. intf->curr_msg не очищается, поэтому новое сообщение не извлекается
2. newmsg по-прежнему указывает на сообщение, вызывая вызов sender()
снова с тем же сообщением
3. Если sender() снова завершается с ошибкой, вызывается метод Deliver_err_response() с
тот же Recv_msg, который уже стоял в очереди на доставку
Это приводит к повреждению list_add («двойное добавление list_add»), поскольку
Recv_msg добавляется в список user_msg дважды.
Впоследствии
поврежденный список приводит к использованию после освобождения, когда память освобождается и
повторное использование и, в конечном итоге, разыменование NULL-указателя при доступе
Recv_msg-> готово. Последовательность ошибок:
отправитель() не работает
-> доставить_err_response(recv_msg) // Recv_msg поставлен в очередь на доставку
-> перейти к перезапуску // curr_msg не очищен!
sender() снова терпит неудачу (то же сообщение!)
-> доставить_err_response(recv_msg) // пытается поставить в очередь тот же самый Recv_msg
-> СПИСОК КОРРУПЦИИ
Исправьте это, освободив сообщение и установив для него значение NULL в случае ошибки отправки. Кроме того, всегда освобождайте newmsg при ошибке отправки, иначе произойдет утечка.
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: ipmi: Fix use-after-free and list corruption on sender error The analysis from Breno: When the SMI sender returns an error, smi_work() delivers an error response but then jumps back to restart without cleaning up properly: 1. intf->curr_msg is not cleared, so no new message is pulled 2. newmsg still points to the message, causing sender() to be called again with the same message 3. If sender() fails again, deliver_err_response() is called with the same recv_msg that was already queued for delivery This causes list_add corruption ("list_add double add") because the recv_msg is added to the user_msgs list twice. Subsequently, the corrupted list leads to use-after-free when the memory is freed and reused, and eventually a NULL pointer dereference when accessing recv_msg->done. The buggy sequence: sender() fails -> deliver_err_response(recv_msg) // recv_msg queued for delivery -> goto restart // curr_msg not cleared! sender() fails again (same message!) -> deliver_err_response(recv_msg) // tries to queue same recv_msg -> LIST CORRUPTION Fix this by freeing the message and setting it to NULL on a send error. Also, always free the newmsg on a send error, otherwise it will leak.