Vulnerability-Lookup

CVE-2022-49114 (GCVE-0-2022-49114)

Vulnerability from cvelistv5 – Published: 2025-02-26 01:54 – Updated: 2026-08-05 08:53

Title

scsi: libfc: Fix use after free in fc_exch_abts_resp()

Summary

In the Linux kernel, the following vulnerability has been resolved: scsi: libfc: Fix use after free in fc_exch_abts_resp() fc_exch_release(ep) will decrease the ep's reference count. When the reference count reaches zero, it is freed. But ep is still used in the following code, which will lead to a use after free. Return after the fc_exch_release() call to avoid use after free.

Severity

8.8 (High)


                        
                          CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

7.8 (High)


                        
                          CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

SSVC

Exploitation: none Automatable: no Technical Impact: total

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2025-03-04 18:03 UTC

CWE

CWE-416 - Use After Free

Assigner

Linux CNA under the mitre root

CNA scorecard D 53/100 over 6641 records in the last 180 days details

References

9 references

URL	Tags
https://git.kernel.org/stable/c/4a131d4ea8b581ac9…
https://git.kernel.org/stable/c/499d198494e77b653…
https://git.kernel.org/stable/c/6044ad64f41c87382…
https://git.kernel.org/stable/c/5cf2ce8967b0d98c8…
https://git.kernel.org/stable/c/1d7effe5fff9d28e4…
https://git.kernel.org/stable/c/f581df412bc45c951…
https://git.kernel.org/stable/c/87909291762d08fdb…
https://git.kernel.org/stable/c/412dd8299b02e4410…
https://git.kernel.org/stable/c/271add11994ba1a33…

Impacted products

2 products

