https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 29 Sep 2026 01:17:42 +0000 https://vulnerability.circl.lu/vuln/cve-2022-49789 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>scsi: zfcp: Fix double free of FSF request when qdio send fails</p> <p>We used to use the wrong type of integer in &#39;zfcp_fsf_req_send()&#39; to cache the FSF request ID when sending a new FSF request. This is used in case the sending fails and we need to remove the request from our internal hash table again (so we don&#39;t keep an invalid reference and use it when we free the request again).</p> <p>In &#39;zfcp_fsf_req_send()&#39; we used to cache the ID as &#39;int&#39; (signed and 32 bit wide), but the rest of the zfcp code (and the firmware specification) handles the ID as &#39;unsigned long&#39;/&#39;u64&#39; (unsigned and 64 bit wide [s390x ELF ABI]). For one this has the obvious problem that when the ID grows past 32 bit (this can happen reasonably fast) it is truncated to 32 bit when storing it in the cache variable and so doesn&#39;t match the original ID anymore. The second less obvious problem is that even when the original ID has not yet grown past 32 bit, as soon as the 32nd bit is set in the original ID (0x80000000 = 2&#39;147&#39;483&#39;648) we will have a mismatch when we cast it back to &#39;unsigned long&#39;. As the cached variable is of a signed type, the compiler will choose a sign-extending instruction to load the 32 bit variable into a 64 bit register (e.g.: &#39;lgf %r11,188(%r15)&#39;). So once we pass the cached variable into &#39;zfcp_reqlist_find_rm()&#39; to remove the request again all the leading zeros will be flipped to ones to extend the sign and won&#39;t match the…</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>scsi: zfcp: Fix double free of FSF request when qdio send fails</p> <p>We used to use the wrong type of integer in &#39;zfcp_fsf_req_send()&#39; to cache the FSF request ID when sending a new FSF request. This is used in case the sending fails and we need to remove the request from our internal hash table again (so we don&#39;t keep an invalid reference and use it when we free the request again).</p> <p>In &#39;zfcp_fsf_req_send()&#39; we used to cache the ID as &#39;int&#39; (signed and 32 bit wide), but the rest of the zfcp code (and the firmware specification) handles the ID as &#39;unsigned long&#39;/&#39;u64&#39; (unsigned and 64 bit wide [s390x ELF ABI]). For one this has the obvious problem that when the ID grows past 32 bit (this can happen reasonably fast) it is truncated to 32 bit when storing it in the cache variable and so doesn&#39;t match the original ID anymore. The second less obvious problem is that even when the original ID has not yet grown past 32 bit, as soon as the 32nd bit is set in the original ID (0x80000000 = 2&#39;147&#39;483&#39;648) we will have a mismatch when we cast it back to &#39;unsigned long&#39;. As the cached variable is of a signed type, the compiler will choose a sign-extending instruction to load the 32 bit variable into a 64 bit register (e.g.: &#39;lgf %r11,188(%r15)&#39;). So once we pass the cached variable into &#39;zfcp_reqlist_find_rm()&#39; to remove the request again all the leading zeros will be flipped to ones to extend the sign and won&#39;t match the…</p> https://vulnerability.circl.lu/vuln/cve-2022-49789