linux-kernel - Re: CVE-2022-50031: scsi: iscsi: Fix HW conn removal use after free

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 for Android: free password hash cracker in your pocket

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

Message-ID: <1b283ae6-d972-4b85-bd4c-bfbb58492914@huawei.com>
Date: Thu, 7 Aug 2025 09:35:25 +0800
From: Li Lingfeng <lilingfeng3@...wei.com>
To: Greg Kroah-Hartman <gregkh@...nel.org>
CC: <cve@...nel.org>, <linux-kernel@...r.kernel.org>,
	<linux-cve-announce@...r.kernel.org>, <lduncan@...e.com>,
	<cleech@...hat.com>, Mike Christie <michael.christie@...cle.com>,
	<James.Bottomley@...senpartnership.com>, <martin.petersen@...cle.com>,
	<open-iscsi@...glegroups.com>, <linux-scsi@...r.kernel.org>, yangerkun
	<yangerkun@...wei.com>, "zhangyi (F)" <yi.zhang@...wei.com>, Hou Tao
	<houtao1@...wei.com>, "yukuai (C)" <yukuai3@...wei.com>,
	"chengzhihao1@...wei.com" <chengzhihao1@...wei.com>, <liumingrui@...wei.com>
Subject: Re: CVE-2022-50031: scsi: iscsi: Fix HW conn removal use after free

Hi, Greg

在 2025/7/3 22:33, Greg Kroah-Hartman 写道:
> On Thu, Jul 03, 2025 at 10:16:58PM +0800, Li Lingfeng wrote:
>> Hi, Greg
>>
>> 在 2025/6/18 19:01, Greg Kroah-Hartman 写道:
>>> From: Greg Kroah-Hartman <gregkh@...nel.org>
>>>
>>> Description
>>> ===========
>>>
>>> In the Linux kernel, the following vulnerability has been resolved:
>>>
>>> scsi: iscsi: Fix HW conn removal use after free
>>>
>>> If qla4xxx doesn't remove the connection before the session, the iSCSI
>>> class tries to remove the connection for it. We were doing a
>>> iscsi_put_conn() in the iter function which is not needed and will result
>>> in a use after free because iscsi_remove_conn() will free the connection.
>>>
>>> The Linux kernel CVE team has assigned CVE-2022-50031 to this issue.
>>>
>>>
>>> Affected and fixed versions
>>> ===========================
>>>
>>> 	Fixed in 5.19.4 with commit 0483ffc02ebb953124c592485a5c48ac4ffae5fe
>>> 	Fixed in 6.0 with commit c577ab7ba5f3bf9062db8a58b6e89d4fe370447e
>>>
>>> Please see https://www.kernel.org for a full list of currently supported
>>> kernel versions by the kernel community.
>>>
>>> Unaffected versions might change over time as fixes are backported to
>>> older supported kernel versions.  The official CVE entry at
>>> 	https://cve.org/CVERecord/?id=CVE-2022-50031
>>> will be updated if fixes are backported, please check that for the most
>>> up to date information about this issue.
>>>
>>>
>>> Affected files
>>> ==============
>>>
>>> The file(s) affected by this issue are:
>>> 	drivers/scsi/scsi_transport_iscsi.c
>>>
>>>
>>> Mitigation
>>> ==========
>>>
>>> The Linux kernel CVE team recommends that you update to the latest
>>> stable kernel version for this, and many other bugfixes.  Individual
>>> changes are never tested alone, but rather are part of a larger kernel
>>> release.  Cherry-picking individual commits is not recommended or
>>> supported by the Linux kernel community at all.  If however, updating to
>>> the latest release is impossible, the individual changes to resolve this
>>> issue can be found at these commits:
>>> 	https://git.kernel.org/stable/c/0483ffc02ebb953124c592485a5c48ac4ffae5fe
>>> 	https://git.kernel.org/stable/c/c577ab7ba5f3bf9062db8a58b6e89d4fe370447e
>>>
>> Based on the details described in the linked discussion, I have concerns
>> that this patch may not fully resolve the Use-After-Free vulnerability.
>> Instead, it appears the changes could potentially introduce memory leak
>> issues.
> Great, then that is a different type of issue, and when fixed, would get
> a different CVE assigned to it.
>
>> Given these concerns, I'd recommend rejecting this CVE until we can
>> thoroughly investigate and validate the complete solution.
> This fixes a known issue, why would it be rejected as such?  The only
> way we would reject this is if the upstream commit is reverted because
> it was deemed to not be correct at all.  If you feel this is the case,
> please work to get that commit reverted there first.
Since it has been reverted by commit 7bdc68921481 ("scsi: Revert "scsi:
iscsi: Fix HW conn removal use after free""), can this CVE be rejected
now?

Links: 
https://lore.kernel.org/all/20250715073926.3529456-1-lilingfeng3@huawei.com/

Thanks,

Lingfeng

>
> Otherwise just fix the new bug :)
>
> thanks,
>
> greg k-h