Vendor	Product	Version	CPE status
Linux	Linux	Affected: 42e9a92fe6a9095bd68a379aaec7ad2be0337f7a , < 4a131d4ea8b581ac9b01d3a72754db4848be3232 (git) Affected: 42e9a92fe6a9095bd68a379aaec7ad2be0337f7a , < 499d198494e77b6533251b9b909baf5c101129cb (git) Affected: 42e9a92fe6a9095bd68a379aaec7ad2be0337f7a , < 6044ad64f41c87382cfeeca281573d1886d80cbe (git) Affected: 42e9a92fe6a9095bd68a379aaec7ad2be0337f7a , < 5cf2ce8967b0d98c8cfa4dc42ef4fcf080f5c836 (git) Affected: 42e9a92fe6a9095bd68a379aaec7ad2be0337f7a , < 1d7effe5fff9d28e45e18ac3a564067c7ddfe898 (git) Affected: 42e9a92fe6a9095bd68a379aaec7ad2be0337f7a , < f581df412bc45c95176e3c808ee2839c05b2ab0c (git) Affected: 42e9a92fe6a9095bd68a379aaec7ad2be0337f7a , < 87909291762d08fdb60d19069d7a89b5b308d0ef (git) Affected: 42e9a92fe6a9095bd68a379aaec7ad2be0337f7a , < 412dd8299b02e4410fe77b8396953c1a8dde183a (git) Affected: 42e9a92fe6a9095bd68a379aaec7ad2be0337f7a , < 271add11994ba1a334859069367e04d2be2ebdd4 (git)	guessed
Linux	Linux	Affected: 2.6.29 Unaffected: 0 , < 2.6.29 (semver) Unaffected: 4.9.311 , ≤ 4.9.* (semver) Unaffected: 4.14.276 , ≤ 4.14.* (semver) Unaffected: 4.19.238 , ≤ 4.19.* (semver) Unaffected: 5.4.189 , ≤ 5.4.* (semver) Unaffected: 5.10.111 , ≤ 5.10.* (semver) Unaffected: 5.15.34 , ≤ 5.15.* (semver) Unaffected: 5.16.20 , ≤ 5.16.* (semver) Unaffected: 5.17.3 , ≤ 5.17.* (semver) Unaffected: 5.18 , ≤ * (original_commit_for_fix)	guessed

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "cvssV3_1": {
              "attackComplexity": "LOW",
              "attackVector": "LOCAL",
              "availabilityImpact": "HIGH",
              "baseScore": 7.8,
              "baseSeverity": "HIGH",
              "confidentialityImpact": "HIGH",
              "integrityImpact": "HIGH",
              "privilegesRequired": "LOW",
              "scope": "UNCHANGED",
              "userInteraction": "NONE",
              "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
              "version": "3.1"
            }
          },
          {
            "other": {
              "content": {
                "id": "CVE-2022-49114",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2025-03-04T18:03:27.178498Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "problemTypes": [
          {
            "descriptions": [
              {
                "cweId": "CWE-416",
                "description": "CWE-416 Use After Free",
                "lang": "en",
                "type": "CWE"
              }
            ]
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2025-03-04T18:07:17.816Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/scsi/libfc/fc_exch.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "4a131d4ea8b581ac9b01d3a72754db4848be3232",
              "status": "affected",
              "version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
              "versionType": "git"
            },
            {
              "lessThan": "499d198494e77b6533251b9b909baf5c101129cb",
              "status": "affected",
              "version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
              "versionType": "git"
            },
            {
              "lessThan": "6044ad64f41c87382cfeeca281573d1886d80cbe",
              "status": "affected",
              "version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
              "versionType": "git"
            },
            {
              "lessThan": "5cf2ce8967b0d98c8cfa4dc42ef4fcf080f5c836",
              "status": "affected",
              "version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
              "versionType": "git"
            },
            {
              "lessThan": "1d7effe5fff9d28e45e18ac3a564067c7ddfe898",
              "status": "affected",
              "version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
              "versionType": "git"
            },
            {
              "lessThan": "f581df412bc45c95176e3c808ee2839c05b2ab0c",
              "status": "affected",
              "version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
              "versionType": "git"
            },
            {
              "lessThan": "87909291762d08fdb60d19069d7a89b5b308d0ef",
              "status": "affected",
              "version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
              "versionType": "git"
            },
            {
              "lessThan": "412dd8299b02e4410fe77b8396953c1a8dde183a",
              "status": "affected",
              "version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
              "versionType": "git"
            },
            {
              "lessThan": "271add11994ba1a334859069367e04d2be2ebdd4",
              "status": "affected",
              "version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/scsi/libfc/fc_exch.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "2.6.29"
            },
            {
              "lessThan": "2.6.29",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.9.*",
              "status": "unaffected",
              "version": "4.9.311",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.14.*",
              "status": "unaffected",
              "version": "4.14.276",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.19.*",
              "status": "unaffected",
              "version": "4.19.238",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.4.*",
              "status": "unaffected",
              "version": "5.4.189",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.10.*",
              "status": "unaffected",
              "version": "5.10.111",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.15.*",
              "status": "unaffected",
              "version": "5.15.34",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.16.*",
              "status": "unaffected",
              "version": "5.16.20",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.17.*",
              "status": "unaffected",
              "version": "5.17.3",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "5.18",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "4.9.311",
                  "versionStartIncluding": "2.6.29",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "4.14.276",
                  "versionStartIncluding": "2.6.29",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "4.19.238",
                  "versionStartIncluding": "2.6.29",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.4.189",
                  "versionStartIncluding": "2.6.29",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.10.111",
                  "versionStartIncluding": "2.6.29",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.15.34",
                  "versionStartIncluding": "2.6.29",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.16.20",
                  "versionStartIncluding": "2.6.29",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.17.3",
                  "versionStartIncluding": "2.6.29",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.18",
                  "versionStartIncluding": "2.6.29",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: libfc: Fix use after free in fc_exch_abts_resp()\n\nfc_exch_release(ep) will decrease the ep\u0027s reference count. When the\nreference count reaches zero, it is freed. But ep is still used in the\nfollowing code, which will lead to a use after free.\n\nReturn after the fc_exch_release() call to avoid use after free."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 8.8,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:A - The vulnerable path processes Fibre Channel BLS frames (BA_ACC/BA_RJT) received over an FC SAN fabric or FCoE (ETH_P_FCOE) L2 segment from a peer on the same fabric/VLAN, which is adjacent-network topology, not Internet-routable IP.\nAC:L - An adjacent peer can induce exchange timeouts (delaying responses) so the host sends ABTS with a pending timer, then deliver a crafted BA_ACC/BA_RJT while that timer is still queued, reliably hitting the cancel-and-release path.\nPR:N - fc_exch_recv and the FCoE/HBA receive path accept frames from fabric peers with no OS credential or capability check; fabric zoning only constrains topology, not authenticated privileges on this code path.\nUI:N - Exploitation is fully driven by attacker-sent FC/FCoE frames against an already-configured initiator; no separate victim action such as mounting a volume or confirming a prompt is required.\nS:U - The use-after-free corrupts host kernel exchange/slab state within the same OS security authority and does not cross a VM, IOMMU, or sandbox boundary.\nC:H - Use-after-free of heap-allocated struct fc_exch lets an attacker reclaim the object and obtain arbitrary kernel-memory read primitives, which per guidance is High confidentiality impact.\nI:H - struct fc_exch embeds callable resp and destructor function pointers invoked from this path, so UAF plus heap spray enables arbitrary write and control-flow hijacking.\nA:H - Use-after-free of the exchange object causes kernel oops/panic even when not fully exploited, which is High availability impact and can be retried by sending further ABTS responses."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-05T08:53:58.360Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/4a131d4ea8b581ac9b01d3a72754db4848be3232"
        },
        {
          "url": "https://git.kernel.org/stable/c/499d198494e77b6533251b9b909baf5c101129cb"
        },
        {
          "url": "https://git.kernel.org/stable/c/6044ad64f41c87382cfeeca281573d1886d80cbe"
        },
        {
          "url": "https://git.kernel.org/stable/c/5cf2ce8967b0d98c8cfa4dc42ef4fcf080f5c836"
        },
        {
          "url": "https://git.kernel.org/stable/c/1d7effe5fff9d28e45e18ac3a564067c7ddfe898"
        },
        {
          "url": "https://git.kernel.org/stable/c/f581df412bc45c95176e3c808ee2839c05b2ab0c"
        },
        {
          "url": "https://git.kernel.org/stable/c/87909291762d08fdb60d19069d7a89b5b308d0ef"
        },
        {
          "url": "https://git.kernel.org/stable/c/412dd8299b02e4410fe77b8396953c1a8dde183a"
        },
        {
          "url": "https://git.kernel.org/stable/c/271add11994ba1a334859069367e04d2be2ebdd4"
        }
      ],
      "title": "scsi: libfc: Fix use after free in fc_exch_abts_resp()",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2022-49114",
    "datePublished": "2025-02-26T01:54:58.172Z",
    "dateReserved": "2025-02-26T01:49:39.262Z",
    "dateUpdated": "2026-08-05T08:53:58.360Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2022-49114",
      "date": "2026-11-14",
      "epss": "0.00357",
      "percentile": "0.29945"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "defaultStatus": "unaffected",
                "product": "Linux",
                "programFiles": [
                  "drivers/scsi/libfc/fc_exch.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "lessThan": "4a131d4ea8b581ac9b01d3a72754db4848be3232",
                    "status": "affected",
                    "version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "499d198494e77b6533251b9b909baf5c101129cb",
                    "status": "affected",
                    "version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "6044ad64f41c87382cfeeca281573d1886d80cbe",
                    "status": "affected",
                    "version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "5cf2ce8967b0d98c8cfa4dc42ef4fcf080f5c836",
                    "status": "affected",
                    "version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "1d7effe5fff9d28e45e18ac3a564067c7ddfe898",
                    "status": "affected",
                    "version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "f581df412bc45c95176e3c808ee2839c05b2ab0c",
                    "status": "affected",
                    "version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "87909291762d08fdb60d19069d7a89b5b308d0ef",
                    "status": "affected",
                    "version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "412dd8299b02e4410fe77b8396953c1a8dde183a",
                    "status": "affected",
                    "version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "271add11994ba1a334859069367e04d2be2ebdd4",
                    "status": "affected",
                    "version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
                    "versionType": "git"
                  }
                ]
              },
              {
                "defaultStatus": "affected",
                "product": "Linux",
                "programFiles": [
                  "drivers/scsi/libfc/fc_exch.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "status": "affected",
                    "version": "2.6.29"
                  },
                  {
                    "lessThan": "2.6.29",
                    "status": "unaffected",
                    "version": "0",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "4.9.*",
                    "status": "unaffected",
                    "version": "4.9.311",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "4.14.*",
                    "status": "unaffected",
                    "version": "4.14.276",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "4.19.*",
                    "status": "unaffected",
                    "version": "4.19.238",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "5.4.*",
                    "status": "unaffected",
                    "version": "5.4.189",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "5.10.*",
                    "status": "unaffected",
                    "version": "5.10.111",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "5.15.*",
                    "status": "unaffected",
                    "version": "5.15.34",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "5.16.*",
                    "status": "unaffected",
                    "version": "5.16.20",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "5.17.*",
                    "status": "unaffected",
                    "version": "5.17.3",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "*",
                    "status": "unaffected",
                    "version": "5.18",
                    "versionType": "original_commit_for_fix"
                  }
                ]
              }
            ],
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
          }
        ],
        "configurations": [
          {
            "nodes": [
              {
                "cpeMatch": [
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "C86EFD13-93D4-4385-83E8-C665BE8F570F",
                    "versionEndExcluding": "4.9.311",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "6D9B028C-6313-47F9-94B7-5F8122345E49",
                    "versionEndExcluding": "4.14.276",
                    "versionStartIncluding": "4.10",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "FA28527A-11D3-41D2-9C4C-ECAC0D6A4A2D",
                    "versionEndExcluding": "4.19.238",
                    "versionStartIncluding": "4.15",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "8CB6E8F5-C2B1-46F3-A807-0F6104AC340F",
                    "versionEndExcluding": "5.4.189",
                    "versionStartIncluding": "4.20",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "96258501-7BCE-4C55-8A38-8AC9D327626D",
                    "versionEndExcluding": "5.10.111",
                    "versionStartIncluding": "5.5",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "D25878D3-7761-4E9F-8919-E92CD53896E0",
                    "versionEndExcluding": "5.15.34",
                    "versionStartIncluding": "5.11",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "ABBBA66E-0244-4621-966B-9790AF1EEB00",
                    "versionEndExcluding": "5.16.20",
                    "versionStartIncluding": "5.16",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "AE420AC7-1E59-4398-B84F-71F4B4337762",
                    "versionEndExcluding": "5.17.3",
                    "versionStartIncluding": "5.17",
                    "vulnerable": true
                  }
                ],
                "negate": false,
                "operator": "OR"
              }
            ]
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: libfc: Fix use after free in fc_exch_abts_resp()\n\nfc_exch_release(ep) will decrease the ep\u0027s reference count. When the\nreference count reaches zero, it is freed. But ep is still used in the\nfollowing code, which will lead to a use after free.\n\nReturn after the fc_exch_release() call to avoid use after free."
          },
          {
            "lang": "es",
            "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: libfc: Se corrige el use-after-free en fc_exch_abts_resp() fc_exch_release(ep) reducir\u00e1 el recuento de referencias de ep. Cuando el recuento de referencias llega a cero, se libera. Pero ep todav\u00eda se usa en el siguiente c\u00f3digo, lo que provocar\u00e1 un use-after-free. Regrese despu\u00e9s de la llamada fc_exch_release() para evitar el use-after-free."
          }
        ],
        "id": "CVE-2022-49114",
        "lastModified": "2026-08-04T10:17:35.540",
        "metrics": {
          "cvssMetricV31": [
            {
              "cvssData": {
                "attackComplexity": "LOW",
                "attackVector": "ADJACENT_NETWORK",
                "availabilityImpact": "HIGH",
                "baseScore": 8.8,
                "baseSeverity": "HIGH",
                "confidentialityImpact": "HIGH",
                "integrityImpact": "HIGH",
                "privilegesRequired": "NONE",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
                "version": "3.1"
              },
              "exploitabilityScore": 2.8,
              "impactScore": 5.9,
              "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
              "type": "Secondary"
            },
            {
              "cvssData": {
                "attackComplexity": "LOW",
                "attackVector": "LOCAL",
                "availabilityImpact": "HIGH",
                "baseScore": 7.8,
                "baseSeverity": "HIGH",
                "confidentialityImpact": "HIGH",
                "integrityImpact": "HIGH",
                "privilegesRequired": "LOW",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
                "version": "3.1"
              },
              "exploitabilityScore": 1.8,
              "impactScore": 5.9,
              "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "type": "Secondary"
            }
          ],
          "ssvcV203": [
            {
              "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "ssvcData": {
                "id": "CVE-2022-49114",
                "options": [
                  {
                    "exploitation": "none"
                  },
                  {
                    "automatable": "no"
                  },
                  {
                    "technicalImpact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2025-03-04T18:03:27.178498Z",
                "version": "2.0.3"
              }
            }
          ]
        },
        "published": "2025-02-26T07:00:48.773",
        "references": [
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/1d7effe5fff9d28e45e18ac3a564067c7ddfe898"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/271add11994ba1a334859069367e04d2be2ebdd4"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/412dd8299b02e4410fe77b8396953c1a8dde183a"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/499d198494e77b6533251b9b909baf5c101129cb"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/4a131d4ea8b581ac9b01d3a72754db4848be3232"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/5cf2ce8967b0d98c8cfa4dc42ef4fcf080f5c836"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/6044ad64f41c87382cfeeca281573d1886d80cbe"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/87909291762d08fdb60d19069d7a89b5b308d0ef"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/f581df412bc45c95176e3c808ee2839c05b2ab0c"
          }
        ],
        "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "vulnStatus": "Modified",
        "weaknesses": [
          {
            "description": [
              {
                "lang": "en",
                "value": "CWE-416"
              }
            ],
            "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
            "type": "Secondary"
          }
        ]
      }
    },
    "redhat_vex": {
      "aggregate_severity": "Moderate",
      "current_release_date": "2026-11-09T17:18:47+00:00",
      "cve": "CVE-2022-49114",
      "id": "CVE-2022-49114",
      "initial_release_date": "2022-01-01T00:00:00+00:00",
      "product_status:fixed": "681",
      "product_status:known_affected": "80",
      "product_status:known_not_affected": "1",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: scsi: libfc: Fix use after free in fc_exch_abts_resp()",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2022/cve-2022-49114.json",
      "version": "3"
    },
    "vulnrichment": {
      "containers": {
        "adp": [
          {
            "metrics": [
              {
                "cvssV3_1": {
                  "attackComplexity": "LOW",
                  "attackVector": "LOCAL",
                  "availabilityImpact": "HIGH",
                  "baseScore": 7.8,
                  "baseSeverity": "HIGH",
                  "confidentialityImpact": "HIGH",
                  "integrityImpact": "HIGH",
                  "privilegesRequired": "LOW",
                  "scope": "UNCHANGED",
                  "userInteraction": "NONE",
                  "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
                  "version": "3.1"
                }
              },
              {
                "other": {
                  "content": {
                    "id": "CVE-2022-49114",
                    "options": [
                      {
                        "Exploitation": "none"
                      },
                      {
                        "Automatable": "no"
                      },
                      {
                        "Technical Impact": "total"
                      }
                    ],
                    "role": "CISA Coordinator",
                    "timestamp": "2025-03-04T18:03:27.178498Z",
                    "version": "2.0.3"
                  },
                  "type": "ssvc"
                }
              }
            ],
            "problemTypes": [
              {
                "descriptions": [
                  {
                    "cweId": "CWE-416",
                    "description": "CWE-416 Use After Free",
                    "lang": "en",
                    "type": "CWE"
                  }
                ]
              }
            ],
            "providerMetadata": {
              "dateUpdated": "2025-03-04T18:03:28.399Z",
              "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "shortName": "CISA-ADP"
            },
            "title": "CISA ADP Vulnrichment"
          }
        ],
        "cna": {
          "affected": [
            {
              "defaultStatus": "unaffected",
              "product": "Linux",
              "programFiles": [
                "drivers/scsi/libfc/fc_exch.c"
              ],
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "vendor": "Linux",
              "versions": [
                {
                  "lessThan": "4a131d4ea8b581ac9b01d3a72754db4848be3232",
                  "status": "affected",
                  "version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
                  "versionType": "git"
                },
                {
                  "lessThan": "499d198494e77b6533251b9b909baf5c101129cb",
                  "status": "affected",
                  "version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
                  "versionType": "git"
                },
                {
                  "lessThan": "6044ad64f41c87382cfeeca281573d1886d80cbe",
                  "status": "affected",
                  "version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
                  "versionType": "git"
                },
                {
                  "lessThan": "5cf2ce8967b0d98c8cfa4dc42ef4fcf080f5c836",
                  "status": "affected",
                  "version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
                  "versionType": "git"
                },
                {
                  "lessThan": "1d7effe5fff9d28e45e18ac3a564067c7ddfe898",
                  "status": "affected",
                  "version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
                  "versionType": "git"
                },
                {
                  "lessThan": "f581df412bc45c95176e3c808ee2839c05b2ab0c",
                  "status": "affected",
                  "version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
                  "versionType": "git"
                },
                {
                  "lessThan": "87909291762d08fdb60d19069d7a89b5b308d0ef",
                  "status": "affected",
                  "version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
                  "versionType": "git"
                },
                {
                  "lessThan": "412dd8299b02e4410fe77b8396953c1a8dde183a",
                  "status": "affected",
                  "version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
                  "versionType": "git"
                },
                {
                  "lessThan": "271add11994ba1a334859069367e04d2be2ebdd4",
                  "status": "affected",
                  "version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
                  "versionType": "git"
                }
              ]
            },
            {
              "defaultStatus": "affected",
              "product": "Linux",
              "programFiles": [
                "drivers/scsi/libfc/fc_exch.c"
              ],
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "vendor": "Linux",
              "versions": [
                {
                  "status": "affected",
                  "version": "2.6.29"
                },
                {
                  "lessThan": "2.6.29",
                  "status": "unaffected",
                  "version": "0",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "4.9.*",
                  "status": "unaffected",
                  "version": "4.9.311",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "4.14.*",
                  "status": "unaffected",
                  "version": "4.14.276",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "4.19.*",
                  "status": "unaffected",
                  "version": "4.19.238",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "5.4.*",
                  "status": "unaffected",
                  "version": "5.4.189",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "5.10.*",
                  "status": "unaffected",
                  "version": "5.10.111",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "5.15.*",
                  "status": "unaffected",
                  "version": "5.15.34",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "5.16.*",
                  "status": "unaffected",
                  "version": "5.16.20",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "5.17.*",
                  "status": "unaffected",
                  "version": "5.17.3",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "*",
                  "status": "unaffected",
                  "version": "5.18",
                  "versionType": "original_commit_for_fix"
                }
              ]
            }
          ],
          "cpeApplicability": [
            {
              "nodes": [
                {
                  "cpeMatch": [
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "4.9.311",
                      "versionStartIncluding": "2.6.29",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "4.14.276",
                      "versionStartIncluding": "2.6.29",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "4.19.238",
                      "versionStartIncluding": "2.6.29",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "5.4.189",
                      "versionStartIncluding": "2.6.29",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "5.10.111",
                      "versionStartIncluding": "2.6.29",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "5.15.34",
                      "versionStartIncluding": "2.6.29",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "5.16.20",
                      "versionStartIncluding": "2.6.29",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "5.17.3",
                      "versionStartIncluding": "2.6.29",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "5.18",
                      "versionStartIncluding": "2.6.29",
                      "vulnerable": true
                    }
                  ],
                  "negate": false,
                  "operator": "OR"
                }
              ]
            }
          ],
          "descriptions": [
            {
              "lang": "en",
              "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: libfc: Fix use after free in fc_exch_abts_resp()\n\nfc_exch_release(ep) will decrease the ep\u0027s reference count. When the\nreference count reaches zero, it is freed. But ep is still used in the\nfollowing code, which will lead to a use after free.\n\nReturn after the fc_exch_release() call to avoid use after free."
            }
          ],
          "metrics": [
            {
              "cvssV3_1": {
                "baseScore": 8.8,
                "baseSeverity": "HIGH",
                "vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
                "version": "3.1"
              },
              "scenarios": [
                {
                  "lang": "en",
                  "value": "AV:A - The vulnerable path processes Fibre Channel BLS frames (BA_ACC/BA_RJT) received over an FC SAN fabric or FCoE (ETH_P_FCOE) L2 segment from a peer on the same fabric/VLAN, which is adjacent-network topology, not Internet-routable IP.\nAC:L - An adjacent peer can induce exchange timeouts (delaying responses) so the host sends ABTS with a pending timer, then deliver a crafted BA_ACC/BA_RJT while that timer is still queued, reliably hitting the cancel-and-release path.\nPR:N - fc_exch_recv and the FCoE/HBA receive path accept frames from fabric peers with no OS credential or capability check; fabric zoning only constrains topology, not authenticated privileges on this code path.\nUI:N - Exploitation is fully driven by attacker-sent FC/FCoE frames against an already-configured initiator; no separate victim action such as mounting a volume or confirming a prompt is required.\nS:U - The use-after-free corrupts host kernel exchange/slab state within the same OS security authority and does not cross a VM, IOMMU, or sandbox boundary.\nC:H - Use-after-free of heap-allocated struct fc_exch lets an attacker reclaim the object and obtain arbitrary kernel-memory read primitives, which per guidance is High confidentiality impact.\nI:H - struct fc_exch embeds callable resp and destructor function pointers invoked from this path, so UAF plus heap spray enables arbitrary write and control-flow hijacking.\nA:H - Use-after-free of the exchange object causes kernel oops/panic even when not fully exploited, which is High availability impact and can be retried by sending further ABTS responses."
                }
              ]
            }
          ],
          "providerMetadata": {
            "dateUpdated": "2026-08-05T08:53:58.360Z",
            "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "shortName": "Linux"
          },
          "references": [
            {
              "url": "https://git.kernel.org/stable/c/4a131d4ea8b581ac9b01d3a72754db4848be3232"
            },
            {
              "url": "https://git.kernel.org/stable/c/499d198494e77b6533251b9b909baf5c101129cb"
            },
            {
              "url": "https://git.kernel.org/stable/c/6044ad64f41c87382cfeeca281573d1886d80cbe"
            },
            {
              "url": "https://git.kernel.org/stable/c/5cf2ce8967b0d98c8cfa4dc42ef4fcf080f5c836"
            },
            {
              "url": "https://git.kernel.org/stable/c/1d7effe5fff9d28e45e18ac3a564067c7ddfe898"
            },
            {
              "url": "https://git.kernel.org/stable/c/f581df412bc45c95176e3c808ee2839c05b2ab0c"
            },
            {
              "url": "https://git.kernel.org/stable/c/87909291762d08fdb60d19069d7a89b5b308d0ef"
            },
            {
              "url": "https://git.kernel.org/stable/c/412dd8299b02e4410fe77b8396953c1a8dde183a"
            },
            {
              "url": "https://git.kernel.org/stable/c/271add11994ba1a334859069367e04d2be2ebdd4"
            }
          ],
          "title": "scsi: libfc: Fix use after free in fc_exch_abts_resp()",
          "x_generator": {
            "engine": "bippy-1.2.0"
          }
        }
      },
      "cveMetadata": {
        "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "assignerShortName": "Linux",
        "cveId": "CVE-2022-49114",
        "datePublished": "2025-02-26T01:54:58.172Z",
        "dateReserved": "2025-02-26T01:49:39.262Z",
        "dateUpdated": "2026-08-05T08:53:58.360Z",
        "state": "PUBLISHED"
      },
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}

OESA-2025-1282 (CVE-2021-47631)

Vulnerability from osv_openeuler – Published: 2025-03-14 11:08 – Updated: 2026-08-06 11:08 – Source website

Summary

kernel security update

Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

ARM: davinci: da850-evm: Avoid NULL pointer dereference

With newer versions of GCC, there is a panic in da850_evm_config_emac() when booting multi_v5_defconfig in QEMU under the palmetto-bmc machine:

