In the Linux kernel, the following vulnerability has been resolved:

tracing: Fix WARN_ON in tracing_buffers_mmap_close

When a process forks, the child process copies the parent's VMAs but the
user_mapped reference count is not incremented. As a result, when both the
parent and child processes exit, tracing_buffers_mmap_close() is called
twice. On the second call, user_mapped is already 0, causing the function to
return -ENODEV and triggering a WARN_ON.

Normally, this isn't an issue as the memory is mapped with VM_DONTCOPY set.
But this is only a hint, and the application can call
madvise(MADVISE_DOFORK) which resets the VM_DONTCOPY flag. When the
application does that, it can trigger this issue on fork.

Fix it by incrementing the user_mapped reference count without re-mapping
the pages in the VMA's open callback.

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

tracing: Corrección de WARN_ON en tracing_buffers_mmap_close

Cuando un proceso hace fork, el proceso hijo copia los VMAs del padre pero el contador de referencias user_mapped no se incrementa. Como resultado, cuando tanto el proceso padre como el hijo terminan, tracing_buffers_mmap_close() se llama dos veces. En la segunda llamada, user_mapped ya es 0, lo que hace que la función devuelva -ENODEV y active un WARN_ON.

Normalmente, esto no es un problema ya que la memoria está mapeada con VM_DONTCOPY establecido. Pero esto es solo una sugerencia, y la aplicación puede llamar a madvise(MADVISE_DOFORK) lo que restablece el flag VM_DONTCOPY. Cuando la aplicación hace eso, puede activar este problema al hacer fork.

Se soluciona incrementando el contador de referencias user_mapped sin remapear las páginas en la función de callback 'open' del VMA.