In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: gadget: Bail from dwc3_gadget_exit() if dwc->gadget is NULL There exists a possible scenario in which dwc3_gadget_init() can fail: during during host -> peripheral mode switch in dwc3_set_mode(), and a pending gadget driver fails to bind. Then, if the DRD undergoes another mode switch from peripheral->host the resulting dwc3_gadget_exit() will attempt to reference an invalid and dangling dwc->gadget pointer as well as call dma_free_coherent() on unmapped DMA pointers. The exact scenario can be reproduced as follows: - Start DWC3 in peripheral mode - Configure ConfigFS gadget with FunctionFS instance (or use g_ffs) - Run FunctionFS userspace application (open EPs, write descriptors, etc) - Bind gadget driver to DWC3's UDC - Switch DWC3 to host mode => dwc3_gadget_exit() is called. usb_del_gadget() will put the ConfigFS driver instance on the gadget_driver_pending_list - Stop FunctionFS application (closes the ep files) - Switch DWC3 to peripheral mode => dwc3_gadget_init() fails as usb_add_gadget() calls check_pending_gadget_drivers() and attempts to rebind the UDC to the ConfigFS gadget but fails with -19 (-ENODEV) because the FFS instance is not in FFS_ACTIVE state (userspace has not re-opened and written the descriptors yet, i.e. desc_ready!=0). - Switch DWC3 back to host mode => dwc3_gadget_exit() is called again, but this time dwc->gadget is invalid. Although it can be argued that userspace should take responsibility for ensuring that the FunctionFS application be ready prior to allowing the composite driver bind to the UDC, failure to do so should not result in a panic from the kernel driver. Fix this by setting dwc->gadget to NULL in the failure path of dwc3_gadget_init() and add a check to dwc3_gadget_exit() to bail out unless the gadget pointer is valid.

unity_linux UTSA-2025-988904: Unity Linux: kernel-5.10 (UTSA-2025-988904)

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2025-986840 advisory.

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

    usb: dwc3: gadget: Bail from dwc3_gadget_exit() if dwc->gadget is NULL

    There exists a possible scenario in which dwc3_gadget_init() can fail:
    during during host -> peripheral mode switch in dwc3_set_mode(), and     a pending gadget driver fails to bind.  Then, if the DRD undergoes     another mode switch from peripheral->host the resulting     dwc3_gadget_exit() will attempt to reference an invalid and dangling     dwc->gadget pointer as well as call dma_free_coherent() on unmapped     DMA pointers.

    The exact scenario can be reproduced as follows:
     - Start DWC3 in peripheral mode
     - Configure ConfigFS gadget with FunctionFS instance (or use g_ffs)
     - Run FunctionFS userspace application (open EPs, write descriptors, etc)
     - Bind gadget driver to DWC3's UDC
     - Switch DWC3 to host mode        => dwc3_gadget_exit() is called. usb_del_gadget() will put the             ConfigFS driver instance on the gadget_driver_pending_list
     - Stop FunctionFS application (closes the ep files)
     - Switch DWC3 to peripheral mode        => dwc3_gadget_init() fails as usb_add_gadget() calls             check_pending_gadget_drivers() and attempts to rebind the UDC             to the ConfigFS gadget but fails with -19 (-ENODEV) because the             FFS instance is not in FFS_ACTIVE state (userspace has not             re-opened and written the descriptors yet, i.e. desc_ready!=0).
     - Switch DWC3 back to host mode        => dwc3_gadget_exit() is called again, but this time dwc->gadget             is invalid.

    Although it can be argued that userspace should take responsibility     for ensuring that the FunctionFS application be ready prior to     allowing the composite driver bind to the UDC, failure to do so     should not result in a panic from the kernel driver.

    Fix this by setting dwc->gadget to NULL in the failure path of     dwc3_gadget_init() and add a check to dwc3_gadget_exit() to bail out     unless the gadget pointer is valid.

Tenable has extracted the preceding description block directly from the Unity Linux security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: gadget: Bail from     dwc3_gadget_exit() if dwc->gadget is NULL There exists a possible scenario in which dwc3_gadget_init() can     fail: during during host -> peripheral mode switch in dwc3_set_mode(), and a pending gadget driver fails     to bind. Then, if the DRD undergoes another mode switch from peripheral->host the resulting     dwc3_gadget_exit() will attempt to reference an invalid and dangling dwc->gadget pointer as well as call     dma_free_coherent() on unmapped DMA pointers. The exact scenario can be reproduced as follows: - Start     DWC3 in peripheral mode - Configure ConfigFS gadget with FunctionFS instance (or use g_ffs) - Run     FunctionFS userspace application (open EPs, write descriptors, etc) - Bind gadget driver to DWC3's UDC -     Switch DWC3 to host mode => dwc3_gadget_exit() is called. usb_del_gadget() will put the ConfigFS driver     instance on the gadget_driver_pending_list - Stop FunctionFS application (closes the ep files) - Switch     DWC3 to peripheral mode => dwc3_gadget_init() fails as usb_add_gadget() calls     check_pending_gadget_drivers() and attempts to rebind the UDC to the ConfigFS gadget but fails with -19     (-ENODEV) because the FFS instance is not in FFS_ACTIVE state (userspace has not re-opened and written the     descriptors yet, i.e. desc_ready!=0). - Switch DWC3 back to host mode => dwc3_gadget_exit() is called     again, but this time dwc->gadget is invalid. Although it can be argued that userspace should take     responsibility for ensuring that the FunctionFS application be ready prior to allowing the composite     driver bind to the UDC, failure to do so should not result in a panic from the kernel driver. Fix this by     setting dwc->gadget to NULL in the failure path of dwc3_gadget_init() and add a check to     dwc3_gadget_exit() to bail out unless the gadget pointer is valid. (CVE-2021-47272)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Severity
268709	Unity Linux 20.1070e Security Update: kernel (UTSA-2025-986840)	Nessus	Unity Linux Local Security Checks	medium
229869	Linux Distros Unpatched Vulnerability : CVE-2021-47272	Nessus	Misc.	medium

Detections

Analytics

CVE-2021-47272

medium

Tenable Plugins

Coming Soon

medium

medium