Unable to handle kernel NULL pointer dereference at virtual address 00000020 pgd = (ptrval) [00000020] *pgd=00000000 Internal error: Oops: 5 [#1] PREEMPT ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 5.15.0 #1 Hardware name: Generic DT based system PC is at da850_evm_config_emac+0x1c/0x120 LR is at do_one_initcall+0x50/0x1e0

The emac_pdata pointer in soc_info is NULL because davinci_soc_info only gets populated on davinci machines but da850_evm_config_emac() is called on all machines via device_initcall().

Move the rmii_en assignment below the machine check so that it is only dereferenced when running on a supported SoC.(CVE-2021-47631)

In the Linux kernel, the following vulnerability has been resolved:

video: fbdev: nvidiafb: Use strscpy() to prevent buffer overflow

Coverity complains of a possible buffer overflow. However, given the 'static' scope of nvidia_setup_i2c_bus() it looks like that can't happen after examiniing the call sites.

CID 19036 (#1 of 1): Copy into fixed size buffer (STRING_OVERFLOW) 1. fixed_size_dest: You might overrun the 48-character fixed-size string chan->adapter.name by copying name without checking the length. 2. parameter_as_source: Note: This defect has an elevated risk because the source argument is a parameter of the current function. 89 strcpy(chan->adapter.name, name);

Fix this warning by using strscpy() which will silence the warning and prevent any future buffer overflows should the names used to identify the channel become much longer.(CVE-2021-47642)

In the Linux kernel, the following vulnerability has been resolved:

dm integrity: fix memory corruption when tag_size is less than digest size

It is possible to set up dm-integrity in such a way that the "tag_size" parameter is less than the actual digest size. In this situation, a part of the digest beyond tag_size is ignored.

In this case, dm-integrity would write beyond the end of the ic->recalc_tags array and corrupt memory. The corruption happened in integrity_recalc->integrity_sector_checksum->crypto_shash_final.

Fix this corruption by increasing the tags array so that it has enough padding at the end to accomodate the loop in integrity_recalc() being able to write a full digest size for the last member of the tags array.(CVE-2022-49044)

In the Linux kernel, the following vulnerability has been resolved:

drm/amdkfd: Check for potential null return of kmalloc_array()

As the kmalloc_array() may return null, the 'event_waiters[i].wait' would lead to null-pointer dereference. Therefore, it is better to check the return value of kmalloc_array() to avoid this confusion.(CVE-2022-49055)

In the Linux kernel, the following vulnerability has been resolved:

scsi: libfc: Fix use after free in fc_exch_abts_resp()

fc_exch_release(ep) will decrease the ep's reference count. When the reference count reaches zero, it is freed. But ep is still used in the following code, which will lead to a use after free.

Return after the fc_exch_release() call to avoid use after free.(CVE-2022-49114)

In the Linux kernel, the following vulnerability has been resolved:

drm/amd/amdgpu/amdgpu_cs: fix refcount leak of a dma_fence obj

This issue takes place in an error path in amdgpu_cs_fence_to_handle_ioctl(). When info->in.what falls into default case, the function simply returns -EINVAL, forgetting to decrement the reference count of a dma_fence obj, which is bumped earlier by amdgpu_cs_get_fence(). This may result in reference count leaks.

Fix it by decreasing the refcount of specific object before returning the error code.(CVE-2022-49137)

In the Linux kernel, the following vulnerability has been resolved:

media: usb: go7007: s2250-board: fix leak in probe()

Call i2c_unregister_device(audio) on this error path.(CVE-2022-49253)

In the Linux kernel, the following vulnerability has been resolved:

extcon: Modify extcon device to be created after driver data is set

Currently, someone can invoke the sysfs such as state_show() intermittently before dev_set_drvdata() is done. And it can be a cause of kernel Oops because of edev is Null at that time. So modified the driver registration to after setting drviver data.

Oops's backtrace.

Backtrace: [<c067865c>] (state_show) from [<c05222e8>] (dev_attr_show) [<c05222c0>] (dev_attr_show) from [<c02c66e0>] (sysfs_kf_seq_show) [<c02c6648>] (sysfs_kf_seq_show) from [<c02c496c>] (kernfs_seq_show) [<c02c4938>] (kernfs_seq_show) from [<c025e2a0>] (seq_read) [<c025e11c>] (seq_read) from [<c02c50a0>] (kernfs_fop_read) [<c02c5064>] (kernfs_fop_read) from [<c0231cac>] (__vfs_read) [<c0231c5c>] (__vfs_read) from [<c0231ee0>] (vfs_read) [<c0231e34>] (vfs_read) from [<c0232464>] (ksys_read) [<c02323f0>] (ksys_read) from [<c02324fc>] (sys_read) [<c02324e4>] (sys_read) from [<c00091d0>] (__sys_trace_return)(CVE-2022-49308)

In the Linux kernel, the following vulnerability has been resolved:

rtl818x: Prevent using not initialized queues

Using not existing queues can panic the kernel with rtl8180/rtl8185 cards. Ignore the skb priority for those cards, they only have one tx queue. Pierre Asselin (pa@panix.com) reported the kernel crash in the Gentoo forum:

https://forums.gentoo.org/viewtopic-t-1147832-postdays-0-postorder-asc-start-25.html

He also confirmed that this patch fixes the issue. In summary this happened:

After updating wpa_supplicant from 2.9 to 2.10 the kernel crashed with a "divide error: 0000" when connecting to an AP. Control port tx now tries to use IEEE80211_AC_VO for the priority, which wpa_supplicants starts to use in 2.10.

Since only the rtl8187se part of the driver supports QoS, the priority of the skb is set to IEEE80211_AC_BE (2) by mac80211 for rtl8180/rtl8185 cards.

rtl8180 is then unconditionally reading out the priority and finally crashes on drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c line 544 without this patch: idx = (ring->idx + skb_queue_len(&ring->queue)) % ring->entries

"ring->entries" is zero for rtl8180/rtl8185 cards, tx_ring[2] never got initialized.(CVE-2022-49326)

In the Linux kernel, the following vulnerability has been resolved:

bpf, arm64: Clear prog->jited_len along prog->jited

syzbot reported an illegal copy_to_user() attempt from bpf_prog_get_info_by_fd() [1]

There was no repro yet on this bug, but I think that commit 0aef499f3172 ("mm/usercopy: Detect vmalloc overruns") is exposing a prior bug in bpf arm64.

bpf_prog_get_info_by_fd() looks at prog->jited_len to determine if the JIT image can be copied out to user space.

My theory is that syzbot managed to get a prog where prog->jited_len has been set to 43, while prog->bpf_func has ben cleared.

It is not clear why copy_to_user(uinsns, NULL, ulen) is triggering this particular warning.

I thought find_vma_area(NULL) would not find a vm_struct. As we do not hold vmap_area_lock spinlock, it might be possible that the found vm_struct was garbage.

[1] usercopy: Kernel memory exposure attempt detected from vmalloc (offset 792633534417210172, size 43)! kernel BUG at mm/usercopy.c:101! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 25002 Comm: syz-executor.1 Not tainted 5.18.0-syzkaller-10139-g8291eaafed36 #0 Hardware name: linux,dummy-virt (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usercopy_abort+0x90/0x94 mm/usercopy.c:101 lr : usercopy_abort+0x90/0x94 mm/usercopy.c:89 sp : ffff80000b773a20 x29: ffff80000b773a30 x28: faff80000b745000 x27: ffff80000b773b48 x26: 0000000000000000 x25: 000000000000002b x24: 0000000000000000 x23: 00000000000000e0 x22: ffff80000b75db67 x21: 0000000000000001 x20: 000000000000002b x19: ffff80000b75db3c x18: 00000000fffffffd x17: 2820636f6c6c616d x16: 76206d6f72662064 x15: 6574636574656420 x14: 74706d6574746120 x13: 2129333420657a69 x12: 73202c3237313031 x11: 3237313434333533 x10: 3336323937207465 x9 : 657275736f707865 x8 : ffff80000a30c550 x7 : ffff80000b773830 x6 : ffff80000b773830 x5 : 0000000000000000 x4 : ffff00007fbbaa10 x3 : 0000000000000000 x2 : 0000000000000000 x1 : f7ff000028fc0000 x0 : 0000000000000064 Call trace: usercopy_abort+0x90/0x94 mm/usercopy.c:89 check_heap_object mm/usercopy.c:186 [inline] __check_object_size mm/usercopy.c:252 [inline] __check_object_size+0x198/0x36c mm/usercopy.c:214 check_object_size include/linux/thread_info.h:199 [inline] check_copy_size include/linux/thread_info.h:235 [inline] copy_to_user include/linux/uaccess.h:159 [inline] bpf_prog_get_info_by_fd.isra.0+0xf14/0xfdc kernel/bpf/syscall.c:3993 bpf_obj_get_info_by_fd+0x12c/0x510 kernel/bpf/syscall.c:4253 __sys_bpf+0x900/0x2150 kernel/bpf/syscall.c:4956 __do_sys_bpf kernel/bpf/syscall.c:5021 [inline] __se_sys_bpf kernel/bpf/syscall.c:5019 [inline] __arm64_sys_bpf+0x28/0x40 kernel/bpf/syscall.c:5019 __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline] invoke_syscall+0x48/0x114 arch/arm64/kernel/syscall.c:52 el0_svc_common.constprop.0+0x44/0xec arch/arm64/kernel/syscall.c:142 do_el0_svc+0xa0/0xc0 arch/arm64/kernel/syscall.c:206 el0_svc+0x44/0xb0 arch/arm64/kernel/entry-common.c:624 el0t_64_sync_handler+0x1ac/0x1b0 arch/arm64/kernel/entry-common.c:642 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:581 Code: aa0003e3 d00038c0 91248000 97fff65f (d4210000)(CVE-2022-49341)

In the Linux kernel, the following vulnerability has been resolved:

net: altera: Fix refcount leak in altera_tse_mdio_create

Every iteration of for_each_child_of_node() decrements the reference count of the previous node. When break from a for_each_child_of_node() loop, we need to explicitly call of_node_put() on the child node when not need anymore. Add missing of_node_put() to avoid refcount leak.(CVE-2022-49351)

In the Linux kernel, the following vulnerability has been resolved:

RDMA/hfi1: Fix potential integer multiplication overflow errors

When multiplying of different types, an overflow is possible even when storing the result in a larger type. This is because the conversion is done after the multiplication. So arithmetic overflow and thus in incorrect value is possible.

Correct an instance of this in the inter packet delay calculation. Fix by ensuring one of the operands is u64 which will promote the other to u64 as well ensuring no overflow.(CVE-2022-49404)

In the Linux kernel, the following vulnerability has been resolved:

RDMA/hfi1: Prevent use of lock before it is initialized

If there is a failure during probe of hfi1 before the sdma_map_lock is initialized, the call to hfi1_free_devdata() will attempt to use a lock that has not been initialized. If the locking correctness validator is on then an INFO message and stack trace resembling the following may be seen:

INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. Call Trace: register_lock_class+0x11b/0x880 __lock_acquire+0xf3/0x7930 lock_acquire+0xff/0x2d0 _raw_spin_lock_irq+0x46/0x60 sdma_clean+0x42a/0x660 [hfi1] hfi1_free_devdata+0x3a7/0x420 [hfi1] init_one+0x867/0x11a0 [hfi1] pci_device_probe+0x40e/0x8d0

The use of sdma_map_lock in sdma_clean() is for freeing the sdma_map memory, and sdma_map is not allocated/initialized until after sdma_map_lock has been initialized. This code only needs to be run if sdma_map is not NULL, and so checking for that condition will avoid trying to use the lock before it is initialized.(CVE-2022-49433)

In the Linux kernel, the following vulnerability has been resolved:

powerpc/fsl_rio: Fix refcount leak in fsl_rio_setup

of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.(CVE-2022-49439)

In the Linux kernel, the following vulnerability has been resolved:

ARM: hisi: Add missing of_node_put after of_find_compatible_node

of_find_compatible_node will increment the refcount of the returned device_node. Calling of_node_put() to avoid the refcount leak(CVE-2022-49447)

In the Linux kernel, the following vulnerability has been resolved:

md/bitmap: don't set sb values if can't pass sanity check

If bitmap area contains invalid data, kernel will crash then mdadm triggers "Segmentation fault". This is cluster-md speical bug. In non-clustered env, mdadm will handle broken metadata case. In clustered array, only kernel space handles bitmap slot info. But even this bug only happened in clustered env, current sanity check is wrong, the code should be changed.

How to trigger: (faulty injection)

dd if=/dev/zero bs=1M count=1 oflag=direct of=/dev/sda dd if=/dev/zero bs=1M count=1 oflag=direct of=/dev/sdb mdadm -C /dev/md0 -b clustered -e 1.2 -n 2 -l mirror /dev/sda /dev/sdb mdadm -Ss echo aaa > magic.txt == below modifying slot 2 bitmap data == dd if=magic.txt of=/dev/sda seek=16384 bs=1 count=3 <== destroy magic dd if=/dev/zero of=/dev/sda seek=16436 bs=1 count=4 <== ZERO chunksize mdadm -A /dev/md0 /dev/sda /dev/sdb == kernel crashes. mdadm outputs "Segmentation fault" ==

Reason of kernel crash:

In md_bitmap_read_sb (called by md_bitmap_create), bad bitmap magic didn't block chunksize assignment, and zero value made DIV_ROUND_UP_SECTOR_T() trigger "divide error".

Crash log:

kernel: md: md0 stopped. kernel: md/raid1:md0: not clean -- starting background reconstruction kernel: md/raid1:md0: active with 2 out of 2 mirrors kernel: dlm: ... ... kernel: md-cluster: Joined cluster 44810aba-38bb-e6b8-daca-bc97a0b254aa slot 1 kernel: md0: invalid bitmap file superblock: bad magic kernel: md_bitmap_copy_from_slot can't get bitmap from slot 2 kernel: md-cluster: Could not gather bitmaps from slot 2 kernel: divide error: 0000 [#1] SMP NOPTI kernel: CPU: 0 PID: 1603 Comm: mdadm Not tainted 5.14.6-1-default kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) kernel: RIP: 0010:md_bitmap_create+0x1d1/0x850 [md_mod] kernel: RSP: 0018:ffffc22ac0843ba0 EFLAGS: 00010246 kernel: ... ... kernel: Call Trace: kernel: ? dlm_lock_sync+0xd0/0xd0 [md_cluster 77fe..7a0] kernel: md_bitmap_copy_from_slot+0x2c/0x290 [md_mod 24ea..d3a] kernel: load_bitmaps+0xec/0x210 [md_cluster 77fe..7a0] kernel: md_bitmap_load+0x81/0x1e0 [md_mod 24ea..d3a] kernel: do_md_run+0x30/0x100 [md_mod 24ea..d3a] kernel: md_ioctl+0x1290/0x15a0 [md_mod 24ea....d3a] kernel: ? mddev_unlock+0xaa/0x130 [md_mod 24ea..d3a] kernel: ? blkdev_ioctl+0xb1/0x2b0 kernel: block_ioctl+0x3b/0x40 kernel: __x64_sys_ioctl+0x7f/0xb0 kernel: do_syscall_64+0x59/0x80 kernel: ? exit_to_user_mode_prepare+0x1ab/0x230 kernel: ? syscall_exit_to_user_mode+0x18/0x40 kernel: ? do_syscall_64+0x69/0x80 kernel: entry_SYSCALL_64_after_hwframe+0x44/0xae kernel: RIP: 0033:0x7f4a15fa722b kernel: ... ... kernel: ---[ end trace 8afa7612f559c868 ]--- kernel: RIP: 0010:md_bitmap_create+0x1d1/0x850 md_mod

In the Linux kernel, the following vulnerability has been resolved:

crypto: qat - add param check for DH

Reject requests with a source buffer that is bigger than the size of the key. This is to prevent a possible integer underflow that might happen when copying the source scatterlist into a linear buffer.(CVE-2022-49564)

In the Linux kernel, the following vulnerability has been resolved:

net: tipc: fix possible refcount leak in tipc_sk_create()

Free sk in case tipc_sk_insert() fails.(CVE-2022-49620)

In the Linux kernel, the following vulnerability has been resolved:

tracing/histograms: Fix memory leak problem

This reverts commit 46bbe5c671e06f070428b9be142cc4ee5cedebac.

As commit 46bbe5c671e0 ("tracing: fix double free") said, the "double free" problem reported by clang static analyzer is: > In parse_var_defs() if there is a problem allocating > var_defs.expr, the earlier var_defs.name is freed. > This free is duplicated by free_var_defs() which frees > the rest of the list.

However, if there is a problem allocating N-th var_defs.expr: + in parse_var_defs(), the freed 'earlier var_defs.name' is actually the N-th var_defs.name; + then in free_var_defs(), the names from 0th to (N-1)-th are freed;

                    IF ALLOCATING PROBLEM HAPPENED HERE!!! -+
                                                             \
                                                              |
      0th           1th                 (N-1)-th      N-th    V
      +-------------+-------------+-----+-------------+-----------

These two frees don't act on same name, so there was no "double free" problem before. Conversely, after that commit, we get a "memory leak" problem because the above "N-th var_defs.name" is not freed.

If enable CONFIG_DEBUG_KMEMLEAK and inject a fault at where the N-th var_defs.expr allocated, then execute on shell like: $ echo 'hist:key=call_site:val=$v1,$v2:v1=bytes_req,v2=bytes_alloc' > \ /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger

Then kmemleak reports: unreferenced object 0xffff8fb100ef3518 (size 8): comm "bash", pid 196, jiffies 4295681690 (age 28.538s) hex dump (first 8 bytes): 76 31 00 00 b1 8f ff ff v1...... backtrace: [<0000000038fe4895>] kstrdup+0x2d/0x60 [<00000000c99c049a>] event_hist_trigger_parse+0x206f/0x20e0 [<00000000ae70d2cc>] trigger_process_regex+0xc0/0x110 [<0000000066737a4c>] event_trigger_write+0x75/0xd0 [<000000007341e40c>] vfs_write+0xbb/0x2a0 [<0000000087fde4c2>] ksys_write+0x59/0xd0 [<00000000581e9cdf>] do_syscall_64+0x3a/0x80 [<00000000cf3b065c>] entry_SYSCALL_64_after_hwframe+0x46/0xb0(CVE-2022-49648)

In the Linux kernel, the following vulnerability has been resolved:

can: gs_usb: gs_usb_open/close(): fix memory leak

The gs_usb driver appears to suffer from a malady common to many USB CAN adapter drivers in that it performs usb_alloc_coherent() to allocate a number of USB request blocks (URBs) for RX, and then later relies on usb_kill_anchored_urbs() to free them, but this doesn't actually free them. As a result, this may be leaking DMA memory that's been used by the driver.

This commit is an adaptation of the techniques found in the esd_usb2 driver where a similar design pattern led to a memory leak. It explicitly frees the RX URBs and their DMA memory via a call to usb_free_coherent(). Since the RX URBs were allocated in the gs_can_open(), we remove them in gs_can_close() rather than in the disconnect function as was done in esd_usb2.

For more information, see the 928150fad41b ("can: esd_usb2: fix memory leak").(CVE-2022-49661)

In the Linux kernel, the following vulnerability has been resolved:

iio: trigger: sysfs: fix use-after-free on remove

Ensure that the irq_work has completed before the trigger is freed.

================================================================== BUG: KASAN: use-after-free in irq_work_run_list Read of size 8 at addr 0000000064702248 by task python3/25

Call Trace: irq_work_run_list irq_work_tick update_process_times tick_sched_handle tick_sched_timer __hrtimer_run_queues hrtimer_interrupt

Allocated by task 25: kmem_cache_alloc_trace iio_sysfs_trig_add dev_attr_store sysfs_kf_write kernfs_fop_write_iter new_sync_write vfs_write ksys_write sys_write

Freed by task 25: kfree iio_sysfs_trig_remove dev_attr_store sysfs_kf_write kernfs_fop_write_iter new_sync_write vfs_write ksys_write sys_write

==================================================================(CVE-2022-49685)

In the Linux kernel, the following vulnerability has been resolved:

cifs: Fix UAF in cifs_demultiplex_thread()

There is a UAF when xfstests on cifs:

BUG: KASAN: use-after-free in smb2_is_network_name_deleted+0x27/0x160 Read of size 4 at addr ffff88810103fc08 by task cifsd/923

CPU: 1 PID: 923 Comm: cifsd Not tainted 6.1.0-rc4+ #45 ... Call Trace: <TASK> dump_stack_lvl+0x34/0x44 print_report+0x171/0x472 kasan_report+0xad/0x130 kasan_check_range+0x145/0x1a0 smb2_is_network_name_deleted+0x27/0x160 cifs_demultiplex_thread.cold+0x172/0x5a4 kthread+0x165/0x1a0 ret_from_fork+0x1f/0x30 </TASK>

Allocated by task 923: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 __kasan_slab_alloc+0x54/0x60 kmem_cache_alloc+0x147/0x320 mempool_alloc+0xe1/0x260 cifs_small_buf_get+0x24/0x60 allocate_buffers+0xa1/0x1c0 cifs_demultiplex_thread+0x199/0x10d0 kthread+0x165/0x1a0 ret_from_fork+0x1f/0x30

Freed by task 921: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info+0x2a/0x40 ____kasan_slab_free+0x143/0x1b0 kmem_cache_free+0xe3/0x4d0 cifs_small_buf_release+0x29/0x90 SMB2_negotiate+0x8b7/0x1c60 smb2_negotiate+0x51/0x70 cifs_negotiate_protocol+0xf0/0x160 cifs_get_smb_ses+0x5fa/0x13c0 mount_get_conns+0x7a/0x750 cifs_mount+0x103/0xd00 cifs_smb3_do_mount+0x1dd/0xcb0 smb3_get_tree+0x1d5/0x300 vfs_get_tree+0x41/0xf0 path_mount+0x9b3/0xdd0 __x64_sys_mount+0x190/0x1d0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0

The UAF is because:

mount(pid: 921)	cifsd(pid: 923)
	cifs_demultiplex_thread
SMB2_negotiate
cifs_send_recv
compound_send_recv
smb_send_rqst
wait_for_response
wait_event_state [1]
	standard_receive3
	cifs_handle_standard
	handle_mid
	mid->resp_buf = buf; [2]
	dequeue_mid [3]
KILL the process [4]
resp_iov[i].iov_base = buf
free_rsp_buf [5]
	is_network_name_deleted [6]
	callback

After send request to server, wait the response until mid->mid_state != SUBMITTED;
Receive response from server, and set it to mid;
Set the mid state to RECEIVED;
Kill the process, the mid state already RECEIVED, get 0;
Handle and release the negotiate response;
UAF.

It can be easily reproduce with add some delay in [3] - [6].

Only sync call has the problem since async call's callback is executed in cifsd process.

Add an extra state to mark the mid state to READY before wakeup the waitter, then it can get the resp safely.(CVE-2023-52572)

In the Linux kernel, the following vulnerability has been resolved:

smb: client: fix TCP timers deadlock after rmmod

Commit ef7134c7fc48 ("smb: client: Fix use-after-free of network namespace.") fixed a netns UAF by manually enabled socket refcounting (sk->sk_net_refcnt=1 and sock_inuse_add(net, 1)).

The reason the patch worked for that bug was because we now hold references to the netns (get_net_track() gets a ref internally) and they're properly released (internally, on __sk_destruct()), but only because sk->sk_net_refcnt was set.

Problem: (this happens regardless of CONFIG_NET_NS_REFCNT_TRACKER and regardless if init_net or other)

Setting sk->sk_net_refcnt=1 manually and after socket creation is not only out of cifs scope, but also technically wrong -- it's set conditionally based on user (=1) vs kernel (=0) sockets. And net/ implementations seem to base their user vs kernel space operations on it.

e.g. upon TCP socket close, the TCP timers are not cleared because sk->sk_net_refcnt=1: (cf. commit 151c9c724d05 ("tcp: properly terminate timers for kernel sockets"))

net/ipv4/tcp.c: void tcp_close(struct sock *sk, long timeout) { lock_sock(sk); __tcp_close(sk, timeout); release_sock(sk); if (!sk->sk_net_refcnt) inet_csk_clear_xmit_timers_sync(sk); sock_put(sk); }

Which will throw a lockdep warning and then, as expected, deadlock on tcp_write_timer().

A way to reproduce this is by running the reproducer from ef7134c7fc48 and then 'rmmod cifs'. A few seconds later, the deadlock/lockdep warning shows up.

Fix: We shouldn't mess with socket internals ourselves, so do not set sk_net_refcnt manually.

Also change __sock_create() to sock_create_kern() for explicitness.

As for non-init_net network namespaces, we deal with it the best way we can -- hold an extra netns reference for server->ssocket and drop it when it's released. This ensures that the netns still exists whenever we need to create/destroy server->ssocket, but is not directly tied to it.(CVE-2024-54680)

In the Linux kernel, the following vulnerability has been resolved:

hfsplus: don't query the device logical block size multiple times

Devices block sizes may change. One of these cases is a loop device by using ioctl LOOP_SET_BLOCK_SIZE.

While this may cause other issues like IO being rejected, in the case of hfsplus, it will allocate a block by using that size and potentially write out-of-bounds when hfsplus_read_wrapper calls hfsplus_submit_bio and the latter function reads a different io_size.

Using a new min_io_size initally set to sb_min_blocksize works for the purposes of the original fix, since it will be set to the max between HFSPLUS_SECTOR_SIZE and the first seen logical block size. We still use the max between HFSPLUS_SECTOR_SIZE and min_io_size in case the latter is not initialized.

Tested by mounting an hfsplus filesystem with loop block sizes 512, 1024 and 4096.

The produced KASAN report before the fix looks like this:

[ 419.944641] ================================================================== [ 419.945655] BUG: KASAN: slab-use-after-free in hfsplus_read_wrapper+0x659/0xa0a [ 419.946703] Read of size 2 at addr ffff88800721fc00 by task repro/10678 [ 419.947612] [ 419.947846] CPU: 0 UID: 0 PID: 10678 Comm: repro Not tainted 6.12.0-rc5-00008-gdf56e0f2f3ca #84 [ 419.949007] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 419.950035] Call Trace: [ 419.950384] <TASK> [ 419.950676] dump_stack_lvl+0x57/0x78 [ 419.951212] ? hfsplus_read_wrapper+0x659/0xa0a [ 419.951830] print_report+0x14c/0x49e [ 419.952361] ? __virt_addr_valid+0x267/0x278 [ 419.952979] ? kmem_cache_debug_flags+0xc/0x1d [ 419.953561] ? hfsplus_read_wrapper+0x659/0xa0a [ 419.954231] kasan_report+0x89/0xb0 [ 419.954748] ? hfsplus_read_wrapper+0x659/0xa0a [ 419.955367] hfsplus_read_wrapper+0x659/0xa0a [ 419.955948] ? __pfx_hfsplus_read_wrapper+0x10/0x10 [ 419.956618] ? do_raw_spin_unlock+0x59/0x1a9 [ 419.957214] ? _raw_spin_unlock+0x1a/0x2e [ 419.957772] hfsplus_fill_super+0x348/0x1590 [ 419.958355] ? hlock_class+0x4c/0x109 [ 419.958867] ? __pfx_hfsplus_fill_super+0x10/0x10 [ 419.959499] ? __pfx_string+0x10/0x10 [ 419.960006] ? lock_acquire+0x3e2/0x454 [ 419.960532] ? bdev_name.constprop.0+0xce/0x243 [ 419.961129] ? __pfx_bdev_name.constprop.0+0x10/0x10 [ 419.961799] ? pointer+0x3f0/0x62f [ 419.962277] ? __pfx_pointer+0x10/0x10 [ 419.962761] ? vsnprintf+0x6c4/0xfba [ 419.963178] ? __pfx_vsnprintf+0x10/0x10 [ 419.963621] ? setup_bdev_super+0x376/0x3b3 [ 419.964029] ? snprintf+0x9d/0xd2 [ 419.964344] ? __pfx_snprintf+0x10/0x10 [ 419.964675] ? lock_acquired+0x45c/0x5e9 [ 419.965016] ? set_blocksize+0x139/0x1c1 [ 419.965381] ? sb_set_blocksize+0x6d/0xae [ 419.965742] ? __pfx_hfsplus_fill_super+0x10/0x10 [ 419.966179] mount_bdev+0x12f/0x1bf [ 419.966512] ? __pfx_mount_bdev+0x10/0x10 [ 419.966886] ? vfs_parse_fs_string+0xce/0x111 [ 419.967293] ? __pfx_vfs_parse_fs_string+0x10/0x10 [ 419.967702] ? __pfx_hfsplus_mount+0x10/0x10 [ 419.968073] legacy_get_tree+0x104/0x178 [ 419.968414] vfs_get_tree+0x86/0x296 [ 419.968751] path_mount+0xba3/0xd0b [ 419.969157] ? __pfx_path_mount+0x10/0x10 [ 419.969594] ? kmem_cache_free+0x1e2/0x260 [ 419.970311] do_mount+0x99/0xe0 [ 419.970630] ? __pfx_do_mount+0x10/0x10 [ 419.971008] __do_sys_mount+0x199/0x1c9 [ 419.971397] do_syscall_64+0xd0/0x135 [ 419.971761] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 419.972233] RIP: 0033:0x7c3cb812972e [ 419.972564] Code: 48 8b 0d f5 46 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c2 46 0d 00 f7 d8 64 89 01 48 [ 419.974371] RSP: 002b:00007ffe30632548 EFLAGS: 00000286 ORIG_RAX: 00000000000000a5 [ 419.975048] RAX: ffffffffffffffda RBX: 00007ffe306328d8 RCX: 00007c3cb812972e [ 419.975701] RDX: 0000000020000000 RSI: 0000000020000c80 RDI: ---truncated---(CVE-2024-56548)

In the Linux kernel, the following vulnerability has been resolved:

af_packet: avoid erroring out after sock_init_data() in packet_create()

After sock_init_data() the allocated sk object is attached to the provided sock object. On error, packet_create() frees the sk object leaving the dangling pointer in the sock object on return. Some other code may try to use this pointer and cause use-after-free.(CVE-2024-56606)

In the Linux kernel, the following vulnerability has been resolved:

net: sched: Disallow replacing of child qdisc from one parent to another

Lion Ackermann was able to create a UAF which can be abused for privilege escalation with the following script

Step 1. create root qdisc tc qdisc add dev lo root handle 1:0 drr

step2. a class for packet aggregation do demonstrate uaf tc class add dev lo classid 1:1 drr

step3. a class for nesting tc class add dev lo classid 1:2 drr

step4. a class to graft qdisc to tc class add dev lo classid 1:3 drr

step5. tc qdisc add dev lo parent 1:1 handle 2:0 plug limit 1024

step6. tc qdisc add dev lo parent 1:2 handle 3:0 drr

step7. tc class add dev lo classid 3:1 drr

step 8. tc qdisc add dev lo parent 3:1 handle 4:0 pfifo

step 9. Display the class/qdisc layout

tc class ls dev lo class drr 1:1 root leaf 2: quantum 64Kb class drr 1:2 root leaf 3: quantum 64Kb class drr 3:1 root leaf 4: quantum 64Kb

tc qdisc ls qdisc drr 1: dev lo root refcnt 2 qdisc plug 2: dev lo parent 1:1 qdisc pfifo 4: dev lo parent 3:1 limit 1000p qdisc drr 3: dev lo parent 1:2

step10. trigger the bug <=== prevented by this patch tc qdisc replace dev lo parent 1:3 handle 4:0

step 11. Redisplay again the qdiscs/classes

tc class ls dev lo class drr 1:1 root leaf 2: quantum 64Kb class drr 1:2 root leaf 3: quantum 64Kb class drr 1:3 root leaf 4: quantum 64Kb class drr 3:1 root leaf 4: quantum 64Kb

tc qdisc ls qdisc drr 1: dev lo root refcnt 2 qdisc plug 2: dev lo parent 1:1 qdisc pfifo 4: dev lo parent 3:1 refcnt 2 limit 1000p qdisc drr 3: dev lo parent 1:2

Observe that a) parent for 4:0 does not change despite the replace request. There can only be one parent. b) refcount has gone up by two for 4:0 and c) both class 1:3 and 3:1 are pointing to it.

