In the Linux kernel, the following vulnerability has been resolved: smb: client: cancel reconnect…

Why it is Amber

• CVSS 7.5 high
• Remotely exploitable without logging in
• On your watchlist: linux kernel

References

• https://git.kernel.org/stable/c/180380272f116dbd2b0354c5c7872e112e519149
• https://git.kernel.org/stable/c/2e5103e11a17c274715dd56cf185eeedccf686b8
• https://git.kernel.org/stable/c/7ab9ceedd860216fb97f2d8574cbe58b8906f42a
• https://git.kernel.org/stable/c/c65eae6f61d1778ff7a82e4aae4080e26f486af1
• https://git.kernel.org/stable/c/e3f6a779433d13aafb5edab59e4f9313051e8a52

Original description

In the Linux kernel, the following vulnerability has been resolved: smb: client: cancel reconnect work in clean_demultiplex_info() clean_demultiplex_info() cancels server->echo delayed work but not server->reconnect, which can cause a use-after-free when the demultiplex thread exits while a reconnect work is still queued: cifs_demultiplex_thread() cifs_readv_from_socket() cifs_reconnect() __cifs_reconnect() cifs_queue_server_reconn() mod_delayed_work(cifsiod_wq, &server->reconnect, 0) clean_demultiplex_info() cancel_delayed_work_sync(&server->echo) // echo canceled // reconnect NOT canceled kfree_sensitive(server) // server freed ...later, on cifsiod_wq: smb2_reconnect_server() server->srv_count // UAF read of freed server Fix this by canceling server->reconnect delayed work in clean_demultiplex_info() before the server is freed, the same way cifs_put_tcp_session() already does.