[Question] fix CVE-2022-49980 introduces deadlock in linux-5.10.y

[Question] fix CVE-2022-49980 introduces deadlock in linux-5.10.y

[Cheng Yu]

Hello,
I noticed that the community has assigned CVE-2022-49980.
I found that the issue described by this CVE also exists
in the linux-5.10.y. Therefore, I attempted to backport
the fix patch to the linux-5.10.y, but encountered a
potential deadlock after applying the patch.
The specific call path is as follows:
   usb_add_gadget              [(1) mutex_lock(&udc_lock]
     -> device_add
       -> kobject_uevent
         -> uevent_ops->uevent
           -> dev->class->dev_uevent
             -> usb_udc_uevent [(2) mutex_lock(&udc_lock)]
This results in repeated acquisition of udc_lock, causing
a deadlock.
Does the community have any suggestions on how to resolve
this new deadlock issue introduced by the CVE fix?

Best regards,
--
Cheng Yu

Re: [Question] fix CVE-2022-49980 introduces deadlock in linux-5.10.y

[Greg KH]

On Tue, Aug 26, 2025 at 10:24:18PM +0800, Cheng Yu wrote:
> Hello,
> I noticed that the community has assigned CVE-2022-49980.
> I found that the issue described by this CVE also exists
> in the linux-5.10.y. Therefore, I attempted to backport
> the fix patch to the linux-5.10.y, but encountered a
> potential deadlock after applying the patch.
> The specific call path is as follows:
>    usb_add_gadget              [(1) mutex_lock(&udc_lock]
>      -> device_add
>        -> kobject_uevent
>          -> uevent_ops->uevent
>            -> dev->class->dev_uevent
>              -> usb_udc_uevent [(2) mutex_lock(&udc_lock)]
> This results in repeated acquisition of udc_lock, causing
> a deadlock.
> Does the community have any suggestions on how to resolve
> this new deadlock issue introduced by the CVE fix?

As you are making a business decision to stay on a very old kernel
version, I think that business decision includes doing the development
of fixes for it on your own :)

Seriously, the community doesn't do much, if any, work on older kernels
like this, especially ones as old as 5.10.y, as we do not even have
systems that run that kernel anymore.

Why not just move to a newer kernel version instead?  What's preventing
that from happening today?  You are going to have to do it soon anyway,
why not use this as a prompt to do so?

thanks,

greg k-h