Step 12. send one packet to plug echo "" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10001)) step13. send one packet to the grafted fifo echo "" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10003))

step14. lets trigger the uaf tc class delete dev lo classid 1:3 tc class delete dev lo classid 1:1

The semantics of "replace" is for a del/add on the same node and not a delete from one node(3:1) and add to another node (1:3) as in step10. While we could "fix" with a more complex approach there could be consequences to expectations so the patch takes the preventive approach of "disallow such config".

Joint work with Lion Ackermann <nnamrec@gmail.com>(CVE-2025-21700)

In the Linux kernel, the following vulnerability has been resolved:

pfifo_tail_enqueue: Drop new packet when sch->limit == 0

Expected behaviour: In case we reach scheduler's limit, pfifo_tail_enqueue() will drop a packet in scheduler's queue and decrease scheduler's qlen by one. Then, pfifo_tail_enqueue() enqueue new packet and increase scheduler's qlen by one. Finally, pfifo_tail_enqueue() return NET_XMIT_CN status code.

Weird behaviour: In case we set sch->limit == 0 and trigger pfifo_tail_enqueue() on a scheduler that has no packet, the 'drop a packet' step will do nothing. This means the scheduler's qlen still has value equal 0. Then, we continue to enqueue new packet and increase scheduler's qlen by one. In summary, we can leverage pfifo_tail_enqueue() to increase qlen by one and return NET_XMIT_CN status code.

