In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in SMB request handling
A race condition exists between SMB request handling in
ksmbd_conn_handler_loop() and the freeing of ksmbd_conn in the
workqueue handler handle_ksmbd_work(). This leads to a UAF.
- KASAN: slab-use-after-free Read in handle_ksmbd_work
- KASAN: slab-use-after-free in rtlock_slowlock_locked
This race condition arises as follows:
ksmbd_conn_handler_loop() waits for conn->r_count to reach zero:
wait_event(conn->r_count_q, atomic_read(&conn->r_count) == 0);- Meanwhile,
handle_ksmbd_work() decrements conn->r_count using
atomic_dec_return(&conn->r_count), and if it reaches zero, calls
ksmbd_conn_free(), which frees conn.
- However, after
handle_ksmbd_work() decrements conn->r_count,
it may still access conn->r_count_q in the following line:
waitqueue_active(&conn->r_count_q) or wake_up(&conn->r_count_q)
This results in a UAF, as conn has already been freed.
The discovery of this UAF can be referenced in the following PR for
syzkaller's support for SMB requests.
References
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in SMB request handling
A race condition exists between SMB request handling in
ksmbd_conn_handler_loop()and the freeing ofksmbd_connin theworkqueue handler
handle_ksmbd_work(). This leads to a UAF.This race condition arises as follows:
ksmbd_conn_handler_loop()waits forconn->r_countto reach zero:wait_event(conn->r_count_q, atomic_read(&conn->r_count) == 0);handle_ksmbd_work()decrementsconn->r_countusingatomic_dec_return(&conn->r_count), and if it reaches zero, callsksmbd_conn_free(), which freesconn.handle_ksmbd_work()decrementsconn->r_count,it may still access
conn->r_count_qin the following line:waitqueue_active(&conn->r_count_q)orwake_up(&conn->r_count_q)This results in a UAF, as
connhas already been freed.The discovery of this UAF can be referenced in the following PR for
syzkaller's support for SMB requests.
References