Skip to content

Commit

Permalink
ksmbd: fix use-after-free in SMB request handling
Browse files Browse the repository at this point in the history
commit 9a8c5d89d327ff58e9b2517f8a6afb4181d32c6e upstream.

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.
Link: google/syzkaller#5524

Fixes: ee426bfb9d09 ("ksmbd: add refcnt to ksmbd_conn struct")
Cc: [email protected]
Cc: [email protected] # v6.6.55+, v6.10.14+, v6.11.3+
Cc: [email protected]
Signed-off-by: Yunseong Kim <[email protected]>
Acked-by: Namjae Jeon <[email protected]>
Signed-off-by: Steve French <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
(cherry picked from commit 1a955b62fd6adf91e4c4cfa05dc6f82b12f1f200)
  • Loading branch information
yskelg authored and opsiff committed Dec 7, 2024
1 parent 8691248 commit e656890
Showing 1 changed file with 4 additions and 0 deletions.
4 changes: 4 additions & 0 deletions fs/smb/server/server.c
Original file line number Diff line number Diff line change
Expand Up @@ -276,8 +276,12 @@ static void handle_ksmbd_work(struct work_struct *wk)
* disconnection. waitqueue_active is safe because it
* uses atomic operation for condition.
*/
atomic_inc(&conn->refcnt);
if (!atomic_dec_return(&conn->r_count) && waitqueue_active(&conn->r_count_q))
wake_up(&conn->r_count_q);

if (atomic_dec_and_test(&conn->refcnt))
kfree(conn);
}

/**
Expand Down

0 comments on commit e656890

Please sign in to comment.