The problem is: Let's say we have two qdiscs: Qdisc_A and Qdisc_B. - Qdisc_A's type must have '->graft()' function to create parent/child relationship. Let's say Qdisc_A's type is hfsc. Enqueue packet to this qdisc will trigger hfsc_enqueue. - Qdisc_B's type is pfifo_head_drop. Enqueue packet to this qdisc will trigger pfifo_tail_enqueue. - Qdisc_B is configured to have sch->limit == 0. - Qdisc_A is configured to route the enqueued's packet to Qdisc_B.

Enqueue packet through Qdisc_A will lead to: - hfsc_enqueue(Qdisc_A) -> pfifo_tail_enqueue(Qdisc_B) - Qdisc_B->q.qlen += 1 - pfifo_tail_enqueue() return NET_XMIT_CN - hfsc_enqueue() check for NET_XMIT_SUCCESS and see NET_XMIT_CN => hfsc_enqueue() don't increase qlen of Qdisc_A.

The whole process lead to a situation where Qdisc_A->q.qlen == 0 and Qdisc_B->q.qlen == 1. Replace 'hfsc' with other type (for example: 'drr') still lead to the same problem. This violate the design where parent's qlen should equal to the sum of its childrens'qlen.

Bug impact: This issue can be used for user->kernel privilege escalation when it is reachable.(CVE-2025-21702)

Severity

7.8 (High)


                    
                      CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

References

URL

