"value":"In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix use-after-free in SMB request handling\n\nA race condition exists between SMB request handling in\n`ksmbd_conn_handler_loop()` and the freeing of `ksmbd_conn` in the\nworkqueue handler `handle_ksmbd_work()`. This leads to a UAF.\n- KASAN: slab-use-after-free Read in handle_ksmbd_work\n- KASAN: slab-use-after-free in rtlock_slowlock_locked\n\nThis race condition arises as follows:\n- `ksmbd_conn_handler_loop()` waits for `conn->r_count` to reach zero:\n `wait_event(conn->r_count_q, atomic_read(&conn->r_count) == 0);`\n- Meanwhile, `handle_ksmbd_work()` decrements `conn->r_count` using\n `atomic_dec_return(&conn->r_count)`, and if it reaches zero, calls\n `ksmbd_conn_free()`, which frees `conn`.\n- However, after `handle_ksmbd_work()` decrements `conn->r_count`,\n it may still access `conn->r_count_q` in the following line:\n `waitqueue_active(&conn->r_count_q)` or `wake_up(&conn->r_count_q)`\n This results in a UAF, as `conn` has already been freed.\n\nThe discovery of this UAF can be referenced in the following PR for\nsyzkaller's support for SMB requests."
"value":"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: se corrige el problema de use-after-free en la gesti\u00f3n de solicitudes SMB Existe una condici\u00f3n de ejecuci\u00f3n entre la gesti\u00f3n de solicitudes SMB en `ksmbd_conn_handler_loop()` y la liberaci\u00f3n de `ksmbd_conn` en el controlador de cola de trabajo `handle_ksmbd_work()`. Esto conduce a una UAF. - KASAN: slab-use-after-free Leer en handle_ksmbd_work - KASAN: slab-use-after-free en rtlock_slowlock_locked Esta condici\u00f3n de ejecuci\u00f3n surge de la siguiente manera: - `ksmbd_conn_handler_loop()` espera a que `conn->r_count` llegue a cero: `wait_event(conn->r_count_q, atomic_read(&conn->r_count) == 0);` - Mientras tanto, `handle_ksmbd_work()` decrementa `conn->r_count` usando `atomic_dec_return(&conn->r_count)`, y si llega a cero, llama a `ksmbd_conn_free()`, que libera a `conn`. - Sin embargo, despu\u00e9s de que `handle_ksmbd_work()` disminuya `conn->r_count`, a\u00fan puede acceder a `conn->r_count_q` en la siguiente l\u00ednea: `waitqueue_active(&conn->r_count_q)` o `wake_up(&conn->r_count_q)` Esto da como resultado un UAF, ya que `conn` ya se ha liberado. Se puede hacer referencia al descubrimiento de este UAF en la siguiente PR para el soporte de syzkaller para solicitudes SMB."
