In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_hid: move list and spinlock inits from bind to alloc There was an issue when you did the following: - setup and bind an hid gadget - open /dev/hidg0 - use the resulting fd in EPOLL_CTL_ADD - unbind the UDC - bind the UDC - use the fd in EPOLL_CTL_DEL When CONFIG_DEBUG_LIST was enabled, a list_del corruption was reported within remove_wait_queue (via ep_remove_wait_queue). After some debugging I found out that t
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: f_hid: move list and spinlock inits from bind to alloc
There was an issue when you did the following:
When CONFIG_DEBUG_LIST was enabled, a list_del corruption was reported within remove_wait_queue (via ep_remove_wait_queue). After some debugging I found out that the queues, which f_hid registers via poll_wait were the problem. These were initialized using init_waitqueue_head inside hidg_bind. So effectively, the bind function re-initialized the queues while there were still items in them.
The solution is to move the initialization from hidg_bind to hidg_alloc to extend their lifetimes to the lifetime of the function instance.
Additionally, I found many other possibly problematic init calls in the bind function, which I moved as well.
Why this VPI (explainable, experimental)
VPI breakdown
| Impact | 55.00 |
| Exploitation signal(No additional exploitation signal) | ×1.00 |
| VPI | 55.00 |
VPI formula vpi-v1