Type

	https://www.openeuler.org/zh/security/security-bu…	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2021-47631	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2021-47642	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-49044	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-49055	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-49114	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-49137	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-49253	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-49308	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-49326	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-49341	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-49351	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-49404	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-49433	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-49439	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-49447	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-49526	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-49564	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-49620	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-49648	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-49661	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-49685	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-52572	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-54680	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56548	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56606	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-21700	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-21702	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-4.19.90-2503.3.0.0319.oe2003sp4.aarch64.rpm",
          "bpftool-debuginfo-4.19.90-2503.3.0.0319.oe2003sp4.aarch64.rpm",
          "kernel-4.19.90-2503.3.0.0319.oe2003sp4.aarch64.rpm",
          "kernel-debuginfo-4.19.90-2503.3.0.0319.oe2003sp4.aarch64.rpm",
          "kernel-debugsource-4.19.90-2503.3.0.0319.oe2003sp4.aarch64.rpm",
          "kernel-devel-4.19.90-2503.3.0.0319.oe2003sp4.aarch64.rpm",
          "kernel-source-4.19.90-2503.3.0.0319.oe2003sp4.aarch64.rpm",
          "kernel-tools-4.19.90-2503.3.0.0319.oe2003sp4.aarch64.rpm",
          "kernel-tools-debuginfo-4.19.90-2503.3.0.0319.oe2003sp4.aarch64.rpm",
          "kernel-tools-devel-4.19.90-2503.3.0.0319.oe2003sp4.aarch64.rpm",
          "perf-4.19.90-2503.3.0.0319.oe2003sp4.aarch64.rpm",
          "perf-debuginfo-4.19.90-2503.3.0.0319.oe2003sp4.aarch64.rpm",
          "python2-perf-4.19.90-2503.3.0.0319.oe2003sp4.aarch64.rpm",
          "python2-perf-debuginfo-4.19.90-2503.3.0.0319.oe2003sp4.aarch64.rpm",
          "python3-perf-4.19.90-2503.3.0.0319.oe2003sp4.aarch64.rpm",
          "python3-perf-debuginfo-4.19.90-2503.3.0.0319.oe2003sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-4.19.90-2503.3.0.0319.oe2003sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-4.19.90-2503.3.0.0319.oe2003sp4.x86_64.rpm",
          "bpftool-debuginfo-4.19.90-2503.3.0.0319.oe2003sp4.x86_64.rpm",
          "kernel-4.19.90-2503.3.0.0319.oe2003sp4.x86_64.rpm",
          "kernel-debuginfo-4.19.90-2503.3.0.0319.oe2003sp4.x86_64.rpm",
          "kernel-debugsource-4.19.90-2503.3.0.0319.oe2003sp4.x86_64.rpm",
          "kernel-devel-4.19.90-2503.3.0.0319.oe2003sp4.x86_64.rpm",
          "kernel-source-4.19.90-2503.3.0.0319.oe2003sp4.x86_64.rpm",
          "kernel-tools-4.19.90-2503.3.0.0319.oe2003sp4.x86_64.rpm",
          "kernel-tools-debuginfo-4.19.90-2503.3.0.0319.oe2003sp4.x86_64.rpm",
          "kernel-tools-devel-4.19.90-2503.3.0.0319.oe2003sp4.x86_64.rpm",
          "perf-4.19.90-2503.3.0.0319.oe2003sp4.x86_64.rpm",
          "perf-debuginfo-4.19.90-2503.3.0.0319.oe2003sp4.x86_64.rpm",
          "python2-perf-4.19.90-2503.3.0.0319.oe2003sp4.x86_64.rpm",
          "python2-perf-debuginfo-4.19.90-2503.3.0.0319.oe2003sp4.x86_64.rpm",
          "python3-perf-4.19.90-2503.3.0.0319.oe2003sp4.x86_64.rpm",
          "python3-perf-debuginfo-4.19.90-2503.3.0.0319.oe2003sp4.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:20.03-LTS-SP4",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.19.90-2503.3.0.0319.oe2003sp4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nARM: davinci: da850-evm: Avoid NULL pointer dereference\n\nWith newer versions of GCC, there is a panic in da850_evm_config_emac()\nwhen booting multi_v5_defconfig in QEMU under the palmetto-bmc machine:\n\nUnable to handle kernel NULL pointer dereference at virtual address 00000020\npgd = (ptrval)\n[00000020] *pgd=00000000\nInternal error: Oops: 5 [#1] PREEMPT ARM\nModules linked in:\nCPU: 0 PID: 1 Comm: swapper Not tainted 5.15.0 #1\nHardware name: Generic DT based system\nPC is at da850_evm_config_emac+0x1c/0x120\nLR is at do_one_initcall+0x50/0x1e0\n\nThe emac_pdata pointer in soc_info is NULL because davinci_soc_info only\ngets populated on davinci machines but da850_evm_config_emac() is called\non all machines via device_initcall().\n\nMove the rmii_en assignment below the machine check so that it is only\ndereferenced when running on a supported SoC.(CVE-2021-47631)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvideo: fbdev: nvidiafb: Use strscpy() to prevent buffer overflow\n\nCoverity complains of a possible buffer overflow. However,\ngiven the \u0026apos;static\u0026apos; scope of nvidia_setup_i2c_bus() it looks\nlike that can\u0026apos;t happen after examiniing the call sites.\n\nCID 19036 (#1 of 1): Copy into fixed size buffer (STRING_OVERFLOW)\n1. fixed_size_dest: You might overrun the 48-character fixed-size string\n  chan-\u0026gt;adapter.name by copying name without checking the length.\n2. parameter_as_source: Note: This defect has an elevated risk because the\n  source argument is a parameter of the current function.\n 89        strcpy(chan-\u0026gt;adapter.name, name);\n\nFix this warning by using strscpy() which will silence the warning and\nprevent any future buffer overflows should the names used to identify the\nchannel become much longer.(CVE-2021-47642)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm integrity: fix memory corruption when tag_size is less than digest size\n\nIt is possible to set up dm-integrity in such a way that the\n\u0026quot;tag_size\u0026quot; parameter is less than the actual digest size. In this\nsituation, a part of the digest beyond tag_size is ignored.\n\nIn this case, dm-integrity would write beyond the end of the\nic-\u0026gt;recalc_tags array and corrupt memory. The corruption happened in\nintegrity_recalc-\u0026gt;integrity_sector_checksum-\u0026gt;crypto_shash_final.\n\nFix this corruption by increasing the tags array so that it has enough\npadding at the end to accomodate the loop in integrity_recalc() being\nable to write a full digest size for the last member of the tags\narray.(CVE-2022-49044)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: Check for potential null return of kmalloc_array()\n\nAs the kmalloc_array() may return null, the \u0026apos;event_waiters[i].wait\u0026apos; would lead to null-pointer dereference.\nTherefore, it is better to check the return value of kmalloc_array() to avoid this confusion.(CVE-2022-49055)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: libfc: Fix use after free in fc_exch_abts_resp()\n\nfc_exch_release(ep) will decrease the ep\u0026apos;s reference count. When the\nreference count reaches zero, it is freed. But ep is still used in the\nfollowing code, which will lead to a use after free.\n\nReturn after the fc_exch_release() call to avoid use after free.(CVE-2022-49114)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/amdgpu/amdgpu_cs: fix refcount leak of a dma_fence obj\n\nThis issue takes place in an error path in\namdgpu_cs_fence_to_handle_ioctl(). When `info-\u0026gt;in.what` falls into\ndefault case, the function simply returns -EINVAL, forgetting to\ndecrement the reference count of a dma_fence obj, which is bumped\nearlier by amdgpu_cs_get_fence(). This may result in reference count\nleaks.\n\nFix it by decreasing the refcount of specific object before returning\nthe error code.(CVE-2022-49137)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: usb: go7007: s2250-board: fix leak in probe()\n\nCall i2c_unregister_device(audio) on this error path.(CVE-2022-49253)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nextcon: Modify extcon device to be created after driver data is set\n\nCurrently, someone can invoke the sysfs such as state_show()\nintermittently before dev_set_drvdata() is done.\nAnd it can be a cause of kernel Oops because of edev is Null at that time.\nSo modified the driver registration to after setting drviver data.\n\n- Oops\u0026apos;s backtrace.\n\nBacktrace:\n[\u0026lt;c067865c\u0026gt;] (state_show) from [\u0026lt;c05222e8\u0026gt;] (dev_attr_show)\n[\u0026lt;c05222c0\u0026gt;] (dev_attr_show) from [\u0026lt;c02c66e0\u0026gt;] (sysfs_kf_seq_show)\n[\u0026lt;c02c6648\u0026gt;] (sysfs_kf_seq_show) from [\u0026lt;c02c496c\u0026gt;] (kernfs_seq_show)\n[\u0026lt;c02c4938\u0026gt;] (kernfs_seq_show) from [\u0026lt;c025e2a0\u0026gt;] (seq_read)\n[\u0026lt;c025e11c\u0026gt;] (seq_read) from [\u0026lt;c02c50a0\u0026gt;] (kernfs_fop_read)\n[\u0026lt;c02c5064\u0026gt;] (kernfs_fop_read) from [\u0026lt;c0231cac\u0026gt;] (__vfs_read)\n[\u0026lt;c0231c5c\u0026gt;] (__vfs_read) from [\u0026lt;c0231ee0\u0026gt;] (vfs_read)\n[\u0026lt;c0231e34\u0026gt;] (vfs_read) from [\u0026lt;c0232464\u0026gt;] (ksys_read)\n[\u0026lt;c02323f0\u0026gt;] (ksys_read) from [\u0026lt;c02324fc\u0026gt;] (sys_read)\n[\u0026lt;c02324e4\u0026gt;] (sys_read) from [\u0026lt;c00091d0\u0026gt;] (__sys_trace_return)(CVE-2022-49308)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrtl818x: Prevent using not initialized queues\n\nUsing not existing queues can panic the kernel with rtl8180/rtl8185 cards.\nIgnore the skb priority for those cards, they only have one tx queue. Pierre\nAsselin (pa@panix.com) reported the kernel crash in the Gentoo forum:\n\nhttps://forums.gentoo.org/viewtopic-t-1147832-postdays-0-postorder-asc-start-25.html\n\nHe also confirmed that this patch fixes the issue. In summary this happened:\n\nAfter updating wpa_supplicant from 2.9 to 2.10 the kernel crashed with a\n\u0026quot;divide error: 0000\u0026quot; when connecting to an AP. Control port tx now tries to\nuse IEEE80211_AC_VO for the priority, which wpa_supplicants starts to use in\n2.10.\n\nSince only the rtl8187se part of the driver supports QoS, the priority\nof the skb is set to IEEE80211_AC_BE (2) by mac80211 for rtl8180/rtl8185\ncards.\n\nrtl8180 is then unconditionally reading out the priority and finally crashes on\ndrivers/net/wireless/realtek/rtl818x/rtl8180/dev.c line 544 without this\npatch:\n\tidx = (ring-\u0026gt;idx + skb_queue_len(\u0026amp;ring-\u0026gt;queue)) % ring-\u0026gt;entries\n\n\u0026quot;ring-\u0026gt;entries\u0026quot; is zero for rtl8180/rtl8185 cards, tx_ring[2] never got\ninitialized.(CVE-2022-49326)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf, arm64: Clear prog-\u0026gt;jited_len along prog-\u0026gt;jited\n\nsyzbot reported an illegal copy_to_user() attempt\nfrom bpf_prog_get_info_by_fd() [1]\n\nThere was no repro yet on this bug, but I think\nthat commit 0aef499f3172 (\u0026quot;mm/usercopy: Detect vmalloc overruns\u0026quot;)\nis exposing a prior bug in bpf arm64.\n\nbpf_prog_get_info_by_fd() looks at prog-\u0026gt;jited_len\nto determine if the JIT image can be copied out to user space.\n\nMy theory is that syzbot managed to get a prog where prog-\u0026gt;jited_len\nhas been set to 43, while prog-\u0026gt;bpf_func has ben cleared.\n\nIt is not clear why copy_to_user(uinsns, NULL, ulen) is triggering\nthis particular warning.\n\nI thought find_vma_area(NULL) would not find a vm_struct.\nAs we do not hold vmap_area_lock spinlock, it might be possible\nthat the found vm_struct was garbage.\n\n[1]\nusercopy: Kernel memory exposure attempt detected from vmalloc (offset 792633534417210172, size 43)!\nkernel BUG at mm/usercopy.c:101!\nInternal error: Oops - BUG: 0 [#1] PREEMPT SMP\nModules linked in:\nCPU: 0 PID: 25002 Comm: syz-executor.1 Not tainted 5.18.0-syzkaller-10139-g8291eaafed36 #0\nHardware name: linux,dummy-virt (DT)\npstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : usercopy_abort+0x90/0x94 mm/usercopy.c:101\nlr : usercopy_abort+0x90/0x94 mm/usercopy.c:89\nsp : ffff80000b773a20\nx29: ffff80000b773a30 x28: faff80000b745000 x27: ffff80000b773b48\nx26: 0000000000000000 x25: 000000000000002b x24: 0000000000000000\nx23: 00000000000000e0 x22: ffff80000b75db67 x21: 0000000000000001\nx20: 000000000000002b x19: ffff80000b75db3c x18: 00000000fffffffd\nx17: 2820636f6c6c616d x16: 76206d6f72662064 x15: 6574636574656420\nx14: 74706d6574746120 x13: 2129333420657a69 x12: 73202c3237313031\nx11: 3237313434333533 x10: 3336323937207465 x9 : 657275736f707865\nx8 : ffff80000a30c550 x7 : ffff80000b773830 x6 : ffff80000b773830\nx5 : 0000000000000000 x4 : ffff00007fbbaa10 x3 : 0000000000000000\nx2 : 0000000000000000 x1 : f7ff000028fc0000 x0 : 0000000000000064\nCall trace:\n usercopy_abort+0x90/0x94 mm/usercopy.c:89\n check_heap_object mm/usercopy.c:186 [inline]\n __check_object_size mm/usercopy.c:252 [inline]\n __check_object_size+0x198/0x36c mm/usercopy.c:214\n check_object_size include/linux/thread_info.h:199 [inline]\n check_copy_size include/linux/thread_info.h:235 [inline]\n copy_to_user include/linux/uaccess.h:159 [inline]\n bpf_prog_get_info_by_fd.isra.0+0xf14/0xfdc kernel/bpf/syscall.c:3993\n bpf_obj_get_info_by_fd+0x12c/0x510 kernel/bpf/syscall.c:4253\n __sys_bpf+0x900/0x2150 kernel/bpf/syscall.c:4956\n __do_sys_bpf kernel/bpf/syscall.c:5021 [inline]\n __se_sys_bpf kernel/bpf/syscall.c:5019 [inline]\n __arm64_sys_bpf+0x28/0x40 kernel/bpf/syscall.c:5019\n __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]\n invoke_syscall+0x48/0x114 arch/arm64/kernel/syscall.c:52\n el0_svc_common.constprop.0+0x44/0xec arch/arm64/kernel/syscall.c:142\n do_el0_svc+0xa0/0xc0 arch/arm64/kernel/syscall.c:206\n el0_svc+0x44/0xb0 arch/arm64/kernel/entry-common.c:624\n el0t_64_sync_handler+0x1ac/0x1b0 arch/arm64/kernel/entry-common.c:642\n el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:581\nCode: aa0003e3 d00038c0 91248000 97fff65f (d4210000)(CVE-2022-49341)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: altera: Fix refcount leak in altera_tse_mdio_create\n\nEvery iteration of for_each_child_of_node() decrements\nthe reference count of the previous node.\nWhen break from a for_each_child_of_node() loop,\nwe need to explicitly call of_node_put() on the child node when\nnot need anymore.\nAdd missing of_node_put() to avoid refcount leak.(CVE-2022-49351)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/hfi1: Fix potential integer multiplication overflow errors\n\nWhen multiplying of different types, an overflow is possible even when\nstoring the result in a larger type. This is because the conversion is\ndone after the multiplication. So arithmetic overflow and thus in\nincorrect value is possible.\n\nCorrect an instance of this in the inter packet delay calculation.  Fix by\nensuring one of the operands is u64 which will promote the other to u64 as\nwell ensuring no overflow.(CVE-2022-49404)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/hfi1: Prevent use of lock before it is initialized\n\nIf there is a failure during probe of hfi1 before the sdma_map_lock is\ninitialized, the call to hfi1_free_devdata() will attempt to use a lock\nthat has not been initialized. If the locking correctness validator is on\nthen an INFO message and stack trace resembling the following may be seen:\n\n  INFO: trying to register non-static key.\n  The code is fine but needs lockdep annotation, or maybe\n  you didn\u0026apos;t initialize this object before use?\n  turning off the locking correctness validator.\n  Call Trace:\n  register_lock_class+0x11b/0x880\n  __lock_acquire+0xf3/0x7930\n  lock_acquire+0xff/0x2d0\n  _raw_spin_lock_irq+0x46/0x60\n  sdma_clean+0x42a/0x660 [hfi1]\n  hfi1_free_devdata+0x3a7/0x420 [hfi1]\n  init_one+0x867/0x11a0 [hfi1]\n  pci_device_probe+0x40e/0x8d0\n\nThe use of sdma_map_lock in sdma_clean() is for freeing the sdma_map\nmemory, and sdma_map is not allocated/initialized until after\nsdma_map_lock has been initialized. This code only needs to be run if\nsdma_map is not NULL, and so checking for that condition will avoid trying\nto use the lock before it is initialized.(CVE-2022-49433)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/fsl_rio: Fix refcount leak in fsl_rio_setup\n\nof_parse_phandle() returns a node pointer with refcount\nincremented, we should use of_node_put() on it when not need anymore.\nAdd missing of_node_put() to avoid refcount leak.(CVE-2022-49439)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nARM: hisi: Add missing of_node_put after of_find_compatible_node\n\nof_find_compatible_node  will increment the refcount of the returned\ndevice_node. Calling of_node_put() to avoid the refcount leak(CVE-2022-49447)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/bitmap: don\u0026apos;t set sb values if can\u0026apos;t pass sanity check\n\nIf bitmap area contains invalid data, kernel will crash then mdadm\ntriggers \u0026quot;Segmentation fault\u0026quot;.\nThis is cluster-md speical bug. In non-clustered env, mdadm will\nhandle broken metadata case. In clustered array, only kernel space\nhandles bitmap slot info. But even this bug only happened in clustered\nenv, current sanity check is wrong, the code should be changed.\n\nHow to trigger: (faulty injection)\n\ndd if=/dev/zero bs=1M count=1 oflag=direct of=/dev/sda\ndd if=/dev/zero bs=1M count=1 oflag=direct of=/dev/sdb\nmdadm -C /dev/md0 -b clustered -e 1.2 -n 2 -l mirror /dev/sda /dev/sdb\nmdadm -Ss\necho aaa \u0026gt; magic.txt\n == below modifying slot 2 bitmap data ==\ndd if=magic.txt of=/dev/sda seek=16384 bs=1 count=3 \u0026lt;== destroy magic\ndd if=/dev/zero of=/dev/sda seek=16436 bs=1 count=4 \u0026lt;== ZERO chunksize\nmdadm -A /dev/md0 /dev/sda /dev/sdb\n == kernel crashes. mdadm outputs \u0026quot;Segmentation fault\u0026quot; ==\n\nReason of kernel crash:\n\nIn md_bitmap_read_sb (called by md_bitmap_create), bad bitmap magic didn\u0026apos;t\nblock chunksize assignment, and zero value made DIV_ROUND_UP_SECTOR_T()\ntrigger \u0026quot;divide error\u0026quot;.\n\nCrash log:\n\nkernel: md: md0 stopped.\nkernel: md/raid1:md0: not clean -- starting background reconstruction\nkernel: md/raid1:md0: active with 2 out of 2 mirrors\nkernel: dlm: ... ...\nkernel: md-cluster: Joined cluster 44810aba-38bb-e6b8-daca-bc97a0b254aa slot 1\nkernel: md0: invalid bitmap file superblock: bad magic\nkernel: md_bitmap_copy_from_slot can\u0026apos;t get bitmap from slot 2\nkernel: md-cluster: Could not gather bitmaps from slot 2\nkernel: divide error: 0000 [#1] SMP NOPTI\nkernel: CPU: 0 PID: 1603 Comm: mdadm Not tainted 5.14.6-1-default\nkernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)\nkernel: RIP: 0010:md_bitmap_create+0x1d1/0x850 [md_mod]\nkernel: RSP: 0018:ffffc22ac0843ba0 EFLAGS: 00010246\nkernel: ... ...\nkernel: Call Trace:\nkernel:  ? dlm_lock_sync+0xd0/0xd0 [md_cluster 77fe..7a0]\nkernel:  md_bitmap_copy_from_slot+0x2c/0x290 [md_mod 24ea..d3a]\nkernel:  load_bitmaps+0xec/0x210 [md_cluster 77fe..7a0]\nkernel:  md_bitmap_load+0x81/0x1e0 [md_mod 24ea..d3a]\nkernel:  do_md_run+0x30/0x100 [md_mod 24ea..d3a]\nkernel:  md_ioctl+0x1290/0x15a0 [md_mod 24ea....d3a]\nkernel:  ? mddev_unlock+0xaa/0x130 [md_mod 24ea..d3a]\nkernel:  ? blkdev_ioctl+0xb1/0x2b0\nkernel:  block_ioctl+0x3b/0x40\nkernel:  __x64_sys_ioctl+0x7f/0xb0\nkernel:  do_syscall_64+0x59/0x80\nkernel:  ? exit_to_user_mode_prepare+0x1ab/0x230\nkernel:  ? syscall_exit_to_user_mode+0x18/0x40\nkernel:  ? do_syscall_64+0x69/0x80\nkernel:  entry_SYSCALL_64_after_hwframe+0x44/0xae\nkernel: RIP: 0033:0x7f4a15fa722b\nkernel: ... ...\nkernel: ---[ end trace 8afa7612f559c868 ]---\nkernel: RIP: 0010:md_bitmap_create+0x1d1/0x850 [md_mod](CVE-2022-49526)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: qat - add param check for DH\n\nReject requests with a source buffer that is bigger than the size of the\nkey. This is to prevent a possible integer underflow that might happen\nwhen copying the source scatterlist into a linear buffer.(CVE-2022-49564)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: tipc: fix possible refcount leak in tipc_sk_create()\n\nFree sk in case tipc_sk_insert() fails.(CVE-2022-49620)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing/histograms: Fix memory leak problem\n\nThis reverts commit 46bbe5c671e06f070428b9be142cc4ee5cedebac.\n\nAs commit 46bbe5c671e0 (\u0026quot;tracing: fix double free\u0026quot;) said, the\n\u0026quot;double free\u0026quot; problem reported by clang static analyzer is:\n  \u0026gt; In parse_var_defs() if there is a problem allocating\n  \u0026gt; var_defs.expr, the earlier var_defs.name is freed.\n  \u0026gt; This free is duplicated by free_var_defs() which frees\n  \u0026gt; the rest of the list.\n\nHowever, if there is a problem allocating N-th var_defs.expr:\n  + in parse_var_defs(), the freed \u0026apos;earlier var_defs.name\u0026apos; is\n    actually the N-th var_defs.name;\n  + then in free_var_defs(), the names from 0th to (N-1)-th are freed;\n\n                        IF ALLOCATING PROBLEM HAPPENED HERE!!! -+\n                                                                 \\\n                                                                  |\n          0th           1th                 (N-1)-th      N-th    V\n          +-------------+-------------+-----+-------------+-----------\nvar_defs: | name | expr | name | expr | ... | name | expr | name | ///\n          +-------------+-------------+-----+-------------+-----------\n\nThese two frees don\u0026apos;t act on same name, so there was no \u0026quot;double free\u0026quot;\nproblem before. Conversely, after that commit, we get a \u0026quot;memory leak\u0026quot;\nproblem because the above \u0026quot;N-th var_defs.name\u0026quot; is not freed.\n\nIf enable CONFIG_DEBUG_KMEMLEAK and inject a fault at where the N-th\nvar_defs.expr allocated, then execute on shell like:\n  $ echo \u0026apos;hist:key=call_site:val=$v1,$v2:v1=bytes_req,v2=bytes_alloc\u0026apos; \u0026gt; \\\n/sys/kernel/debug/tracing/events/kmem/kmalloc/trigger\n\nThen kmemleak reports:\n  unreferenced object 0xffff8fb100ef3518 (size 8):\n    comm \u0026quot;bash\u0026quot;, pid 196, jiffies 4295681690 (age 28.538s)\n    hex dump (first 8 bytes):\n      76 31 00 00 b1 8f ff ff                          v1......\n    backtrace:\n      [\u0026lt;0000000038fe4895\u0026gt;] kstrdup+0x2d/0x60\n      [\u0026lt;00000000c99c049a\u0026gt;] event_hist_trigger_parse+0x206f/0x20e0\n      [\u0026lt;00000000ae70d2cc\u0026gt;] trigger_process_regex+0xc0/0x110\n      [\u0026lt;0000000066737a4c\u0026gt;] event_trigger_write+0x75/0xd0\n      [\u0026lt;000000007341e40c\u0026gt;] vfs_write+0xbb/0x2a0\n      [\u0026lt;0000000087fde4c2\u0026gt;] ksys_write+0x59/0xd0\n      [\u0026lt;00000000581e9cdf\u0026gt;] do_syscall_64+0x3a/0x80\n      [\u0026lt;00000000cf3b065c\u0026gt;] entry_SYSCALL_64_after_hwframe+0x46/0xb0(CVE-2022-49648)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: gs_usb: gs_usb_open/close(): fix memory leak\n\nThe gs_usb driver appears to suffer from a malady common to many USB\nCAN adapter drivers in that it performs usb_alloc_coherent() to\nallocate a number of USB request blocks (URBs) for RX, and then later\nrelies on usb_kill_anchored_urbs() to free them, but this doesn\u0026apos;t\nactually free them. As a result, this may be leaking DMA memory that\u0026apos;s\nbeen used by the driver.\n\nThis commit is an adaptation of the techniques found in the esd_usb2\ndriver where a similar design pattern led to a memory leak. It\nexplicitly frees the RX URBs and their DMA memory via a call to\nusb_free_coherent(). Since the RX URBs were allocated in the\ngs_can_open(), we remove them in gs_can_close() rather than in the\ndisconnect function as was done in esd_usb2.\n\nFor more information, see the 928150fad41b (\u0026quot;can: esd_usb2: fix memory\nleak\u0026quot;).(CVE-2022-49661)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: trigger: sysfs: fix use-after-free on remove\n\nEnsure that the irq_work has completed before the trigger is freed.\n\n ==================================================================\n BUG: KASAN: use-after-free in irq_work_run_list\n Read of size 8 at addr 0000000064702248 by task python3/25\n\n Call Trace:\n  irq_work_run_list\n  irq_work_tick\n  update_process_times\n  tick_sched_handle\n  tick_sched_timer\n  __hrtimer_run_queues\n  hrtimer_interrupt\n\n Allocated by task 25:\n  kmem_cache_alloc_trace\n  iio_sysfs_trig_add\n  dev_attr_store\n  sysfs_kf_write\n  kernfs_fop_write_iter\n  new_sync_write\n  vfs_write\n  ksys_write\n  sys_write\n\n Freed by task 25:\n  kfree\n  iio_sysfs_trig_remove\n  dev_attr_store\n  sysfs_kf_write\n  kernfs_fop_write_iter\n  new_sync_write\n  vfs_write\n  ksys_write\n  sys_write\n\n ==================================================================(CVE-2022-49685)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: Fix UAF in cifs_demultiplex_thread()\n\nThere is a UAF when xfstests on cifs:\n\n  BUG: KASAN: use-after-free in smb2_is_network_name_deleted+0x27/0x160\n  Read of size 4 at addr ffff88810103fc08 by task cifsd/923\n\n  CPU: 1 PID: 923 Comm: cifsd Not tainted 6.1.0-rc4+ #45\n  ...\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   dump_stack_lvl+0x34/0x44\n   print_report+0x171/0x472\n   kasan_report+0xad/0x130\n   kasan_check_range+0x145/0x1a0\n   smb2_is_network_name_deleted+0x27/0x160\n   cifs_demultiplex_thread.cold+0x172/0x5a4\n   kthread+0x165/0x1a0\n   ret_from_fork+0x1f/0x30\n   \u0026lt;/TASK\u0026gt;\n\n  Allocated by task 923:\n   kasan_save_stack+0x1e/0x40\n   kasan_set_track+0x21/0x30\n   __kasan_slab_alloc+0x54/0x60\n   kmem_cache_alloc+0x147/0x320\n   mempool_alloc+0xe1/0x260\n   cifs_small_buf_get+0x24/0x60\n   allocate_buffers+0xa1/0x1c0\n   cifs_demultiplex_thread+0x199/0x10d0\n   kthread+0x165/0x1a0\n   ret_from_fork+0x1f/0x30\n\n  Freed by task 921:\n   kasan_save_stack+0x1e/0x40\n   kasan_set_track+0x21/0x30\n   kasan_save_free_info+0x2a/0x40\n   ____kasan_slab_free+0x143/0x1b0\n   kmem_cache_free+0xe3/0x4d0\n   cifs_small_buf_release+0x29/0x90\n   SMB2_negotiate+0x8b7/0x1c60\n   smb2_negotiate+0x51/0x70\n   cifs_negotiate_protocol+0xf0/0x160\n   cifs_get_smb_ses+0x5fa/0x13c0\n   mount_get_conns+0x7a/0x750\n   cifs_mount+0x103/0xd00\n   cifs_smb3_do_mount+0x1dd/0xcb0\n   smb3_get_tree+0x1d5/0x300\n   vfs_get_tree+0x41/0xf0\n   path_mount+0x9b3/0xdd0\n   __x64_sys_mount+0x190/0x1d0\n   do_syscall_64+0x35/0x80\n   entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nThe UAF is because:\n\n mount(pid: 921)               | cifsd(pid: 923)\n-------------------------------|-------------------------------\n                               | cifs_demultiplex_thread\nSMB2_negotiate                 |\n cifs_send_recv                |\n  compound_send_recv           |\n   smb_send_rqst               |\n    wait_for_response          |\n     wait_event_state      [1] |\n                               |  standard_receive3\n                               |   cifs_handle_standard\n                               |    handle_mid\n                               |     mid-\u0026gt;resp_buf = buf;  [2]\n                               |     dequeue_mid           [3]\n     KILL the process      [4] |\n    resp_iov[i].iov_base = buf |\n free_rsp_buf              [5] |\n                               |   is_network_name_deleted [6]\n                               |   callback\n\n1. After send request to server, wait the response until\n    mid-\u0026gt;mid_state != SUBMITTED;\n2. Receive response from server, and set it to mid;\n3. Set the mid state to RECEIVED;\n4. Kill the process, the mid state already RECEIVED, get 0;\n5. Handle and release the negotiate response;\n6. UAF.\n\nIt can be easily reproduce with add some delay in [3] - [6].\n\nOnly sync call has the problem since async call\u0026apos;s callback is\nexecuted in cifsd process.\n\nAdd an extra state to mark the mid state to READY before wakeup the\nwaitter, then it can get the resp safely.(CVE-2023-52572)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix TCP timers deadlock after rmmod\n\nCommit ef7134c7fc48 (\u0026quot;smb: client: Fix use-after-free of network namespace.\u0026quot;)\nfixed a netns UAF by manually enabled socket refcounting\n(sk-\u0026gt;sk_net_refcnt=1 and sock_inuse_add(net, 1)).\n\nThe reason the patch worked for that bug was because we now hold\nreferences to the netns (get_net_track() gets a ref internally)\nand they\u0026apos;re properly released (internally, on __sk_destruct()),\nbut only because sk-\u0026gt;sk_net_refcnt was set.\n\nProblem:\n(this happens regardless of CONFIG_NET_NS_REFCNT_TRACKER and regardless\nif init_net or other)\n\nSetting sk-\u0026gt;sk_net_refcnt=1 *manually* and *after* socket creation is not\nonly out of cifs scope, but also technically wrong -- it\u0026apos;s set conditionally\nbased on user (=1) vs kernel (=0) sockets.  And net/ implementations\nseem to base their user vs kernel space operations on it.\n\ne.g. upon TCP socket close, the TCP timers are not cleared because\nsk-\u0026gt;sk_net_refcnt=1:\n(cf. commit 151c9c724d05 (\u0026quot;tcp: properly terminate timers for kernel sockets\u0026quot;))\n\nnet/ipv4/tcp.c:\n    void tcp_close(struct sock *sk, long timeout)\n    {\n    \tlock_sock(sk);\n    \t__tcp_close(sk, timeout);\n    \trelease_sock(sk);\n    \tif (!sk-\u0026gt;sk_net_refcnt)\n    \t\tinet_csk_clear_xmit_timers_sync(sk);\n    \tsock_put(sk);\n    }\n\nWhich will throw a lockdep warning and then, as expected, deadlock on\ntcp_write_timer().\n\nA way to reproduce this is by running the reproducer from ef7134c7fc48\nand then \u0026apos;rmmod cifs\u0026apos;.  A few seconds later, the deadlock/lockdep\nwarning shows up.\n\nFix:\nWe shouldn\u0026apos;t mess with socket internals ourselves, so do not set\nsk_net_refcnt manually.\n\nAlso change __sock_create() to sock_create_kern() for explicitness.\n\nAs for non-init_net network namespaces, we deal with it the best way\nwe can -- hold an extra netns reference for server-\u0026gt;ssocket and drop it\nwhen it\u0026apos;s released.  This ensures that the netns still exists whenever\nwe need to create/destroy server-\u0026gt;ssocket, but is not directly tied to\nit.(CVE-2024-54680)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: don\u0026apos;t query the device logical block size multiple times\n\nDevices block sizes may change. One of these cases is a loop device by\nusing ioctl LOOP_SET_BLOCK_SIZE.\n\nWhile this may cause other issues like IO being rejected, in the case of\nhfsplus, it will allocate a block by using that size and potentially write\nout-of-bounds when hfsplus_read_wrapper calls hfsplus_submit_bio and the\nlatter function reads a different io_size.\n\nUsing a new min_io_size initally set to sb_min_blocksize works for the\npurposes of the original fix, since it will be set to the max between\nHFSPLUS_SECTOR_SIZE and the first seen logical block size. We still use the\nmax between HFSPLUS_SECTOR_SIZE and min_io_size in case the latter is not\ninitialized.\n\nTested by mounting an hfsplus filesystem with loop block sizes 512, 1024\nand 4096.\n\nThe produced KASAN report before the fix looks like this:\n\n[  419.944641] ==================================================================\n[  419.945655] BUG: KASAN: slab-use-after-free in hfsplus_read_wrapper+0x659/0xa0a\n[  419.946703] Read of size 2 at addr ffff88800721fc00 by task repro/10678\n[  419.947612]\n[  419.947846] CPU: 0 UID: 0 PID: 10678 Comm: repro Not tainted 6.12.0-rc5-00008-gdf56e0f2f3ca #84\n[  419.949007] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014\n[  419.950035] Call Trace:\n[  419.950384]  \u0026lt;TASK\u0026gt;\n[  419.950676]  dump_stack_lvl+0x57/0x78\n[  419.951212]  ? hfsplus_read_wrapper+0x659/0xa0a\n[  419.951830]  print_report+0x14c/0x49e\n[  419.952361]  ? __virt_addr_valid+0x267/0x278\n[  419.952979]  ? kmem_cache_debug_flags+0xc/0x1d\n[  419.953561]  ? hfsplus_read_wrapper+0x659/0xa0a\n[  419.954231]  kasan_report+0x89/0xb0\n[  419.954748]  ? hfsplus_read_wrapper+0x659/0xa0a\n[  419.955367]  hfsplus_read_wrapper+0x659/0xa0a\n[  419.955948]  ? __pfx_hfsplus_read_wrapper+0x10/0x10\n[  419.956618]  ? do_raw_spin_unlock+0x59/0x1a9\n[  419.957214]  ? _raw_spin_unlock+0x1a/0x2e\n[  419.957772]  hfsplus_fill_super+0x348/0x1590\n[  419.958355]  ? hlock_class+0x4c/0x109\n[  419.958867]  ? __pfx_hfsplus_fill_super+0x10/0x10\n[  419.959499]  ? __pfx_string+0x10/0x10\n[  419.960006]  ? lock_acquire+0x3e2/0x454\n[  419.960532]  ? bdev_name.constprop.0+0xce/0x243\n[  419.961129]  ? __pfx_bdev_name.constprop.0+0x10/0x10\n[  419.961799]  ? pointer+0x3f0/0x62f\n[  419.962277]  ? __pfx_pointer+0x10/0x10\n[  419.962761]  ? vsnprintf+0x6c4/0xfba\n[  419.963178]  ? __pfx_vsnprintf+0x10/0x10\n[  419.963621]  ? setup_bdev_super+0x376/0x3b3\n[  419.964029]  ? snprintf+0x9d/0xd2\n[  419.964344]  ? __pfx_snprintf+0x10/0x10\n[  419.964675]  ? lock_acquired+0x45c/0x5e9\n[  419.965016]  ? set_blocksize+0x139/0x1c1\n[  419.965381]  ? sb_set_blocksize+0x6d/0xae\n[  419.965742]  ? __pfx_hfsplus_fill_super+0x10/0x10\n[  419.966179]  mount_bdev+0x12f/0x1bf\n[  419.966512]  ? __pfx_mount_bdev+0x10/0x10\n[  419.966886]  ? vfs_parse_fs_string+0xce/0x111\n[  419.967293]  ? __pfx_vfs_parse_fs_string+0x10/0x10\n[  419.967702]  ? __pfx_hfsplus_mount+0x10/0x10\n[  419.968073]  legacy_get_tree+0x104/0x178\n[  419.968414]  vfs_get_tree+0x86/0x296\n[  419.968751]  path_mount+0xba3/0xd0b\n[  419.969157]  ? __pfx_path_mount+0x10/0x10\n[  419.969594]  ? kmem_cache_free+0x1e2/0x260\n[  419.970311]  do_mount+0x99/0xe0\n[  419.970630]  ? __pfx_do_mount+0x10/0x10\n[  419.971008]  __do_sys_mount+0x199/0x1c9\n[  419.971397]  do_syscall_64+0xd0/0x135\n[  419.971761]  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[  419.972233] RIP: 0033:0x7c3cb812972e\n[  419.972564] Code: 48 8b 0d f5 46 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d c2 46 0d 00 f7 d8 64 89 01 48\n[  419.974371] RSP: 002b:00007ffe30632548 EFLAGS: 00000286 ORIG_RAX: 00000000000000a5\n[  419.975048] RAX: ffffffffffffffda RBX: 00007ffe306328d8 RCX: 00007c3cb812972e\n[  419.975701] RDX: 0000000020000000 RSI: 0000000020000c80 RDI:\n---truncated---(CVE-2024-56548)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\naf_packet: avoid erroring out after sock_init_data() in packet_create()\n\nAfter sock_init_data() the allocated sk object is attached to the provided\nsock object. On error, packet_create() frees the sk object leaving the\ndangling pointer in the sock object on return. Some other code may try\nto use this pointer and cause use-after-free.(CVE-2024-56606)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: sched: Disallow replacing of child qdisc from one parent to another\n\nLion Ackermann was able to create a UAF which can be abused for privilege\nescalation with the following script\n\nStep 1. create root qdisc\ntc qdisc add dev lo root handle 1:0 drr\n\nstep2. a class for packet aggregation do demonstrate uaf\ntc class add dev lo classid 1:1 drr\n\nstep3. a class for nesting\ntc class add dev lo classid 1:2 drr\n\nstep4. a class to graft qdisc to\ntc class add dev lo classid 1:3 drr\n\nstep5.\ntc qdisc add dev lo parent 1:1 handle 2:0 plug limit 1024\n\nstep6.\ntc qdisc add dev lo parent 1:2 handle 3:0 drr\n\nstep7.\ntc class add dev lo classid 3:1 drr\n\nstep 8.\ntc qdisc add dev lo parent 3:1 handle 4:0 pfifo\n\nstep 9. Display the class/qdisc layout\n\ntc class ls dev lo\n class drr 1:1 root leaf 2: quantum 64Kb\n class drr 1:2 root leaf 3: quantum 64Kb\n class drr 3:1 root leaf 4: quantum 64Kb\n\ntc qdisc ls\n qdisc drr 1: dev lo root refcnt 2\n qdisc plug 2: dev lo parent 1:1\n qdisc pfifo 4: dev lo parent 3:1 limit 1000p\n qdisc drr 3: dev lo parent 1:2\n\nstep10. trigger the bug \u0026lt;=== prevented by this patch\ntc qdisc replace dev lo parent 1:3 handle 4:0\n\nstep 11. Redisplay again the qdiscs/classes\n\ntc class ls dev lo\n class drr 1:1 root leaf 2: quantum 64Kb\n class drr 1:2 root leaf 3: quantum 64Kb\n class drr 1:3 root leaf 4: quantum 64Kb\n class drr 3:1 root leaf 4: quantum 64Kb\n\ntc qdisc ls\n qdisc drr 1: dev lo root refcnt 2\n qdisc plug 2: dev lo parent 1:1\n qdisc pfifo 4: dev lo parent 3:1 refcnt 2 limit 1000p\n qdisc drr 3: dev lo parent 1:2\n\nObserve that a) parent for 4:0 does not change despite the replace request.\nThere can only be one parent.  b) refcount has gone up by two for 4:0 and\nc) both class 1:3 and 3:1 are pointing to it.\n\nStep 12.  send one packet to plug\necho \u0026quot;\u0026quot; | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10001))\nstep13.  send one packet to the grafted fifo\necho \u0026quot;\u0026quot; | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10003))\n\nstep14. lets trigger the uaf\ntc class delete dev lo classid 1:3\ntc class delete dev lo classid 1:1\n\nThe semantics of \u0026quot;replace\u0026quot; is for a del/add _on the same node_ and not\na delete from one node(3:1) and add to another node (1:3) as in step10.\nWhile we could \u0026quot;fix\u0026quot; with a more complex approach there could be\nconsequences to expectations so the patch takes the preventive approach of\n\u0026quot;disallow such config\u0026quot;.\n\nJoint work with Lion Ackermann \u0026lt;nnamrec@gmail.com\u0026gt;(CVE-2025-21700)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npfifo_tail_enqueue: Drop new packet when sch-\u0026gt;limit == 0\n\nExpected behaviour:\nIn case we reach scheduler\u0026apos;s limit, pfifo_tail_enqueue() will drop a\npacket in scheduler\u0026apos;s queue and decrease scheduler\u0026apos;s qlen by one.\nThen, pfifo_tail_enqueue() enqueue new packet and increase\nscheduler\u0026apos;s qlen by one. Finally, pfifo_tail_enqueue() return\n`NET_XMIT_CN` status code.\n\nWeird behaviour:\nIn case we set `sch-\u0026gt;limit == 0` and trigger pfifo_tail_enqueue() on a\nscheduler that has no packet, the \u0026apos;drop a packet\u0026apos; step will do nothing.\nThis means the scheduler\u0026apos;s qlen still has value equal 0.\nThen, we continue to enqueue new packet and increase scheduler\u0026apos;s qlen by\none. In summary, we can leverage pfifo_tail_enqueue() to increase qlen by\none and return `NET_XMIT_CN` status code.\n\nThe problem is:\nLet\u0026apos;s say we have two qdiscs: Qdisc_A and Qdisc_B.\n - Qdisc_A\u0026apos;s type must have \u0026apos;-\u0026gt;graft()\u0026apos; function to create parent/child relationship.\n   Let\u0026apos;s say Qdisc_A\u0026apos;s type is `hfsc`. Enqueue packet to this qdisc will trigger `hfsc_enqueue`.\n - Qdisc_B\u0026apos;s type is pfifo_head_drop. Enqueue packet to this qdisc will trigger `pfifo_tail_enqueue`.\n - Qdisc_B is configured to have `sch-\u0026gt;limit == 0`.\n - Qdisc_A is configured to route the enqueued\u0026apos;s packet to Qdisc_B.\n\nEnqueue packet through Qdisc_A will lead to:\n - hfsc_enqueue(Qdisc_A) -\u0026gt; pfifo_tail_enqueue(Qdisc_B)\n - Qdisc_B-\u0026gt;q.qlen += 1\n - pfifo_tail_enqueue() return `NET_XMIT_CN`\n - hfsc_enqueue() check for `NET_XMIT_SUCCESS` and see `NET_XMIT_CN` =\u0026gt; hfsc_enqueue() don\u0026apos;t increase qlen of Qdisc_A.\n\nThe whole process lead to a situation where Qdisc_A-\u0026gt;q.qlen == 0 and Qdisc_B-\u0026gt;q.qlen == 1.\nReplace \u0026apos;hfsc\u0026apos; with other type (for example: \u0026apos;drr\u0026apos;) still lead to the same problem.\nThis violate the design where parent\u0026apos;s qlen should equal to the sum of its childrens\u0026apos;qlen.\n\nBug impact: This issue can be used for user-\u0026gt;kernel privilege escalation when it is reachable.(CVE-2025-21702)",
  "id": "OESA-2025-1282",
  "modified": "2026-08-06T11:08:22Z",
  "published": "2025-03-14T11:08:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1282"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47631"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47642"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49044"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49055"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49114"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49137"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49253"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49308"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49326"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49341"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49351"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49404"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49433"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49439"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49447"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49526"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49564"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49620"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49648"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49661"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49685"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52572"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-54680"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56548"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56606"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21700"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21702"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2021-47631",
    "CVE-2021-47642",
    "CVE-2022-49044",
    "CVE-2022-49055",
    "CVE-2022-49114",
    "CVE-2022-49137",
    "CVE-2022-49253",
    "CVE-2022-49308",
    "CVE-2022-49326",
    "CVE-2022-49341",
    "CVE-2022-49351",
    "CVE-2022-49404",
    "CVE-2022-49433",
    "CVE-2022-49439",
    "CVE-2022-49447",
    "CVE-2022-49526",
    "CVE-2022-49564",
    "CVE-2022-49620",
    "CVE-2022-49648",
    "CVE-2022-49661",
    "CVE-2022-49685",
    "CVE-2023-52572",
    "CVE-2024-54680",
    "CVE-2024-56548",
    "CVE-2024-56606",
    "CVE-2025-21700",
    "CVE-2025-21702"
  ]
}

