Descripción
En el Linux kernel se ha resuelto la siguiente vulnerabilidad: ksmbd: only rebind the reopened file's own oplock on durable reconnect ksmbd_reopen_durable_fd() recorre m_op_list del inode y vuelve a vincular cada oplock desvinculado a la sesión que se reconecta: list_for_each_entry_rcu(op, &ci->m_op_list, op_entry, lockdep_is_held(&ci->m_lock)) { if (op->conn) continue; op->conn = ksmbd_conn_get(fp->conn); op->sess = work->sess; } La única clave es op->conn == NULL, que coincide con todo handle durable desvinculado de ese inode, no solo con el que pertenece a fp. Cuando dos sesiones tienen handles durables sobre el mismo archivo y ambas se desconectan, al reconectarse una de ellas adopta el oplock de la otra sesión: op->sess se sobrescribe con la sesión que se reconecta sin tomar una referencia sobre ella, mientras op->conn fija la conexión. La ruta de desmontaje equivalente, session_fd_check(), usa como clave la identidad de la conexión que se desmonta (op->conn == conn) en lugar de un estado compartido, por lo que no tiene este problema. Una vez que la sesión adoptante se destruye, ksmbd_session_destroy() la libera mientras el oplock ajeno aún apunta a ella. El lector en ksmbd_close_fd_app_instance_id() valida solo opinfo->conn, que sigue activo gracias a la referencia tomada anteriormente, y luego desreferencia la sesión obsoleta: if (!opinfo->conn) { up_read(&fp->f_ci->m_lock); goto out; } ft = &opinfo->sess->file_table; write_lock(&ft->lock); BUG: KASAN: slab-use-after-free in _raw_write_lock+0x74/0xd0 Write of size 4 at addr ffff88810a970528 by task kworker/0:0/9 Workqueue: ksmbd-io handle_ksmbd_work Call Trace: _raw_write_lock+0x74/0xd0 ksmbd_close_fd_app_instance_id+0x183/0x410 smb2_open+0x1346/0x4430 handle_ksmbd_work+0x2bb/0x7b0 Es alcanzable desde una sesión autenticada contra un recurso compartido con la configuración por defecto de handles durables y oplocks: dos sesiones abren el mismo archivo con un handle durable-v2 y un lease RH bajo AppInstanceIds distintos, ambas cierran sesión, una se reconecta con DH2C, y una creación durable-v2 posterior que lleva el otro AppInstanceId accede a la sesión liberada. Se restringe el bucle al oplock que pertenece al archivo que se reabre.
Qué hacer
Revisa si usas el producto afectado y en qué versión, y aplica la actualización o la mitigación que indique el aviso del fabricante. CISA no ha confirmado que se esté explotando; si eso cambia, esta ficha pasa a «explotada» y te avisamos en el boletín.
Versiones afectadas
- Linux Afectadas: f363a0fb134a3eb9e47368b1edbd251fd76be84b y anteriores a 74e3ef4630f004c0de40c0540648a5a4033c6c9d · f363a0fb134a3eb9e47368b1edbd251fd76be84b y anteriores a 3f220a0a62e6b9b391c9d1f0e6580b05173cc7f7
- Linux Afectadas: 7.2 No afectadas: 7.2.4 · 7.3
Según el registro de la vulnerabilidad en CVE.org, tal como lo publicó el fabricante. Confirma tu versión exacta en el aviso del fabricante.
Referencias
- Referencia en git.kernel.orggit.kernel.org/stable/c/74e3ef4630f004c0de40c0540648a5a4033c6c9d
- Referencia en git.kernel.orggit.kernel.org/stable/c/3f220a0a62e6b9b391c9d1f0e6580b05173cc7f7
Ver el texto original en inglés (CVE.org)
ksmbd: only rebind the reopened file's own oplock on durable reconnect
In the Linux kernel, the following vulnerability has been resolved: ksmbd: only rebind the reopened file's own oplock on durable reconnect ksmbd_reopen_durable_fd() walks the inode's m_op_list and rebinds every detached oplock to the reconnecting session: list_for_each_entry_rcu(op, &ci->m_op_list, op_entry, lockdep_is_held(&ci->m_lock)) { if (op->conn) continue; op->conn = ksmbd_conn_get(fp->conn); op->sess = work->sess; } The only key is op->conn == NULL, which every detached durable handle on that inode matches, not just the one owned by fp. When two sessions hold durable handles on the same file and both disconnect, reconnecting one of them adopts the other session's oplock: op->sess is overwritten with the reconnecting session without taking a reference on it, while op->conn pins the connection. The sibling teardown path, session_fd_check(), keys on the identity of the connection being torn down (op->conn == conn) rather than on shared state, and so does not have this problem. Once the adopting session is destroyed, ksmbd_session_destroy() frees it while the foreign oplock still points at it. The reader in ksmbd_close_fd_app_instance_id() validates only opinfo->conn, which is still live thanks to the reference taken above, and then dereferences the stale session: if (!opinfo->conn) { up_read(&fp->f_ci->m_lock); goto out; } ft = &opinfo->sess->file_table; write_lock(&ft->lock); BUG: KASAN: slab-use-after-free in _raw_write_lock+0x74/0xd0 Write of size 4 at addr ffff88810a970528 by task kworker/0:0/9 Workqueue: ksmbd-io handle_ksmbd_work Call Trace: _raw_write_lock+0x74/0xd0 ksmbd_close_fd_app_instance_id+0x183/0x410 smb2_open+0x1346/0x4430 handle_ksmbd_work+0x2bb/0x7b0 Reached from an authenticated session against a share with the default durable-handle and oplock configuration: two sessions open the same file with a durable-v2 handle and an RH lease under distinct AppInstanceIds, both log off, one reconnects with DH2C, and a later durable-v2 create carrying the other AppInstanceId walks into the freed session. Constrain the loop to the oplock owned by the file being reopened.