CVE-2021-46986

In the Linux kernel, the following vulnerability has been resolved:

usb: dwc3: gadget: Free gadget structure only after freeing endpoints

As part of commit e81a7018d93a (usb: dwc3: allocate gadget structure dynamically) the dwc3_gadget_release() was added which will free the dwc->gadget structure upon the devices removal when usb_del_gadget_udc() is called in dwc3_gadget_exit().

However, simply freeing the gadget results a dangling pointer situation: the endpoints created in dwc3_gadget_init_endpoints() have their dep->endpoint.ep_list members chained off the list_head anchored at dwc->gadget->ep_list. Thus when dwc->gadget is freed, the first dwc3_ep in the list now has a dangling prev pointer and likewise for the next pointer of the dwc3_ep at the tail of the list. The dwc3_gadget_free_endpoints() that follows will result in a use-after-free when it calls list_del().

This was caught by enabling KASAN and performing a driver unbind. The recent commit 568262bf5492 (usb: dwc3: core: Add shutdown callback for dwc3) also exposes this as a panic during shutdown.

There are a few possibilities to fix this. One could be to perform a list_del() of the gadget->ep_list itself which removes it from the rest of the dwc3_ep chain.

Another approach is what this patch does, by splitting up the usb_del_gadget_udc() call into its separate del and put components. This allows dwc3_gadget_free_endpoints() to be called before the gadget is finally freed with usb_put_gadget().

Weakness

Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code.

Affected Software

Extended Description

The use of previously-freed memory can have any number of adverse consequences, ranging from the corruption of valid data to the execution of arbitrary code, depending on the instantiation and timing of the flaw. The simplest way data corruption may occur involves the system’s reuse of the freed memory. Use-after-free errors have two common and sometimes overlapping causes:

In this scenario, the memory in question is allocated to another pointer validly at some point after it has been freed. The original pointer to the freed memory is used again and points to somewhere within the new allocation. As the data is changed, it corrupts the validly used memory; this induces undefined behavior in the process. If the newly allocated data happens to hold a class, in C++ for example, various function pointers may be scattered within the heap data. If one of these function pointers is overwritten with an address to valid shellcode, execution of arbitrary code can be achieved.

Potential Mitigations

References

• https://git.kernel.org/stable/c/1ea775021282d90e1d08d696b7ab54aa75d688e5
• https://git.kernel.org/stable/c/b4b8e9601d7ee8806d2687f081a42485d27674a1
• https://git.kernel.org/stable/c/bb9c74a5bd1462499fe5ccb1e3c5ac40dcfa9139
• https://git.kernel.org/stable/c/bc0cdd72493236fb72b390ad38ce581e353c143c
• https://git.kernel.org/stable/c/1ea775021282d90e1d08d696b7ab54aa75d688e5
• https://git.kernel.org/stable/c/b4b8e9601d7ee8806d2687f081a42485d27674a1
• https://git.kernel.org/stable/c/bb9c74a5bd1462499fe5ccb1e3c5ac40dcfa9139
• https://git.kernel.org/stable/c/bc0cdd72493236fb72b390ad38ce581e353c143c