RHSA-2023:2458

Vulnerability from csaf_redhat - Published: 2023-05-09 10:04 - Updated: 2026-11-11 18:40

Summary

Red Hat Security Advisory: kernel security, bug fix, and enhancement update

Severity

Important

Scope

409 vulnerabilities in this advisory, including CVE-2022-49114.

CVE-2022-49114

A vulnerability was found in the Linux kernel's SCSI libfc library in the `fc_exch_abts_resp()` function, which can lead to a use-after-free scenario. This issue can occur because the function calls `fc_exch_release()`, which decrements a reference count stored in the `ep` object and then frees the object once the count is zero. However, the `ep` object is referenced again and can result in the now-freed `ep` pointer being accessed, resulting in system instability, memory corruption, and potential arbitrary code execution.

7.0 (High)


                
                  CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

Fixed: 201 products

https://access.redhat.com/errata/RHSA-2023:2458

Open the full advisory

RHSA-2023:2951

Vulnerability from csaf_redhat - Published: 2023-05-16 08:56 - Updated: 2026-11-11 18:42

Summary

Red Hat Security Advisory: kernel security, bug fix, and enhancement update

Severity

Important

Scope

199 vulnerabilities in this advisory, including CVE-2022-49114.

CVE-2022-49114

7.0 (High)


                
                  CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

