cve-2022-49789
Vulnerability from cvelistv5
Published
2025-05-01 14:09
Modified
2025-05-01 14:09
Severity ?
Summary
scsi: zfcp: Fix double free of FSF request when qdio send fails
Impacted products
LinuxLinux
LinuxLinux
Show details on NVD website


{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/s390/scsi/zfcp_fsf.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "1bf8ed585501bb2dd0b5f67c824eab45adfbdccd",
              "status": "affected",
              "version": "e60a6d69f1f84c2ef1cc63aefaadfe7ae9f12934",
              "versionType": "git"
            },
            {
              "lessThan": "d2c7d8f58e9cde8ac8d1f75e9d66c2a813ffe0ab",
              "status": "affected",
              "version": "e60a6d69f1f84c2ef1cc63aefaadfe7ae9f12934",
              "versionType": "git"
            },
            {
              "lessThan": "11edbdee4399401f533adda9bffe94567aa08b96",
              "status": "affected",
              "version": "e60a6d69f1f84c2ef1cc63aefaadfe7ae9f12934",
              "versionType": "git"
            },
            {
              "lessThan": "90a49a6b015fa439cd62e45121390284c125a91f",
              "status": "affected",
              "version": "e60a6d69f1f84c2ef1cc63aefaadfe7ae9f12934",
              "versionType": "git"
            },
            {
              "lessThan": "0954256e970ecf371b03a6c9af2cf91b9c4085ff",
              "status": "affected",
              "version": "e60a6d69f1f84c2ef1cc63aefaadfe7ae9f12934",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/s390/scsi/zfcp_fsf.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "2.6.34"
            },
            {
              "lessThan": "2.6.34",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.4.*",
              "status": "unaffected",
              "version": "5.4.225",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.10.*",
              "status": "unaffected",
              "version": "5.10.156",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.15.*",
              "status": "unaffected",
              "version": "5.15.80",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.0.*",
              "status": "unaffected",
              "version": "6.0.10",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.1",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: zfcp: Fix double free of FSF request when qdio send fails\n\nWe used to use the wrong type of integer in \u0027zfcp_fsf_req_send()\u0027 to cache\nthe FSF request ID when sending a new FSF request. This is used in case the\nsending fails and we need to remove the request from our internal hash\ntable again (so we don\u0027t keep an invalid reference and use it when we free\nthe request again).\n\nIn \u0027zfcp_fsf_req_send()\u0027 we used to cache the ID as \u0027int\u0027 (signed and 32\nbit wide), but the rest of the zfcp code (and the firmware specification)\nhandles the ID as \u0027unsigned long\u0027/\u0027u64\u0027 (unsigned and 64 bit wide [s390x\nELF ABI]).  For one this has the obvious problem that when the ID grows\npast 32 bit (this can happen reasonably fast) it is truncated to 32 bit\nwhen storing it in the cache variable and so doesn\u0027t match the original ID\nanymore.  The second less obvious problem is that even when the original ID\nhas not yet grown past 32 bit, as soon as the 32nd bit is set in the\noriginal ID (0x80000000 = 2\u0027147\u0027483\u0027648) we will have a mismatch when we\ncast it back to \u0027unsigned long\u0027. As the cached variable is of a signed\ntype, the compiler will choose a sign-extending instruction to load the 32\nbit variable into a 64 bit register (e.g.: \u0027lgf %r11,188(%r15)\u0027). So once\nwe pass the cached variable into \u0027zfcp_reqlist_find_rm()\u0027 to remove the\nrequest again all the leading zeros will be flipped to ones to extend the\nsign and won\u0027t match the original ID anymore (this has been observed in\npractice).\n\nIf we can\u0027t successfully remove the request from the hash table again after\n\u0027zfcp_qdio_send()\u0027 fails (this happens regularly when zfcp cannot notify\nthe adapter about new work because the adapter is already gone during\ne.g. a ChpID toggle) we will end up with a double free.  We unconditionally\nfree the request in the calling function when \u0027zfcp_fsf_req_send()\u0027 fails,\nbut because the request is still in the hash table we end up with a stale\nmemory reference, and once the zfcp adapter is either reset during recovery\nor shutdown we end up freeing the same memory twice.\n\nThe resulting stack traces vary depending on the kernel and have no direct\ncorrelation to the place where the bug occurs. Here are three examples that\nhave been seen in practice:\n\n  list_del corruption. next-\u003eprev should be 00000001b9d13800, but was 00000000dead4ead. (next=00000001bd131a00)\n  ------------[ cut here ]------------\n  kernel BUG at lib/list_debug.c:62!\n  monitor event: 0040 ilc:2 [#1] PREEMPT SMP\n  Modules linked in: ...\n  CPU: 9 PID: 1617 Comm: zfcperp0.0.1740 Kdump: loaded\n  Hardware name: ...\n  Krnl PSW : 0704d00180000000 00000003cbeea1f8 (__list_del_entry_valid+0x98/0x140)\n             R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3\n  Krnl GPRS: 00000000916d12f1 0000000080000000 000000000000006d 00000003cb665cd6\n             0000000000000001 0000000000000000 0000000000000000 00000000d28d21e8\n             00000000d3844000 00000380099efd28 00000001bd131a00 00000001b9d13800\n             00000000d3290100 0000000000000000 00000003cbeea1f4 00000380099efc70\n  Krnl Code: 00000003cbeea1e8: c020004f68a7        larl    %r2,00000003cc8d7336\n             00000003cbeea1ee: c0e50027fd65        brasl   %r14,00000003cc3e9cb8\n            #00000003cbeea1f4: af000000            mc      0,0\n            \u003e00000003cbeea1f8: c02000920440        larl    %r2,00000003cd12aa78\n             00000003cbeea1fe: c0e500289c25        brasl   %r14,00000003cc3fda48\n             00000003cbeea204: b9040043            lgr     %r4,%r3\n             00000003cbeea208: b9040051            lgr     %r5,%r1\n             00000003cbeea20c: b9040032            lgr     %r3,%r2\n  Call Trace:\n   [\u003c00000003cbeea1f8\u003e] __list_del_entry_valid+0x98/0x140\n  ([\u003c00000003cbeea1f4\u003e] __list_del_entry_valid+0x94/0x140)\n   [\u003c000003ff7ff502fe\u003e] zfcp_fsf_req_dismiss_all+0xde/0x150 [zfcp]\n   [\u003c000003ff7ff49cd0\u003e] zfcp_erp_strategy_do_action+0x160/0x280 [zfcp]\n---truncated---"
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-05-01T14:09:21.481Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/1bf8ed585501bb2dd0b5f67c824eab45adfbdccd"
        },
        {
          "url": "https://git.kernel.org/stable/c/d2c7d8f58e9cde8ac8d1f75e9d66c2a813ffe0ab"
        },
        {
          "url": "https://git.kernel.org/stable/c/11edbdee4399401f533adda9bffe94567aa08b96"
        },
        {
          "url": "https://git.kernel.org/stable/c/90a49a6b015fa439cd62e45121390284c125a91f"
        },
        {
          "url": "https://git.kernel.org/stable/c/0954256e970ecf371b03a6c9af2cf91b9c4085ff"
        }
      ],
      "title": "scsi: zfcp: Fix double free of FSF request when qdio send fails",
      "x_generator": {
        "engine": "bippy-1.1.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2022-49789",
    "datePublished": "2025-05-01T14:09:21.481Z",
    "dateReserved": "2025-05-01T14:05:17.224Z",
    "dateUpdated": "2025-05-01T14:09:21.481Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2022-49789\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-05-01T15:16:02.143\",\"lastModified\":\"2025-05-01T15:16:02.143\",\"vulnStatus\":\"Received\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nscsi: zfcp: Fix double free of FSF request when qdio send fails\\n\\nWe used to use the wrong type of integer in \u0027zfcp_fsf_req_send()\u0027 to cache\\nthe FSF request ID when sending a new FSF request. This is used in case the\\nsending fails and we need to remove the request from our internal hash\\ntable again (so we don\u0027t keep an invalid reference and use it when we free\\nthe request again).\\n\\nIn \u0027zfcp_fsf_req_send()\u0027 we used to cache the ID as \u0027int\u0027 (signed and 32\\nbit wide), but the rest of the zfcp code (and the firmware specification)\\nhandles the ID as \u0027unsigned long\u0027/\u0027u64\u0027 (unsigned and 64 bit wide [s390x\\nELF ABI]).  For one this has the obvious problem that when the ID grows\\npast 32 bit (this can happen reasonably fast) it is truncated to 32 bit\\nwhen storing it in the cache variable and so doesn\u0027t match the original ID\\nanymore.  The second less obvious problem is that even when the original ID\\nhas not yet grown past 32 bit, as soon as the 32nd bit is set in the\\noriginal ID (0x80000000 = 2\u0027147\u0027483\u0027648) we will have a mismatch when we\\ncast it back to \u0027unsigned long\u0027. As the cached variable is of a signed\\ntype, the compiler will choose a sign-extending instruction to load the 32\\nbit variable into a 64 bit register (e.g.: \u0027lgf %r11,188(%r15)\u0027). So once\\nwe pass the cached variable into \u0027zfcp_reqlist_find_rm()\u0027 to remove the\\nrequest again all the leading zeros will be flipped to ones to extend the\\nsign and won\u0027t match the original ID anymore (this has been observed in\\npractice).\\n\\nIf we can\u0027t successfully remove the request from the hash table again after\\n\u0027zfcp_qdio_send()\u0027 fails (this happens regularly when zfcp cannot notify\\nthe adapter about new work because the adapter is already gone during\\ne.g. a ChpID toggle) we will end up with a double free.  We unconditionally\\nfree the request in the calling function when \u0027zfcp_fsf_req_send()\u0027 fails,\\nbut because the request is still in the hash table we end up with a stale\\nmemory reference, and once the zfcp adapter is either reset during recovery\\nor shutdown we end up freeing the same memory twice.\\n\\nThe resulting stack traces vary depending on the kernel and have no direct\\ncorrelation to the place where the bug occurs. Here are three examples that\\nhave been seen in practice:\\n\\n  list_del corruption. next-\u003eprev should be 00000001b9d13800, but was 00000000dead4ead. (next=00000001bd131a00)\\n  ------------[ cut here ]------------\\n  kernel BUG at lib/list_debug.c:62!\\n  monitor event: 0040 ilc:2 [#1] PREEMPT SMP\\n  Modules linked in: ...\\n  CPU: 9 PID: 1617 Comm: zfcperp0.0.1740 Kdump: loaded\\n  Hardware name: ...\\n  Krnl PSW : 0704d00180000000 00000003cbeea1f8 (__list_del_entry_valid+0x98/0x140)\\n             R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3\\n  Krnl GPRS: 00000000916d12f1 0000000080000000 000000000000006d 00000003cb665cd6\\n             0000000000000001 0000000000000000 0000000000000000 00000000d28d21e8\\n             00000000d3844000 00000380099efd28 00000001bd131a00 00000001b9d13800\\n             00000000d3290100 0000000000000000 00000003cbeea1f4 00000380099efc70\\n  Krnl Code: 00000003cbeea1e8: c020004f68a7        larl    %r2,00000003cc8d7336\\n             00000003cbeea1ee: c0e50027fd65        brasl   %r14,00000003cc3e9cb8\\n            #00000003cbeea1f4: af000000            mc      0,0\\n            \u003e00000003cbeea1f8: c02000920440        larl    %r2,00000003cd12aa78\\n             00000003cbeea1fe: c0e500289c25        brasl   %r14,00000003cc3fda48\\n             00000003cbeea204: b9040043            lgr     %r4,%r3\\n             00000003cbeea208: b9040051            lgr     %r5,%r1\\n             00000003cbeea20c: b9040032            lgr     %r3,%r2\\n  Call Trace:\\n   [\u003c00000003cbeea1f8\u003e] __list_del_entry_valid+0x98/0x140\\n  ([\u003c00000003cbeea1f4\u003e] __list_del_entry_valid+0x94/0x140)\\n   [\u003c000003ff7ff502fe\u003e] zfcp_fsf_req_dismiss_all+0xde/0x150 [zfcp]\\n   [\u003c000003ff7ff49cd0\u003e] zfcp_erp_strategy_do_action+0x160/0x280 [zfcp]\\n---truncated---\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/0954256e970ecf371b03a6c9af2cf91b9c4085ff\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/11edbdee4399401f533adda9bffe94567aa08b96\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/1bf8ed585501bb2dd0b5f67c824eab45adfbdccd\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/90a49a6b015fa439cd62e45121390284c125a91f\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/d2c7d8f58e9cde8ac8d1f75e9d66c2a813ffe0ab\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}"
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading...

Loading...

Loading...
  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.