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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <2025082627-sinuous-ovary-21c9@gregkh>
Date: Tue, 26 Aug 2025 16:49:57 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Cheng Yu <serein.chengyu@...wei.com>
Cc: cve@...nel.org, linux-kernel@...r.kernel.org, tanghui20@...wei.com,
	zhangqiao22@...wei.com, huangjiale13@...artners.com
Subject: Re: [Question] fix CVE-2022-49980 introduces deadlock in linux-5.10.y

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