Hello everyone, Sorry, it's my fault to cause the misunderstanding. As I keep mentioning "hci_sock_sendmsg()" instead of "hci_sock_bound_ioctl()". In fact, both these two functions are able to cause the race. > >> > > > > My bad, was thinking more about the problem and noticed your poc was for hci_sock_sendmsg, > > not hci_sock_dev_event. > > I didn't catch this part. Are you talking about a different poc? > As far as I'm aware, exp.c in POC.zip was for hci_sock_bound_ioctl(HCIUNBLOCKADDR). > > hci_sock_bound_ioctl(HCIUNBLOCKADDR) (which is called between lock_sock() and release_sock()) > calls copy_from_user() which might cause page fault, and userfaultfd mechanism allows an attacker > to slowdown page fault handling enough to hci_sock_dev_event(HCI_DEV_UNREG) to return without > waiting for hci_sock_bound_ioctl(HCIUNBLOCKADDR) to call release_sock(). This race window > results in UAF (doesn't it, LinMa?). > Your understanding above is quite right. In addition, because the hci_sock_sendmsg() calls the memcpy_from_msg(...), which also in fact fetch data from userspace memory, the userfaultfd can take effect as well. (When writing the exploit for this CVE, the hci_sock_sendmsg() is much useful... so I recently keep mentioning this function) Regards Lin Ma
