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.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:

ipmi: Soluciona el uso después de liberación y la corrupción de lista en error del remitente

El análisis de Breno:

Cuando el remitente SMI devuelve un error, smi_work() entrega una respuesta de error pero luego salta de nuevo para reiniciar sin limpiar correctamente:

1. intf->curr_msg no se borra, por lo que no se extrae ningún mensaje nuevo
2. newmsg todavía apunta al mensaje, haciendo que sender() sea llamado de nuevo con el mismo mensaje
3. Si sender() falla de nuevo, deliver_err_response() es llamado con el mismo recv_msg que ya estaba en cola para entrega

Esto causa corrupción de list_add ('list_add doble adición') porque el recv_msg es añadido a la lista user_msgs dos veces. Posteriormente, la lista corrupta lleva a un uso después de liberación cuando la memoria es liberada y reutilizada, y eventualmente a una desreferencia de puntero NULL al acceder a recv_msg->done.

La secuencia defectuosa:

sender() falla
-> deliver_err_response(recv_msg) // recv_msg en cola para entrega
-> goto restart // ¡curr_msg no borrado!
sender() falla de nuevo (¡mismo mensaje!)
-> deliver_err_response(recv_msg) // intenta poner en cola el mismo recv_msg
-> CORRUPCIÓN DE LISTA

Soluciona esto liberando el mensaje y estableciéndolo a NULL en un error de envío. Además, siempre libera el newmsg en un error de envío, de lo contrario, se producirá una fuga.