Fixed: 120 products

https://access.redhat.com/errata/RHSA-2023:2951

Open the full advisory

RHSA-2025:10005

Vulnerability from csaf_redhat - Published: 2025-07-01 00:41 - Updated: 2026-11-09 22:44

Summary

Red Hat Security Advisory: kernel security update

Severity

Moderate

Scope

3 vulnerabilities in this advisory, including CVE-2022-49114.

CVE-2022-49114

7.0 (High)


                
                  CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

Fixed: 25 products

https://access.redhat.com/errata/RHSA-2025:10005

Open the full advisory

RHSA-2025:10009

Vulnerability from csaf_redhat - Published: 2025-07-01 01:11 - Updated: 2026-11-09 22:45

Summary

Red Hat Security Advisory: kernel security update

Severity

Moderate

Scope

2 vulnerabilities in this advisory, including CVE-2022-49114.

CVE-2022-49114

7.0 (High)


                
                  CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

Fixed: 146 products

https://access.redhat.com/errata/RHSA-2025:10009

Open the full advisory

RHSA-2025:10174

Vulnerability from csaf_redhat - Published: 2025-07-01 22:46 - Updated: 2026-11-09 22:45

Summary

Red Hat Security Advisory: kernel security update

Severity

Moderate

Scope

5 vulnerabilities in this advisory, including CVE-2022-49114.

CVE-2022-49114

7.0 (High)


                
                  CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

Fixed: 134 products

https://access.redhat.com/errata/RHSA-2025:10174

Open the full advisory

RHSA-2025:10179

Vulnerability from csaf_redhat - Published: 2025-07-02 04:39 - Updated: 2026-11-09 22:44

Summary

Red Hat Security Advisory: kernel security update

Severity

Moderate

Scope

5 vulnerabilities in this advisory, including CVE-2022-49114.

CVE-2022-49114

7.0 (High)


                
                  CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

Fixed: 25 products

https://access.redhat.com/errata/RHSA-2025:10179

Open the full advisory

RHSA-2025:10193

Vulnerability from csaf_redhat - Published: 2025-07-02 06:48 - Updated: 2026-11-09 22:45

Summary

Red Hat Security Advisory: kernel-rt security update

Severity

Moderate

Scope

5 vulnerabilities in this advisory, including CVE-2022-49114.

CVE-2022-49114

7.0 (High)


                
                  CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

Fixed: 30 products

https://access.redhat.com/errata/RHSA-2025:10193

Open the full advisory

SUSE-SU-2025:1027-1

Vulnerability from csaf_suse - Published: 2025-03-26 12:12 - Updated: 2025-03-26 12:12

Summary

Security update for the Linux Kernel

Severity

Important

Scope

468 vulnerabilities in this advisory, including CVE-2022-49114.

CVE-2022-49114

6.7 (Medium)


                
                  CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H

Recommended: 139 products

Open the full advisory

SUSE-SU-2025:1176-1

Vulnerability from csaf_suse - Published: 2025-04-08 15:35 - Updated: 2026-11-01 10:34

Summary

Security update for the Linux Kernel

Severity

Important

Scope

605 vulnerabilities in this advisory, including CVE-2022-49114.

CVE-2022-49114

6.7 (Medium)


                
                  CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H

Recommended: 3 products

Open the full advisory

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

CVE-2022-49114 (GCVE-0-2022-49114)

OESA-2025-1282 (CVE-2021-47631)

Tags

Sightings

Nomenclature

Vulnerability timeline

Related by attack behaviour