{
  "affected": [
    {
      "affectedData": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/net/wireless/marvell/mwifiex/uap_txrx.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "d155c5f64cefacdc6a9a26d40be53ee2903c28ff",
              "status": "affected",
              "version": "838e4f44929782a2163c7bc95a7cd2da5d8b47f9",
              "versionType": "git"
            },
            {
              "lessThan": "139d285e7695279f030dbb172e2d0245425c86c6",
              "status": "affected",
              "version": "838e4f44929782a2163c7bc95a7cd2da5d8b47f9",
              "versionType": "git"
            },
            {
              "lessThan": "231086e6a36316b823654f4535653f22d6344420",
              "status": "affected",
              "version": "838e4f44929782a2163c7bc95a7cd2da5d8b47f9",
              "versionType": "git"
            },
            {
              "lessThan": "bef85d58f7709896ed8426560ad117a73a37762f",
              "status": "affected",
              "version": "838e4f44929782a2163c7bc95a7cd2da5d8b47f9",
              "versionType": "git"
            },
            {
              "lessThan": "d7fd24b8d1bb54c5bcf583139e11a5e651e0263c",
              "status": "affected",
              "version": "838e4f44929782a2163c7bc95a7cd2da5d8b47f9",
              "versionType": "git"
            },
            {
              "lessThan": "7e7197e4d6a1bc72a774590d8765909f898be1dc",
              "status": "affected",
              "version": "838e4f44929782a2163c7bc95a7cd2da5d8b47f9",
              "versionType": "git"
            },
            {
              "lessThan": "0c57f9ad2c3ed43abb764b0247d610ff7fdb7a00",
              "status": "affected",
              "version": "838e4f44929782a2163c7bc95a7cd2da5d8b47f9",
              "versionType": "git"
            },
            {
              "lessThan": "c2509f7c37355e1f0bd5b7087815b845fd383723",
              "status": "affected",
              "version": "838e4f44929782a2163c7bc95a7cd2da5d8b47f9",
              "versionType": "git"
            },
            {
              "lessThan": "35a7a1ce7c7d61664ee54f5239a1f120ab95a87e",
              "status": "affected",
              "version": "838e4f44929782a2163c7bc95a7cd2da5d8b47f9",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/net/wireless/marvell/mwifiex/uap_txrx.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "3.7"
            },
            {
              "lessThan": "3.7",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.14.*",
              "status": "unaffected",
              "version": "4.14.326",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.19.*",
              "status": "unaffected",
              "version": "4.19.295",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.4.*",
              "status": "unaffected",
              "version": "5.4.257",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.10.*",
              "status": "unaffected",
              "version": "5.10.195",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.15.*",
              "status": "unaffected",
              "version": "5.15.132",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.53",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.4.*",
              "status": "unaffected",
              "version": "6.4.16",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.5.*",
              "status": "unaffected",
              "version": "6.5.3",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.6",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    }
  ],
  "configurations": [
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "8EA40812-FC7E-414C-88CF-616A1BECABF8",
              "versionEndExcluding": "4.14.326",
              "versionStartIncluding": "3.7",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "D419C7D6-F33D-4EF8-8950-1CB5DDF6A55D",
              "versionEndExcluding": "4.19.295",
              "versionStartIncluding": "4.15",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "834BD148-28EC-43A4-A4F5-458124A1E39F",
              "versionEndExcluding": "5.4.257",
              "versionStartIncluding": "4.20",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "C385B650-53DB-4BFB-83D1-1D8FADF653EF",
              "versionEndExcluding": "5.10.195",
              "versionStartIncluding": "5.5",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "5913891D-409A-4EEC-9231-F2EF5A493BC7",
              "versionEndExcluding": "5.15.132",
              "versionStartIncluding": "5.11",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "B20754AF-3B8C-4574-A70D-EC24933810E5",
              "versionEndExcluding": "6.1.53",
              "versionStartIncluding": "5.16",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "C3039EA3-F6CA-43EF-9F17-81A7EC6841EF",
              "versionEndExcluding": "6.4.16",
              "versionStartIncluding": "6.2",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "880C803A-BEAE-4DA0-8A59-AC023F7B4EE3",
              "versionEndExcluding": "6.5.3",
              "versionStartIncluding": "6.5",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mwifiex: avoid possible NULL skb pointer dereference\n\nIn \u0027mwifiex_handle_uap_rx_forward()\u0027, always check the value\nreturned by \u0027skb_copy()\u0027 to avoid potential NULL pointer\ndereference in \u0027mwifiex_uap_queue_bridged_pkt()\u0027, and drop\noriginal skb in case of copying failure.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE."
    }
  ],
  "id": "CVE-2023-53384",
  "lastModified": "2026-06-17T06:45:10.347",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "LOCAL",
          "availabilityImpact": "HIGH",
          "baseScore": 5.5,
          "baseSeverity": "MEDIUM",
          "confidentialityImpact": "NONE",
          "integrityImpact": "NONE",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 1.8,
        "impactScore": 3.6,
        "source": "nvd@nist.gov",
        "type": "Primary"
      },
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "LOCAL",
          "availabilityImpact": "HIGH",
          "baseScore": 5.5,
          "baseSeverity": "MEDIUM",
          "confidentialityImpact": "NONE",
          "integrityImpact": "NONE",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 1.8,
        "impactScore": 3.6,
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "type": "Secondary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2023-53384",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2026-01-14T18:57:13.035071Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2025-09-18T14:15:41.433",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/0c57f9ad2c3ed43abb764b0247d610ff7fdb7a00"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/139d285e7695279f030dbb172e2d0245425c86c6"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/231086e6a36316b823654f4535653f22d6344420"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/35a7a1ce7c7d61664ee54f5239a1f120ab95a87e"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/7e7197e4d6a1bc72a774590d8765909f898be1dc"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/bef85d58f7709896ed8426560ad117a73a37762f"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/c2509f7c37355e1f0bd5b7087815b845fd383723"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/d155c5f64cefacdc6a9a26d40be53ee2903c28ff"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/d7fd24b8d1bb54c5bcf583139e11a5e651e0263c"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Modified",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-476"
        }
      ],
      "source": "nvd@nist.gov",
      "type": "Primary"
    },
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-476"
        }
      ],
      "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
      "type": "Secondary"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2023-53384"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-18T14:15:41Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mwifiex: avoid possible NULL skb pointer dereference\n\nIn \u0027mwifiex_handle_uap_rx_forward()\u0027, always check the value\nreturned by \u0027skb_copy()\u0027 to avoid potential NULL pointer\ndereference in \u0027mwifiex_uap_queue_bridged_pkt()\u0027, and drop\noriginal skb in case of copying failure.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.",
  "id": "GHSA-jhfh-g9jf-gfpv",
  "modified": "2025-12-11T18:30:34Z",
  "published": "2025-09-18T15:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53384"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0c57f9ad2c3ed43abb764b0247d610ff7fdb7a00"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/139d285e7695279f030dbb172e2d0245425c86c6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/231086e6a36316b823654f4535653f22d6344420"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/35a7a1ce7c7d61664ee54f5239a1f120ab95a87e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7e7197e4d6a1bc72a774590d8765909f898be1dc"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/bef85d58f7709896ed8426560ad117a73a37762f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c2509f7c37355e1f0bd5b7087815b845fd383723"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d155c5f64cefacdc6a9a26d40be53ee2903c28ff"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d7fd24b8d1bb54c5bcf583139e11a5e651e0263c"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "kernel-5.10.0-284.0.0.186.oe2203sp3.aarch64.rpm",
          "kernel-debuginfo-5.10.0-284.0.0.186.oe2203sp3.aarch64.rpm",
          "kernel-debugsource-5.10.0-284.0.0.186.oe2203sp3.aarch64.rpm",
          "kernel-devel-5.10.0-284.0.0.186.oe2203sp3.aarch64.rpm",
          "kernel-headers-5.10.0-284.0.0.186.oe2203sp3.aarch64.rpm",
          "kernel-source-5.10.0-284.0.0.186.oe2203sp3.aarch64.rpm",
          "kernel-tools-5.10.0-284.0.0.186.oe2203sp3.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-284.0.0.186.oe2203sp3.aarch64.rpm",
          "kernel-tools-devel-5.10.0-284.0.0.186.oe2203sp3.aarch64.rpm",
          "perf-5.10.0-284.0.0.186.oe2203sp3.aarch64.rpm",
          "perf-debuginfo-5.10.0-284.0.0.186.oe2203sp3.aarch64.rpm",
          "python3-perf-5.10.0-284.0.0.186.oe2203sp3.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-284.0.0.186.oe2203sp3.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-284.0.0.186.oe2203sp3.src.rpm"
        ],
        "x86_64": [
          "kernel-5.10.0-284.0.0.186.oe2203sp3.x86_64.rpm",
          "kernel-debuginfo-5.10.0-284.0.0.186.oe2203sp3.x86_64.rpm",
          "kernel-debugsource-5.10.0-284.0.0.186.oe2203sp3.x86_64.rpm",
          "kernel-devel-5.10.0-284.0.0.186.oe2203sp3.x86_64.rpm",
          "kernel-headers-5.10.0-284.0.0.186.oe2203sp3.x86_64.rpm",
          "kernel-source-5.10.0-284.0.0.186.oe2203sp3.x86_64.rpm",
          "kernel-tools-5.10.0-284.0.0.186.oe2203sp3.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-284.0.0.186.oe2203sp3.x86_64.rpm",
          "kernel-tools-devel-5.10.0-284.0.0.186.oe2203sp3.x86_64.rpm",
          "perf-5.10.0-284.0.0.186.oe2203sp3.x86_64.rpm",
          "perf-debuginfo-5.10.0-284.0.0.186.oe2203sp3.x86_64.rpm",
          "python3-perf-5.10.0-284.0.0.186.oe2203sp3.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-284.0.0.186.oe2203sp3.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP3",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.10.0-284.0.0.186.oe2203sp3"
            }
          ],
          "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\nnet: dsa: Avoid cross-chip syncing of VLAN filtering\n\nChanges to VLAN filtering are not applicable to cross-chip\nnotifications.\n\nOn a system like this:\n\n.-----.   .-----.   .-----.\n| sw1 +---+ sw2 +---+ sw3 |\n\u0026apos;-1-2-\u0026apos;   \u0026apos;-1-2-\u0026apos;   \u0026apos;-1-2-\u0026apos;\n\nBefore this change, upon sw1p1 leaving a bridge, a call to\ndsa_port_vlan_filtering would also be made to sw2p1 and sw3p1.\n\nIn this scenario:\n\n.---------.   .-----.   .-----.\n|   sw1   +---+ sw2 +---+ sw3 |\n\u0026apos;-1-2-3-4-\u0026apos;   \u0026apos;-1-2-\u0026apos;   \u0026apos;-1-2-\u0026apos;\n\nWhen sw1p4 would leave a bridge, dsa_port_vlan_filtering would be\ncalled for sw2 and sw3 with a non-existing port - leading to array\nout-of-bounds accesses and crashes on mv88e6xxx.(CVE-2022-49234)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: iscsi: Fix a race condition between login_work and the login thread\n\nIn case a malicious initiator sends some random data immediately after a\nlogin PDU; the iscsi_target_sk_data_ready() callback will schedule the\nlogin_work and, at the same time, the negotiation may end without clearing\nthe LOGIN_FLAGS_INITIAL_PDU flag (because no additional PDU exchanges are\nrequired to complete the login).\n\nThe login has been completed but the login_work function will find the\nLOGIN_FLAGS_INITIAL_PDU flag set and will never stop from rescheduling\nitself; at this point, if the initiator drops the connection, the\niscsit_conn structure will be freed, login_work will dereference a released\nsocket structure and the kernel crashes.\n\nBUG: kernel NULL pointer dereference, address: 0000000000000230\nPF: supervisor write access in kernel mode\nPF: error_code(0x0002) - not-present page\nWorkqueue: events iscsi_target_do_login_rx [iscsi_target_mod]\nRIP: 0010:_raw_read_lock_bh+0x15/0x30\nCall trace:\n iscsi_target_do_login_rx+0x75/0x3f0 [iscsi_target_mod]\n process_one_work+0x1e8/0x3c0\n\nFix this bug by forcing login_work to stop after the login has been\ncompleted and the socket callbacks have been restored.\n\nAdd a comment to clearify the return values of iscsi_target_do_login()(CVE-2022-50350)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: fbcon: release buffer when fbcon_do_set_font() failed\n\nsyzbot is reporting memory leak at fbcon_do_set_font() [1], for\ncommit a5a923038d70 (\u0026quot;fbdev: fbcon: Properly revert changes when\nvc_resize() failed\u0026quot;) missed that the buffer might be newly allocated\nby fbcon_set_font().(CVE-2022-50404)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nudf: Fix uninitialized array access for some pathnames\n\nFor filenames that begin with . and are between 2 and 5 characters long,\nUDF charset conversion code would read uninitialized memory in the\noutput buffer. The only practical impact is that the name may be prepended a\n\u0026quot;unification hash\u0026quot; when it is not actually needed but still it is good\nto fix this.(CVE-2023-53165)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: call op_release, even when op_func returns an error\n\nFor ops with \u0026quot;trivial\u0026quot; replies, nfsd4_encode_operation will shortcut\nmost of the encoding work and skip to just marshalling up the status.\nOne of the things it skips is calling op_release. This could cause a\nmemory leak in the layoutget codepath if there is an error at an\ninopportune time.\n\nHave the compound processing engine always call op_release, even when\nop_func sets an error in op-\u0026gt;status. With this change, we also need\nnfsd4_block_get_device_info_scsi to set the gd_device pointer to NULL\non error to avoid a double free.(CVE-2023-53241)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nVMCI: check context-\u0026gt;notify_page after call to get_user_pages_fast() to avoid GPF\n\nThe call to get_user_pages_fast() in vmci_host_setup_notify() can return\nNULL context-\u0026gt;notify_page causing a GPF. To avoid GPF check if\ncontext-\u0026gt;notify_page == NULL and return error if so.\n\ngeneral protection fault, probably for non-canonical address\n    0xe0009d1000000060: 0000 [#1] PREEMPT SMP KASAN NOPTI\nKASAN: maybe wild-memory-access in range [0x0005088000000300-\n    0x0005088000000307]\nCPU: 2 PID: 26180 Comm: repro_34802241 Not tainted 6.1.0-rc4 #1\nHardware name: Red Hat KVM, BIOS 1.15.0-2.module+el8.6.0 04/01/2014\nRIP: 0010:vmci_ctx_check_signal_notify+0x91/0xe0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n vmci_host_unlocked_ioctl+0x362/0x1f40\n __x64_sys_ioctl+0x1a1/0x230\n do_syscall_64+0x3a/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd(CVE-2023-53259)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: hda: fix a possible null-pointer dereference due to data race in snd_hdac_regmap_sync()\n\nThe variable codec-\u0026gt;regmap is often protected by the lock\ncodec-\u0026gt;regmap_lock when is accessed. However, it is accessed without\nholding the lock when is accessed in snd_hdac_regmap_sync():\n\n  if (codec-\u0026gt;regmap)\n\nIn my opinion, this may be a harmful race, because if codec-\u0026gt;regmap is\nset to NULL right after the condition is checked, a null-pointer\ndereference can occur in the called function regcache_sync():\n\n  map-\u0026gt;lock(map-\u0026gt;lock_arg); --\u0026gt; Line 360 in drivers/base/regmap/regcache.c\n\nTo fix this possible null-pointer dereference caused by data race, the\nmutex_lock coverage is extended to protect the if statement as well as the\nfunction call to regcache_sync().\n\n[ Note: the lack of the regmap_lock itself is harmless for the current\n  codec driver implementations, as snd_hdac_regmap_sync() is only for\n  PM runtime resume that is prohibited during the codec probe.\n  But the change makes the whole code more consistent, so it\u0026apos;s merged\n  as is -- tiwai ](CVE-2023-53275)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Return the firmware result upon destroying QP/RQ\n\nPreviously when destroying a QP/RQ, the result of the firmware\ndestruction function was ignored and upper layers weren\u0026apos;t informed\nabout the failure.\nWhich in turn could lead to various problems since when upper layer\nisn\u0026apos;t aware of the failure it continues its operation thinking that the\nrelated QP/RQ was successfully destroyed while it actually wasn\u0026apos;t,\nwhich could lead to the below kernel WARN.\n\nCurrently, we return the correct firmware destruction status to upper\nlayers which in case of the RQ would be mlx5_ib_destroy_wq() which\nwas already capable of handling RQ destruction failure or in case of\na QP to destroy_qp_common(), which now would actually warn upon qp\ndestruction failure.\n\nWARNING: CPU: 3 PID: 995 at drivers/infiniband/core/rdma_core.c:940 uverbs_destroy_ufile_hw+0xcb/0xe0 [ib_uverbs]\nModules linked in: xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_umad ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core overlay mlx5_core fuse\nCPU: 3 PID: 995 Comm: python3 Not tainted 5.16.0-rc5+ #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\nRIP: 0010:uverbs_destroy_ufile_hw+0xcb/0xe0 [ib_uverbs]\nCode: 41 5c 41 5d 41 5e e9 44 34 f0 e0 48 89 df e8 4c 77 ff ff 49 8b 86 10 01 00 00 48 85 c0 74 a1 4c 89 e7 ff d0 eb 9a 0f 0b eb c1 \u0026lt;0f\u0026gt; 0b be 04 00 00 00 48 89 df e8 b6 f6 ff ff e9 75 ff ff ff 90 0f\nRSP: 0018:ffff8881533e3e78 EFLAGS: 00010287\nRAX: ffff88811b2cf3e0 RBX: ffff888106209700 RCX: 0000000000000000\nRDX: ffff888106209780 RSI: ffff8881533e3d30 RDI: ffff888109b101a0\nRBP: 0000000000000001 R08: ffff888127cb381c R09: 0de9890000000009\nR10: ffff888127cb3800 R11: 0000000000000000 R12: ffff888106209780\nR13: ffff888106209750 R14: ffff888100f20660 R15: 0000000000000000\nFS:  00007f8be353b740(0000) GS:ffff88852c980000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f8bd5b117c0 CR3: 000000012cd8a004 CR4: 0000000000370ea0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ib_uverbs_close+0x1a/0x90 [ib_uverbs]\n __fput+0x82/0x230\n task_work_run+0x59/0x90\n exit_to_user_mode_prepare+0x138/0x140\n syscall_exit_to_user_mode+0x1d/0x50\n ? __x64_sys_close+0xe/0x40\n do_syscall_64+0x4a/0x90\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x7f8be3ae0abb\nCode: 03 00 00 00 0f 05 48 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 83 43 f9 ff 8b 7c 24 0c 41 89 c0 b8 03 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 35 44 89 c7 89 44 24 0c e8 c1 43 f9 ff 8b 44\nRSP: 002b:00007ffdb51909c0 EFLAGS: 00000293 ORIG_RAX: 0000000000000003\nRAX: 0000000000000000 RBX: 0000557bb7f7c020 RCX: 00007f8be3ae0abb\nRDX: 0000557bb7c74010 RSI: 0000557bb7f14ca0 RDI: 0000000000000005\nRBP: 0000557bb7fbd598 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000293 R12: 0000557bb7fbd5b8\nR13: 0000557bb7fbd5a8 R14: 0000000000001000 R15: 0000557bb7f7c020\n \u0026lt;/TASK\u0026gt;(CVE-2023-53286)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npstore/ram: Check start of empty przs during init\n\nAfter commit 30696378f68a (\u0026quot;pstore/ram: Do not treat empty buffers as\nvalid\u0026quot;), initialization would assume a prz was valid after seeing that\nthe buffer_size is zero (regardless of the buffer start position). This\nunchecked start value means it could be outside the bounds of the buffer,\nleading to future access panics when written to:\n\n sysdump_panic_event+0x3b4/0x5b8\n atomic_notifier_call_chain+0x54/0x90\n panic+0x1c8/0x42c\n die+0x29c/0x2a8\n die_kernel_fault+0x68/0x78\n __do_kernel_fault+0x1c4/0x1e0\n do_bad_area+0x40/0x100\n do_translation_fault+0x68/0x80\n do_mem_abort+0x68/0xf8\n el1_da+0x1c/0xc0\n __raw_writeb+0x38/0x174\n __memcpy_toio+0x40/0xac\n persistent_ram_update+0x44/0x12c\n persistent_ram_write+0x1a8/0x1b8\n ramoops_pstore_write+0x198/0x1e8\n pstore_console_write+0x94/0xe0\n ...\n\nTo avoid this, also check if the prz start is 0 during the initialization\nphase. If not, the next prz sanity check case will discover it (start \u0026gt;\nsize) and zap the buffer back to a sane state.\n\n[kees: update commit log with backtrace and clarifications](CVE-2023-53331)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: dcb: choose correct policy to parse DCB_ATTR_BCN\n\nThe dcbnl_bcn_setcfg uses erroneous policy to parse tb[DCB_ATTR_BCN],\nwhich is introduced in commit 859ee3c43812 (\u0026quot;DCB: Add support for DCB\nBCN\u0026quot;). Please see the comment in below code\n\nstatic int dcbnl_bcn_setcfg(...)\n{\n  ...\n  ret = nla_parse_nested_deprecated(..., dcbnl_pfc_up_nest, .. )\n  // !!! dcbnl_pfc_up_nest for attributes\n  //  DCB_PFC_UP_ATTR_0 to DCB_PFC_UP_ATTR_ALL in enum dcbnl_pfc_up_attrs\n  ...\n  for (i = DCB_BCN_ATTR_RP_0; i \u0026lt;= DCB_BCN_ATTR_RP_7; i++) {\n  // !!! DCB_BCN_ATTR_RP_0 to DCB_BCN_ATTR_RP_7 in enum dcbnl_bcn_attrs\n    ...\n    value_byte = nla_get_u8(data[i]);\n    ...\n  }\n  ...\n  for (i = DCB_BCN_ATTR_BCNA_0; i \u0026lt;= DCB_BCN_ATTR_RI; i++) {\n  // !!! DCB_BCN_ATTR_BCNA_0 to DCB_BCN_ATTR_RI in enum dcbnl_bcn_attrs\n  ...\n    value_int = nla_get_u32(data[i]);\n  ...\n  }\n  ...\n}\n\nThat is, the nla_parse_nested_deprecated uses dcbnl_pfc_up_nest\nattributes to parse nlattr defined in dcbnl_pfc_up_attrs. But the\nfollowing access code fetch each nlattr as dcbnl_bcn_attrs attributes.\nBy looking up the associated nla_policy for dcbnl_bcn_attrs. We can find\nthe beginning part of these two policies are \u0026quot;same\u0026quot;.\n\nstatic const struct nla_policy dcbnl_pfc_up_nest[...] = {\n        [DCB_PFC_UP_ATTR_0]   = {.type = NLA_U8},\n        [DCB_PFC_UP_ATTR_1]   = {.type = NLA_U8},\n        [DCB_PFC_UP_ATTR_2]   = {.type = NLA_U8},\n        [DCB_PFC_UP_ATTR_3]   = {.type = NLA_U8},\n        [DCB_PFC_UP_ATTR_4]   = {.type = NLA_U8},\n        [DCB_PFC_UP_ATTR_5]   = {.type = NLA_U8},\n        [DCB_PFC_UP_ATTR_6]   = {.type = NLA_U8},\n        [DCB_PFC_UP_ATTR_7]   = {.type = NLA_U8},\n        [DCB_PFC_UP_ATTR_ALL] = {.type = NLA_FLAG},\n};\n\nstatic const struct nla_policy dcbnl_bcn_nest[...] = {\n        [DCB_BCN_ATTR_RP_0]         = {.type = NLA_U8},\n        [DCB_BCN_ATTR_RP_1]         = {.type = NLA_U8},\n        [DCB_BCN_ATTR_RP_2]         = {.type = NLA_U8},\n        [DCB_BCN_ATTR_RP_3]         = {.type = NLA_U8},\n        [DCB_BCN_ATTR_RP_4]         = {.type = NLA_U8},\n        [DCB_BCN_ATTR_RP_5]         = {.type = NLA_U8},\n        [DCB_BCN_ATTR_RP_6]         = {.type = NLA_U8},\n        [DCB_BCN_ATTR_RP_7]         = {.type = NLA_U8},\n        [DCB_BCN_ATTR_RP_ALL]       = {.type = NLA_FLAG},\n        // from here is somewhat different\n        [DCB_BCN_ATTR_BCNA_0]       = {.type = NLA_U32},\n        ...\n        [DCB_BCN_ATTR_ALL]          = {.type = NLA_FLAG},\n};\n\nTherefore, the current code is buggy and this\nnla_parse_nested_deprecated could overflow the dcbnl_pfc_up_nest and use\nthe adjacent nla_policy to parse attributes from DCB_BCN_ATTR_BCNA_0.\n\nHence use the correct policy dcbnl_bcn_nest to parse the nested\ntb[DCB_ATTR_BCN] TLV.(CVE-2023-53369)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mwifiex: avoid possible NULL skb pointer dereference\n\nIn \u0026apos;mwifiex_handle_uap_rx_forward()\u0026apos;, always check the value\nreturned by \u0026apos;skb_copy()\u0026apos; to avoid potential NULL pointer\ndereference in \u0026apos;mwifiex_uap_queue_bridged_pkt()\u0026apos;, and drop\noriginal skb in case of copying failure.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-53384)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: Add AML_NO_OPERAND_RESOLVE flag to Timer\n\nACPICA commit 90310989a0790032f5a0140741ff09b545af4bc5\n\nAccording to the ACPI specification 19.6.134, no argument is required to be passed for ASL Timer instruction. For taking care of no argument, AML_NO_OPERAND_RESOLVE flag is added to ASL Timer instruction opcode.\n\nWhen ASL timer instruction interpreted by ACPI interpreter, getting error. After adding AML_NO_OPERAND_RESOLVE flag to ASL Timer instruction opcode, issue is not observed.\n\n=============================================================\nUBSAN: array-index-out-of-bounds in acpica/dswexec.c:401:12 index -1 is out of range for type \u0026apos;union acpi_operand_object *[9]\u0026apos;\nCPU: 37 PID: 1678 Comm: cat Not tainted\n6.0.0-dev-th500-6.0.y-1+bcf8c46459e407-generic-64k\nHW name: NVIDIA BIOS v1.1.1-d7acbfc-dirty 12/19/2022 Call trace:\n dump_backtrace+0xe0/0x130\n show_stack+0x20/0x60\n dump_stack_lvl+0x68/0x84\n dump_stack+0x18/0x34\n ubsan_epilogue+0x10/0x50\n __ubsan_handle_out_of_bounds+0x80/0x90\n acpi_ds_exec_end_op+0x1bc/0x6d8\n acpi_ps_parse_loop+0x57c/0x618\n acpi_ps_parse_aml+0x1e0/0x4b4\n acpi_ps_execute_method+0x24c/0x2b8\n acpi_ns_evaluate+0x3a8/0x4bc\n acpi_evaluate_object+0x15c/0x37c\n acpi_evaluate_integer+0x54/0x15c\n show_power+0x8c/0x12c [acpi_power_meter](CVE-2023-53395)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/MCE: Always save CS register on AMD Zen IF Poison errors\n\nThe Instruction Fetch (IF) units on current AMD Zen-based systems do not\nguarantee a synchronous #MC is delivered for poison consumption errors.\nTherefore, MCG_STATUS[EIPV|RIPV] will not be set. However, the\nmicroarchitecture does guarantee that the exception is delivered within\nthe same context. In other words, the exact rIP is not known, but the\ncontext is known to not have changed.\n\nThere is no architecturally-defined method to determine this behavior.\n\nThe Code Segment (CS) register is always valid on such IF unit poison\nerrors regardless of the value of MCG_STATUS[EIPV|RIPV].\n\nAdd a quirk to save the CS register for poison consumption from the IF\nunit banks.\n\nThis is needed to properly determine the context of the error.\nOtherwise, the severity grading function will assume the context is\nIN_KERNEL due to the m-\u0026gt;cs value being 0 (the initialized value). This\nleads to unnecessary kernel panics on data poison errors due to the\nkernel believing the poison consumption occurred in kernel context.(CVE-2023-53438)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ravb: Fix missing rtnl lock in suspend/resume path\n\nFix the suspend/resume path by ensuring the rtnl lock is held where\nrequired. Calls to ravb_open, ravb_close and wol operations must be\nperformed under the rtnl lock to prevent conflicts with ongoing ndo\noperations.\n\nWithout this fix, the following warning is triggered:\n[   39.032969] =============================\n[   39.032983] WARNING: suspicious RCU usage\n[   39.033019] -----------------------------\n[   39.033033] drivers/net/phy/phy_device.c:2004 suspicious\nrcu_dereference_protected() usage!\n...\n[   39.033597] stack backtrace:\n[   39.033613] CPU: 0 UID: 0 PID: 174 Comm: python3 Not tainted\n6.13.0-rc7-next-20250116-arm64-renesas-00002-g35245dfdc62c #7\n[   39.033623] Hardware name: Renesas SMARC EVK version 2 based on\nr9a08g045s33 (DT)\n[   39.033628] Call trace:\n[   39.033633]  show_stack+0x14/0x1c (C)\n[   39.033652]  dump_stack_lvl+0xb4/0xc4\n[   39.033664]  dump_stack+0x14/0x1c\n[   39.033671]  lockdep_rcu_suspicious+0x16c/0x22c\n[   39.033682]  phy_detach+0x160/0x190\n[   39.033694]  phy_disconnect+0x40/0x54\n[   39.033703]  ravb_close+0x6c/0x1cc\n[   39.033714]  ravb_suspend+0x48/0x120\n[   39.033721]  dpm_run_callback+0x4c/0x14c\n[   39.033731]  device_suspend+0x11c/0x4dc\n[   39.033740]  dpm_suspend+0xdc/0x214\n[   39.033748]  dpm_suspend_start+0x48/0x60\n[   39.033758]  suspend_devices_and_enter+0x124/0x574\n[   39.033769]  pm_suspend+0x1ac/0x274\n[   39.033778]  state_store+0x88/0x124\n[   39.033788]  kobj_attr_store+0x14/0x24\n[   39.033798]  sysfs_kf_write+0x48/0x6c\n[   39.033808]  kernfs_fop_write_iter+0x118/0x1a8\n[   39.033817]  vfs_write+0x27c/0x378\n[   39.033825]  ksys_write+0x64/0xf4\n[   39.033833]  __arm64_sys_write+0x18/0x20\n[   39.033841]  invoke_syscall+0x44/0x104\n[   39.033852]  el0_svc_common.constprop.0+0xb4/0xd4\n[   39.033862]  do_el0_svc+0x18/0x20\n[   39.033870]  el0_svc+0x3c/0xf0\n[   39.033880]  el0t_64_sync_handler+0xc0/0xc4\n[   39.033888]  el0t_64_sync+0x154/0x158\n[   39.041274] ravb 11c30000.ethernet eth0: Link is Down(CVE-2025-21801)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nspufs: fix a leak on spufs_new_file() failure\n\nIt\u0026apos;s called from spufs_fill_dir(), and caller of that will do\nspufs_rmdir() in case of failure.  That does remove everything\nwe\u0026apos;d managed to create, but... the problem dentry is still\nnegative.  IOW, it needs to be explicitly dropped.(CVE-2025-22073)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ch9200: fix uninitialised access during mii_nway_restart\n\nIn mii_nway_restart() the code attempts to call\nmii-\u0026gt;mdio_read which is ch9200_mdio_read(). ch9200_mdio_read()\nutilises a local buffer called \u0026quot;buff\u0026quot;, which is initialised\nwith control_read(). However \u0026quot;buff\u0026quot; is conditionally\ninitialised inside control_read():\n\n        if (err == size) {\n                memcpy(data, buf, size);\n        }\n\nIf the condition of \u0026quot;err == size\u0026quot; is not met, then\n\u0026quot;buff\u0026quot; remains uninitialised. Once this happens the\nuninitialised \u0026quot;buff\u0026quot; is accessed and returned during\nch9200_mdio_read():\n\n        return (buff[0] | buff[1] \u0026lt;\u0026lt; 8);\n\nThe problem stems from the fact that ch9200_mdio_read()\nignores the return value of control_read(), leading to\nuinit-access of \u0026quot;buff\u0026quot;.\n\nTo fix this we should check the return value of\ncontrol_read() and return early on error.(CVE-2025-38086)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbus: fsl-mc: fix double-free on mc_dev\n\nThe blamed commit tried to simplify how the deallocations are done but,\nin the process, introduced a double-free on the mc_dev variable.\n\nIn case the MC device is a DPRC, a new mc_bus is allocated and the\nmc_dev variable is just a reference to one of its fields. In this\ncircumstance, on the error path only the mc_bus should be freed.\n\nThis commit introduces back the following checkpatch warning which is a\nfalse-positive.\n\nWARNING: kfree(NULL) is safe and this check is probably not required\n+       if (mc_bus)\n+               kfree(mc_bus);(CVE-2025-38313)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: cancle set bad inode after removing name fails\n\nThe reproducer uses a file0 on a ntfs3 file system with a corrupted i_link.\nWhen renaming, the file0\u0026apos;s inode is marked as a bad inode because the file\nname cannot be deleted.\n\nThe underlying bug is that make_bad_inode() is called on a live inode.\nIn some cases it\u0026apos;s \u0026quot;icache lookup finds a normal inode, d_splice_alias()\nis called to attach it to dentry, while another thread decides to call\nmake_bad_inode() on it - that would evict it from icache, but we\u0026apos;d already\nfound it there earlier\u0026quot;.\nIn some it\u0026apos;s outright \u0026quot;we have an inode attached to dentry - that\u0026apos;s how we\ngot it in the first place; let\u0026apos;s call make_bad_inode() on it just for shits\nand giggles\u0026quot;.(CVE-2025-38615)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nARM: rockchip: fix kernel hang during smp initialization\n\nIn order to bring up secondary CPUs main CPU write trampoline\ncode to SRAM. The trampoline code is written while secondary\nCPUs are powered on (at least that true for RK3188 CPU).\nSometimes that leads to kernel hang. Probably because secondary\nCPU execute trampoline code while kernel doesn\u0026apos;t expect.\n\nThe patch moves SRAM initialization step to the point where all\nsecondary CPUs are powered down.\n\nThat fixes rarely hangs on RK3188:\n[    0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000\n[    0.091996] rockchip_smp_prepare_cpus: ncores 4(CVE-2025-39752)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntee: fix NULL pointer dereference in tee_shm_put\n\ntee_shm_put have NULL pointer dereference:\n\n__optee_disable_shm_cache --\u0026gt;\n\tshm = reg_pair_to_ptr(...);//shm maybe return NULL\n        tee_shm_free(shm); --\u0026gt;\n\t\ttee_shm_put(shm);//crash\n\nAdd check in tee_shm_put to fix it.\n\npanic log:\nUnable to handle kernel paging request at virtual address 0000000000100cca\nMem abort info:\nESR = 0x0000000096000004\nEC = 0x25: DABT (current EL), IL = 32 bits\nSET = 0, FnV = 0\nEA = 0, S1PTW = 0\nFSC = 0x04: level 0 translation fault\nData abort info:\nISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\nCM = 0, WnR = 0, TnD = 0, TagAccess = 0\nGCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\nuser pgtable: 4k pages, 48-bit VAs, pgdp=0000002049d07000\n[0000000000100cca] pgd=0000000000000000, p4d=0000000000000000\nInternal error: Oops: 0000000096000004 [#1] SMP\nCPU: 2 PID: 14442 Comm: systemd-sleep Tainted: P OE ------- ----\n6.6.0-39-generic #38\nSource Version: 938b255f6cb8817c95b0dd5c8c2944acfce94b07\nHardware name: greatwall GW-001Y1A-FTH, BIOS Great Wall BIOS V3.0\n10/26/2022\npstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : tee_shm_put+0x24/0x188\nlr : tee_shm_free+0x14/0x28\nsp : ffff001f98f9faf0\nx29: ffff001f98f9faf0 x28: ffff0020df543cc0 x27: 0000000000000000\nx26: ffff001f811344a0 x25: ffff8000818dac00 x24: ffff800082d8d048\nx23: ffff001f850fcd18 x22: 0000000000000001 x21: ffff001f98f9fb88\nx20: ffff001f83e76218 x19: ffff001f83e761e0 x18: 000000000000ffff\nx17: 303a30303a303030 x16: 0000000000000000 x15: 0000000000000003\nx14: 0000000000000001 x13: 0000000000000000 x12: 0101010101010101\nx11: 0000000000000001 x10: 0000000000000001 x9 : ffff800080e08d0c\nx8 : ffff001f98f9fb88 x7 : 0000000000000000 x6 : 0000000000000000\nx5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000\nx2 : ffff001f83e761e0 x1 : 00000000ffff001f x0 : 0000000000100cca\nCall trace:\ntee_shm_put+0x24/0x188\ntee_shm_free+0x14/0x28\n__optee_disable_shm_cache+0xa8/0x108\noptee_shutdown+0x28/0x38\nplatform_shutdown+0x28/0x40\ndevice_shutdown+0x144/0x2b0\nkernel_power_off+0x3c/0x80\nhibernate+0x35c/0x388\nstate_store+0x64/0x80\nkobj_attr_store+0x14/0x28\nsysfs_kf_write+0x48/0x60\nkernfs_fop_write_iter+0x128/0x1c0\nvfs_write+0x270/0x370\nksys_write+0x6c/0x100\n__arm64_sys_write+0x20/0x30\ninvoke_syscall+0x4c/0x120\nel0_svc_common.constprop.0+0x44/0xf0\ndo_el0_svc+0x24/0x38\nel0_svc+0x24/0x88\nel0t_64_sync_handler+0x134/0x150\nel0t_64_sync+0x14c/0x15(CVE-2025-39865)\n\nIn the Linux kernel, a use-after-free vulnerability exists in the __mark_inode_dirty() function. The issue occurs when __mark_inode_dirty() obtains a bdi_writeback that is in the process of switching. This is a race condition vulnerability between inode_switch_wbs_work_fn() and ___mark_inode_dirty(), causing the old writeback structure to be accessed after it has been released, triggering a use-after-free vulnerability.(CVE-2025-39866)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/memory-failure: fix VM_BUG_ON_PAGE(PagePoisoned(page)) when unpoison memory\n\nWhen I did memory failure tests, below panic occurs:\n\npage dumped because: VM_BUG_ON_PAGE(PagePoisoned(page))\nkernel BUG at include/linux/page-flags.h:616!\nOops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 3 PID: 720 Comm: bash Not tainted 6.10.0-rc1-00195-g148743902568 #40\nRIP: 0010:unpoison_memory+0x2f3/0x590\nRSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246\nRAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8\nRDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0\nRBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb\nR10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000\nR13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe\nFS:  00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n unpoison_memory+0x2f3/0x590\n simple_attr_write_xsigned.constprop.0.isra.0+0xb3/0x110\n debugfs_attr_write+0x42/0x60\n full_proxy_write+0x5b/0x80\n vfs_write+0xd5/0x540\n ksys_write+0x64/0xe0\n do_syscall_64+0xb9/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f08f0314887\nRSP: 002b:00007ffece710078 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 0000000000000009 RCX: 00007f08f0314887\nRDX: 0000000000000009 RSI: 0000564787a30410 RDI: 0000000000000001\nRBP: 0000564787a30410 R08: 000000000000fefe R09: 000000007fffffff\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000009\nR13: 00007f08f041b780 R14: 00007f08f0417600 R15: 00007f08f0416a00\n \u0026lt;/TASK\u0026gt;\nModules linked in: hwpoison_inject\n---[ end trace 0000000000000000 ]---\nRIP: 0010:unpoison_memory+0x2f3/0x590\nRSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246\nRAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8\nRDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0\nRBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb\nR10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000\nR13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe\nFS:  00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0\nKernel panic - not syncing: Fatal exception\nKernel Offset: 0x31c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)\n---[ end Kernel panic - not syncing: Fatal exception ]---\n\nThe root cause is that unpoison_memory() tries to check the PG_HWPoison\nflags of an uninitialized page.  So VM_BUG_ON_PAGE(PagePoisoned(page)) is\ntriggered.  This can be reproduced by below steps:\n\n1.Offline memory block:\n\n echo offline \u0026gt; /sys/devices/system/memory/memory12/state\n\n2.Get offlined memory pfn:\n\n page-types -b n -rlN\n\n3.Write pfn to unpoison-pfn\n\n echo \u0026lt;pfn\u0026gt; \u0026gt; /sys/kernel/debug/hwpoison/unpoison-pfn\n\nThis scenario can be identified by pfn_to_online_page() returning NULL. \nAnd ZONE_DEVICE pages are never expected, so we can simply fail if\npfn_to_online_page() == NULL to fix the bug.(CVE-2025-39883)",
  "id": "OESA-2025-2407",
  "modified": "2026-08-06T11:09:29Z",
  "published": "2025-10-11T11:09:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2407"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49234"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50350"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50404"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53165"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53241"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53259"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53275"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53286"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53331"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53369"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53384"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53395"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53438"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21801"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22073"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38086"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38313"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38615"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39752"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39865"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39866"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39883"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2022-49234",
    "CVE-2022-50350",
    "CVE-2022-50404",
    "CVE-2023-53165",
    "CVE-2023-53241",
    "CVE-2023-53259",
    "CVE-2023-53275",
    "CVE-2023-53286",
    "CVE-2023-53331",
    "CVE-2023-53369",
    "CVE-2023-53384",
    "CVE-2023-53395",
    "CVE-2023-53438",
    "CVE-2025-21801",
    "CVE-2025-22073",
    "CVE-2025-38086",
    "CVE-2025-38313",
    "CVE-2025-38615",
    "CVE-2025-39752",
    "CVE-2025-39865",
    "CVE-2025-39866",
    "CVE-2025-39883"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-4.19.90-2510.4.0.0349.oe2003sp4.aarch64.rpm",
          "bpftool-debuginfo-4.19.90-2510.4.0.0349.oe2003sp4.aarch64.rpm",
          "kernel-4.19.90-2510.4.0.0349.oe2003sp4.aarch64.rpm",
          "kernel-debuginfo-4.19.90-2510.4.0.0349.oe2003sp4.aarch64.rpm",
          "kernel-debugsource-4.19.90-2510.4.0.0349.oe2003sp4.aarch64.rpm",
          "kernel-devel-4.19.90-2510.4.0.0349.oe2003sp4.aarch64.rpm",
          "kernel-source-4.19.90-2510.4.0.0349.oe2003sp4.aarch64.rpm",
          "kernel-tools-4.19.90-2510.4.0.0349.oe2003sp4.aarch64.rpm",
          "kernel-tools-debuginfo-4.19.90-2510.4.0.0349.oe2003sp4.aarch64.rpm",
          "kernel-tools-devel-4.19.90-2510.4.0.0349.oe2003sp4.aarch64.rpm",
          "perf-4.19.90-2510.4.0.0349.oe2003sp4.aarch64.rpm",
          "perf-debuginfo-4.19.90-2510.4.0.0349.oe2003sp4.aarch64.rpm",
          "python2-perf-4.19.90-2510.4.0.0349.oe2003sp4.aarch64.rpm",
          "python2-perf-debuginfo-4.19.90-2510.4.0.0349.oe2003sp4.aarch64.rpm",
          "python3-perf-4.19.90-2510.4.0.0349.oe2003sp4.aarch64.rpm",
          "python3-perf-debuginfo-4.19.90-2510.4.0.0349.oe2003sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-4.19.90-2510.4.0.0349.oe2003sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-4.19.90-2510.4.0.0349.oe2003sp4.x86_64.rpm",
          "bpftool-debuginfo-4.19.90-2510.4.0.0349.oe2003sp4.x86_64.rpm",
          "kernel-4.19.90-2510.4.0.0349.oe2003sp4.x86_64.rpm",
          "kernel-debuginfo-4.19.90-2510.4.0.0349.oe2003sp4.x86_64.rpm",
          "kernel-debugsource-4.19.90-2510.4.0.0349.oe2003sp4.x86_64.rpm",
          "kernel-devel-4.19.90-2510.4.0.0349.oe2003sp4.x86_64.rpm",
          "kernel-source-4.19.90-2510.4.0.0349.oe2003sp4.x86_64.rpm",
          "kernel-tools-4.19.90-2510.4.0.0349.oe2003sp4.x86_64.rpm",
          "kernel-tools-debuginfo-4.19.90-2510.4.0.0349.oe2003sp4.x86_64.rpm",
          "kernel-tools-devel-4.19.90-2510.4.0.0349.oe2003sp4.x86_64.rpm",
          "perf-4.19.90-2510.4.0.0349.oe2003sp4.x86_64.rpm",
          "perf-debuginfo-4.19.90-2510.4.0.0349.oe2003sp4.x86_64.rpm",
          "python2-perf-4.19.90-2510.4.0.0349.oe2003sp4.x86_64.rpm",
          "python2-perf-debuginfo-4.19.90-2510.4.0.0349.oe2003sp4.x86_64.rpm",
          "python3-perf-4.19.90-2510.4.0.0349.oe2003sp4.x86_64.rpm",
          "python3-perf-debuginfo-4.19.90-2510.4.0.0349.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-2510.4.0.0349.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\nnet/tunnel: wait until all sk_user_data reader finish before releasing the sock\n\nThere is a race condition in vxlan that when deleting a vxlan device\nduring receiving packets, there is a possibility that the sock is\nreleased after getting vxlan_sock vs from sk_user_data. Then in\nlater vxlan_ecn_decapsulate(), vxlan_get_sk_family() we will got\nNULL pointer dereference. e.g.\n\n   #0 [ffffa25ec6978a38] machine_kexec at ffffffff8c669757\n   #1 [ffffa25ec6978a90] __crash_kexec at ffffffff8c7c0a4d\n   #2 [ffffa25ec6978b58] crash_kexec at ffffffff8c7c1c48\n   #3 [ffffa25ec6978b60] oops_end at ffffffff8c627f2b\n   #4 [ffffa25ec6978b80] page_fault_oops at ffffffff8c678fcb\n   #5 [ffffa25ec6978bd8] exc_page_fault at ffffffff8d109542\n   #6 [ffffa25ec6978c00] asm_exc_page_fault at ffffffff8d200b62\n      [exception RIP: vxlan_ecn_decapsulate+0x3b]\n      RIP: ffffffffc1014e7b  RSP: ffffa25ec6978cb0  RFLAGS: 00010246\n      RAX: 0000000000000008  RBX: ffff8aa000888000  RCX: 0000000000000000\n      RDX: 000000000000000e  RSI: ffff8a9fc7ab803e  RDI: ffff8a9fd1168700\n      RBP: ffff8a9fc7ab803e   R8: 0000000000700000   R9: 00000000000010ae\n      R10: ffff8a9fcb748980  R11: 0000000000000000  R12: ffff8a9fd1168700\n      R13: ffff8aa000888000  R14: 00000000002a0000  R15: 00000000000010ae\n      ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018\n   #7 [ffffa25ec6978ce8] vxlan_rcv at ffffffffc10189cd [vxlan]\n   #8 [ffffa25ec6978d90] udp_queue_rcv_one_skb at ffffffff8cfb6507\n   #9 [ffffa25ec6978dc0] udp_unicast_rcv_skb at ffffffff8cfb6e45\n  #10 [ffffa25ec6978dc8] __udp4_lib_rcv at ffffffff8cfb8807\n  #11 [ffffa25ec6978e20] ip_protocol_deliver_rcu at ffffffff8cf76951\n  #12 [ffffa25ec6978e48] ip_local_deliver at ffffffff8cf76bde\n  #13 [ffffa25ec6978ea0] __netif_receive_skb_one_core at ffffffff8cecde9b\n  #14 [ffffa25ec6978ec8] process_backlog at ffffffff8cece139\n  #15 [ffffa25ec6978f00] __napi_poll at ffffffff8ceced1a\n  #16 [ffffa25ec6978f28] net_rx_action at ffffffff8cecf1f3\n  #17 [ffffa25ec6978fa0] __softirqentry_text_start at ffffffff8d4000ca\n  #18 [ffffa25ec6978ff0] do_softirq at ffffffff8c6fbdc3\n\nReproducer: https://github.com/Mellanox/ovs-tests/blob/master/test-ovs-vxlan-remove-tunnel-during-traffic.sh\n\nFix this by waiting for all sk_user_data reader to finish before\nreleasing the sock.(CVE-2022-50405)\n\nIn the Linux kernel, there is a vulnerability in the USB host controller interface (xHCI). When the xHC host is dying or being removed, endpoints are not properly cleaned up, remaining in the bandwidth list when freeing the virtual device. This causes a list_del corruption kernel crash when unbinding xhci-pci, as xhci_mem_cleanup() later attempts to delete already freed endpoints from the bandwidth list. This vulnerability only affects hosts that use software bandwidth checking, which currently is only the xHC in Intel Panther Point PCH (Ivy Bridge).(CVE-2022-50470)\n\nIn the Linux kernel, the following vulnerability has been resolved:thermal: intel_powerclamp: Use get_cpu() instead of smp_processor_id() to avoid crashWhen CPU 0 is offline and intel_powerclamp is used to injectidle, it generates kernel BUG:BUG: using smp_processor_id() in preemptible [00000000] code: bash/15687caller is debug_smp_processor_id+0x17/0x20CPU: 4 PID: 15687 Comm: bash Not tainted 5.19.0-rc7+ #57Call Trace:\u0026lt;TASK\u0026gt;dump_stack_lvl+0x49/0x63dump_stack+0x10/0x16check_preemption_disabled+0xdd/0xe0debug_smp_processor_id+0x17/0x20powerclamp_set_cur_state+0x7f/0xf9 [intel_powerclamp]......Here CPU 0 is the control CPU by default and changed to the current CPU,if CPU 0 offlined. This check has to be performed under cpus_read_lock(),hence the above warning.Use get_cpu() instead of smp_processor_id() to avoid this BUG.[ rjw: Subject edits ](CVE-2022-50494)\n\nIn the Linux kernel, the following vulnerability has been resolved:iommu/amd: Fix pci device refcount leak in ppr_notifier()As comment of pci_get_domain_bus_and_slot() says, it returnsa pci device with refcount increment, when finish using it,the caller must decrement the reference count by callingpci_dev_put(). So call it before returning from ppr_notifier()to avoid refcount leak.(CVE-2022-50505)\n\nIn the Linux kernel, the following vulnerability has been resolved:usb: host: xhci: Fix potential memory leak in xhci_alloc_stream_info()xhci_alloc_stream_info() allocates stream context array for stream_info-\u0026gt;stream_ctx_array with xhci_alloc_stream_ctx(). When some error occurs,stream_info-\u0026gt;stream_ctx_array is not released, which will lead to amemory leak.We can fix it by releasing the stream_info-\u0026gt;stream_ctx_array withxhci_free_stream_ctx() on the error path to avoid the potential memoryleak.(CVE-2022-50544)\n\nIn the Linux kernel, the following vulnerability has been resolved:mtd: Fix device name leak when register device failed in add_mtd_device()There is a kmemleak when register device failed:  unreferenced object 0xffff888101aab550 (size 8):    comm  insmod , pid 3922, jiffies 4295277753 (age 925.408s)    hex dump (first 8 bytes):      6d 74 64 30 00 88 ff ff                          mtd0....    backtrace:      [\u0026lt;00000000bde26724\u0026gt;] __kmalloc_node_track_caller+0x4e/0x150      [\u0026lt;000000003c32b416\u0026gt;] kvasprintf+0xb0/0x130      [\u0026lt;000000001f7a8f15\u0026gt;] kobject_set_name_vargs+0x2f/0xb0      [\u0026lt;000000006e781163\u0026gt;] dev_set_name+0xab/0xe0      [\u0026lt;00000000e30d0c78\u0026gt;] add_mtd_device+0x4bb/0x700      [\u0026lt;00000000f3d34de7\u0026gt;] mtd_device_parse_register+0x2ac/0x3f0      [\u0026lt;00000000c0d88488\u0026gt;] 0xffffffffa0238457      [\u0026lt;00000000b40d0922\u0026gt;] 0xffffffffa02a008f      [\u0026lt;0000000023d17b9d\u0026gt;] do_one_initcall+0x87/0x2a0      [\u0026lt;00000000770f6ca6\u0026gt;] do_init_module+0xdf/0x320      [\u0026lt;000000007b6768fe\u0026gt;] load_module+0x2f98/0x3330      [\u0026lt;00000000346bed5a\u0026gt;] __do_sys_finit_module+0x113/0x1b0      [\u0026lt;00000000674c2290\u0026gt;] do_syscall_64+0x35/0x80      [\u0026lt;000000004c6a8d97\u0026gt;] entry_SYSCALL_64_after_hwframe+0x46/0xb0If register device failed, should call put_device() to give up thereference.(CVE-2022-50566)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nubi: ensure that VID header offset + VID header size \u0026lt;= alloc, size\n\nEnsure that the VID header offset + VID header size does not exceed\nthe allocated area to avoid slab OOB.\n\nBUG: KASAN: slab-out-of-bounds in crc32_body lib/crc32.c:111 [inline]\nBUG: KASAN: slab-out-of-bounds in crc32_le_generic lib/crc32.c:179 [inline]\nBUG: KASAN: slab-out-of-bounds in crc32_le_base+0x58c/0x626 lib/crc32.c:197\nRead of size 4 at addr ffff88802bb36f00 by task syz-executor136/1555\n\nCPU: 2 PID: 1555 Comm: syz-executor136 Tainted: G        W\n6.0.0-1868 #1\nHardware name: Red Hat KVM, BIOS 1.13.0-2.module+el8.3.0+7860+a7792d29\n04/01/2014\nCall Trace:\n  \u0026lt;TASK\u0026gt;\n  __dump_stack lib/dump_stack.c:88 [inline]\n  dump_stack_lvl+0x85/0xad lib/dump_stack.c:106\n  print_address_description mm/kasan/report.c:317 [inline]\n  print_report.cold.13+0xb6/0x6bb mm/kasan/report.c:433\n  kasan_report+0xa7/0x11b mm/kasan/report.c:495\n  crc32_body lib/crc32.c:111 [inline]\n  crc32_le_generic lib/crc32.c:179 [inline]\n  crc32_le_base+0x58c/0x626 lib/crc32.c:197\n  ubi_io_write_vid_hdr+0x1b7/0x472 drivers/mtd/ubi/io.c:1067\n  create_vtbl+0x4d5/0x9c4 drivers/mtd/ubi/vtbl.c:317\n  create_empty_lvol drivers/mtd/ubi/vtbl.c:500 [inline]\n  ubi_read_volume_table+0x67b/0x288a drivers/mtd/ubi/vtbl.c:812\n  ubi_attach+0xf34/0x1603 drivers/mtd/ubi/attach.c:1601\n  ubi_attach_mtd_dev+0x6f3/0x185e drivers/mtd/ubi/build.c:965\n  ctrl_cdev_ioctl+0x2db/0x347 drivers/mtd/ubi/cdev.c:1043\n  vfs_ioctl fs/ioctl.c:51 [inline]\n  __do_sys_ioctl fs/ioctl.c:870 [inline]\n  __se_sys_ioctl fs/ioctl.c:856 [inline]\n  __x64_sys_ioctl+0x193/0x213 fs/ioctl.c:856\n  do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n  do_syscall_64+0x3e/0x86 arch/x86/entry/common.c:80\n  entry_SYSCALL_64_after_hwframe+0x63/0x0\nRIP: 0033:0x7f96d5cf753d\nCode:\nRSP: 002b:00007fffd72206f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\nRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f96d5cf753d\nRDX: 0000000020000080 RSI: 0000000040186f40 RDI: 0000000000000003\nRBP: 0000000000400cd0 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000400be0\nR13: 00007fffd72207e0 R14: 0000000000000000 R15: 0000000000000000\n  \u0026lt;/TASK\u0026gt;\n\nAllocated by task 1555:\n  kasan_save_stack+0x20/0x3d mm/kasan/common.c:38\n  kasan_set_track mm/kasan/common.c:45 [inline]\n  set_alloc_info mm/kasan/common.c:437 [inline]\n  ____kasan_kmalloc mm/kasan/common.c:516 [inline]\n  __kasan_kmalloc+0x88/0xa3 mm/kasan/common.c:525\n  kasan_kmalloc include/linux/kasan.h:234 [inline]\n  __kmalloc+0x138/0x257 mm/slub.c:4429\n  kmalloc include/linux/slab.h:605 [inline]\n  ubi_alloc_vid_buf drivers/mtd/ubi/ubi.h:1093 [inline]\n  create_vtbl+0xcc/0x9c4 drivers/mtd/ubi/vtbl.c:295\n  create_empty_lvol drivers/mtd/ubi/vtbl.c:500 [inline]\n  ubi_read_volume_table+0x67b/0x288a drivers/mtd/ubi/vtbl.c:812\n  ubi_attach+0xf34/0x1603 drivers/mtd/ubi/attach.c:1601\n  ubi_attach_mtd_dev+0x6f3/0x185e drivers/mtd/ubi/build.c:965\n  ctrl_cdev_ioctl+0x2db/0x347 drivers/mtd/ubi/cdev.c:1043\n  vfs_ioctl fs/ioctl.c:51 [inline]\n  __do_sys_ioctl fs/ioctl.c:870 [inline]\n  __se_sys_ioctl fs/ioctl.c:856 [inline]\n  __x64_sys_ioctl+0x193/0x213 fs/ioctl.c:856\n  do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n  do_syscall_64+0x3e/0x86 arch/x86/entry/common.c:80\n  entry_SYSCALL_64_after_hwframe+0x63/0x0\n\nThe buggy address belongs to the object at ffff88802bb36e00\n  which belongs to the cache kmalloc-256 of size 256\nThe buggy address is located 0 bytes to the right of\n  256-byte region [ffff88802bb36e00, ffff88802bb36f00)\n\nThe buggy address belongs to the physical page:\npage:00000000ea4d1263 refcount:1 mapcount:0 mapping:0000000000000000\nindex:0x0 pfn:0x2bb36\nhead:00000000ea4d1263 order:1 compound_mapcount:0 compound_pincount:0\nflags: 0xfffffc0010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff)\nraw: 000fffffc0010200 ffffea000066c300 dead000000000003 ffff888100042b40\nraw: 0000000000000000 00000000001\n---truncated---(CVE-2023-53265)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nubi: Fix unreferenced object reported by kmemleak in ubi_resize_volume()\n\nThere is a memory leaks problem reported by kmemleak:\n\nunreferenced object 0xffff888102007a00 (size 128):\n  comm \u0026quot;ubirsvol\u0026quot;, pid 32090, jiffies 4298464136 (age 2361.231s)\n  hex dump (first 32 bytes):\nff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................\nff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................\n  backtrace:\n[\u0026lt;ffffffff8176cecd\u0026gt;] __kmalloc+0x4d/0x150\n[\u0026lt;ffffffffa02a9a36\u0026gt;] ubi_eba_create_table+0x76/0x170 [ubi]\n[\u0026lt;ffffffffa029764e\u0026gt;] ubi_resize_volume+0x1be/0xbc0 [ubi]\n[\u0026lt;ffffffffa02a3321\u0026gt;] ubi_cdev_ioctl+0x701/0x1850 [ubi]\n[\u0026lt;ffffffff81975d2d\u0026gt;] __x64_sys_ioctl+0x11d/0x170\n[\u0026lt;ffffffff83c142a5\u0026gt;] do_syscall_64+0x35/0x80\n[\u0026lt;ffffffff83e0006a\u0026gt;] entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nThis is due to a mismatch between create and destroy interfaces, and\nin detail that \u0026quot;new_eba_tbl\u0026quot; created by ubi_eba_create_table() but\ndestroyed by kfree(), while will causing \u0026quot;new_eba_tbl-\u0026gt;entries\u0026quot; not\nfreed.\n\nFix it by replacing kfree(new_eba_tbl) with\nubi_eba_destroy_table(new_eba_tbl)(CVE-2023-53271)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: check send stream number after wait_for_sndbuf\n\nThis patch fixes a corner case where the asoc out stream count may change\nafter wait_for_sndbuf.\n\nWhen the main thread in the client starts a connection, if its out stream\ncount is set to N while the in stream count in the server is set to N - 2,\nanother thread in the client keeps sending the msgs with stream number\nN - 1, and waits for sndbuf before processing INIT_ACK.\n\nHowever, after processing INIT_ACK, the out stream count in the client is\nshrunk to N - 2, the same to the in stream count in the server. The crash\noccurs when the thread waiting for sndbuf is awake and sends the msg in a\nnon-existing stream(N - 1), the call trace is as below:\n\n  KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   sctp_cmd_send_msg net/sctp/sm_sideeffect.c:1114 [inline]\n   sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1777 [inline]\n   sctp_side_effects net/sctp/sm_sideeffect.c:1199 [inline]\n   sctp_do_sm+0x197d/0x5310 net/sctp/sm_sideeffect.c:1170\n   sctp_primitive_SEND+0x9f/0xc0 net/sctp/primitive.c:163\n   sctp_sendmsg_to_asoc+0x10eb/0x1a30 net/sctp/socket.c:1868\n   sctp_sendmsg+0x8d4/0x1d90 net/sctp/socket.c:2026\n   inet_sendmsg+0x9d/0xe0 net/ipv4/af_inet.c:825\n   sock_sendmsg_nosec net/socket.c:722 [inline]\n   sock_sendmsg+0xde/0x190 net/socket.c:745\n\nThe fix is to add an unlikely check for the send stream number after the\nthread wakes up from the wait_for_sndbuf.(CVE-2023-53296)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: fix a potential overflow in sctp_ifwdtsn_skip\n\nCurrently, when traversing ifwdtsn skips with _sctp_walk_ifwdtsn, it only\nchecks the pos against the end of the chunk. However, the data left for\nthe last pos may be \u0026lt; sizeof(struct sctp_ifwdtsn_skip), and dereference\nit as struct sctp_ifwdtsn_skip may cause coverflow.\n\nThis patch fixes it by checking the pos against \u0026quot;the end of the chunk -\nsizeof(struct sctp_ifwdtsn_skip)\u0026quot; in sctp_ifwdtsn_skip, similar to\nsctp_fwdtsn_skip.(CVE-2023-53372)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mwifiex: avoid possible NULL skb pointer dereference\n\nIn \u0026apos;mwifiex_handle_uap_rx_forward()\u0026apos;, always check the value\nreturned by \u0026apos;skb_copy()\u0026apos; to avoid potential NULL pointer\ndereference in \u0026apos;mwifiex_uap_queue_bridged_pkt()\u0026apos;, and drop\noriginal skb in case of copying failure.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-53384)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/radeon: free iio for atombios when driver shutdown\n\nFix below kmemleak when unload radeon driver:\n\nunreferenced object 0xffff9f8608ede200 (size 512):\n  comm \u0026quot;systemd-udevd\u0026quot;, pid 326, jiffies 4294682822 (age 716.338s)\n  hex dump (first 32 bytes):\n    00 00 00 00 c4 aa ec aa 14 ab 00 00 00 00 00 00  ................\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n  backtrace:\n    [\u0026lt;0000000062fadebe\u0026gt;] kmem_cache_alloc_trace+0x2f1/0x500\n    [\u0026lt;00000000b6883cea\u0026gt;] atom_parse+0x117/0x230 [radeon]\n    [\u0026lt;00000000158c23fd\u0026gt;] radeon_atombios_init+0xab/0x170 [radeon]\n    [\u0026lt;00000000683f672e\u0026gt;] si_init+0x57/0x750 [radeon]\n    [\u0026lt;00000000566cc31f\u0026gt;] radeon_device_init+0x559/0x9c0 [radeon]\n    [\u0026lt;0000000046efabb3\u0026gt;] radeon_driver_load_kms+0xc1/0x1a0 [radeon]\n    [\u0026lt;00000000b5155064\u0026gt;] drm_dev_register+0xdd/0x1d0\n    [\u0026lt;0000000045fec835\u0026gt;] radeon_pci_probe+0xbd/0x100 [radeon]\n    [\u0026lt;00000000e69ecca3\u0026gt;] pci_device_probe+0xe1/0x160\n    [\u0026lt;0000000019484b76\u0026gt;] really_probe.part.0+0xc1/0x2c0\n    [\u0026lt;000000003f2649da\u0026gt;] __driver_probe_device+0x96/0x130\n    [\u0026lt;00000000231c5bb1\u0026gt;] driver_probe_device+0x24/0xf0\n    [\u0026lt;0000000000a42377\u0026gt;] __driver_attach+0x77/0x190\n    [\u0026lt;00000000d7574da6\u0026gt;] bus_for_each_dev+0x7f/0xd0\n    [\u0026lt;00000000633166d2\u0026gt;] driver_attach+0x1e/0x30\n    [\u0026lt;00000000313b05b8\u0026gt;] bus_add_driver+0x12c/0x1e0\n\niio was allocated in atom_index_iio() called by atom_parse(),\nbut it doesn\u0026apos;t got released when the dirver is shutdown.\nFix this kmemleak by free it in radeon_atombios_fini().(CVE-2023-53453)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nubi: ubi_wl_put_peb: Fix infinite loop when wear-leveling work failed\n\nFollowing process will trigger an infinite loop in ubi_wl_put_peb():\n\n\tubifs_bgt\t\tubi_bgt\nubifs_leb_unmap\n  ubi_leb_unmap\n    ubi_eba_unmap_leb\n      ubi_wl_put_peb\twear_leveling_worker\n                          e1 = rb_entry(rb_first(\u0026amp;ubi-\u0026gt;used)\n\t\t\t  e2 = get_peb_for_wl(ubi)\n\t\t\t  ubi_io_read_vid_hdr  // return err (flash fault)\n\t\t\t  out_error:\n\t\t\t    ubi-\u0026gt;move_from = ubi-\u0026gt;move_to = NULL\n\t\t\t    wl_entry_destroy(ubi, e1)\n\t\t\t      ubi-\u0026gt;lookuptbl[e-\u0026gt;pnum] = NULL\n      retry:\n        e = ubi-\u0026gt;lookuptbl[pnum];\t// return NULL\n\tif (e == ubi-\u0026gt;move_from) {\t// NULL == NULL gets true\n\t  goto retry;\t\t\t// infinite loop !!!\n\n$ top\n  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     COMMAND\n  7676 root     20   0       0      0      0 R 100.0  0.0  ubifs_bgt0_0\n\nFix it by:\n 1) Letting ubi_wl_put_peb() returns directly if wearl leveling entry has\n    been removed from \u0026apos;ubi-\u0026gt;lookuptbl\u0026apos;.\n 2) Using \u0026apos;ubi-\u0026gt;wl_lock\u0026apos; protecting wl entry deletion to preventing an\n    use-after-free problem for wl entry in ubi_wl_put_peb().\n\nFetch a reproducer in [Link].(CVE-2023-53481)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvirtio-mmio: don\u0026apos;t break lifecycle of vm_dev\n\nvm_dev has a separate lifecycle because it has a \u0026apos;struct device\u0026apos;\nembedded. Thus, having a release callback for it is correct.\n\nAllocating the vm_dev struct with devres totally breaks this protection,\nthough. Instead of waiting for the vm_dev release callback, the memory\nis freed when the platform_device is removed. Resulting in a\nuse-after-free when finally the callback is to be called.\n\nTo easily see the problem, compile the kernel with\nCONFIG_DEBUG_KOBJECT_RELEASE and unbind with sysfs.\n\nThe fix is easy, don\u0026apos;t use devres in this case.\n\nFound during my research about object lifetime problems.(CVE-2023-53515)\n\nIn the Linux kernel, the following vulnerability has been resolved:spi: qup: Don t skip cleanup in remove s error pathReturning early in a platform driver s remove callback is wrong. In thiscase the dma resources are not released in the error path. this is neverretried later and so this is a permanent leak. To fix this, only skiphardware disabling if waking the device fails.(CVE-2023-53567)\n\nIn the Linux kernel, the following vulnerability has been resolved:dm integrity: call kmem_cache_destroy() in dm_integrity_init() error pathOtherwise the journal_io_cache will leak if dm_register_target() fails.(CVE-2023-53604)\n\nIn the Linux kernel, the following vulnerability has been resolved:ALSA: ac97: Fix possible NULL dereference in snd_ac97_mixersmatch error:sound/pci/ac97/ac97_codec.c:2354 snd_ac97_mixer() error:we previously assumed  rac97  could be null (see line 2072)remove redundant assignment, return error if rac97 is NULL.(CVE-2023-53648)\n\nIn the Linux kernel, the following vulnerability has been resolved:bcache: Fix __bch_btree_node_alloc to make the failure behavior consistentIn some specific situations, the return value of __bch_btree_node_allocmay be NULL. This may lead to a potential NULL pointer dereference incaller function like a calling chain :btree_split-\u0026gt;bch_btree_node_alloc-\u0026gt;__bch_btree_node_alloc.Fix it by initializing the return value in __bch_btree_node_alloc.(CVE-2023-53681)\n\nIn the Linux kernel, the following vulnerability has been resolved:serial: arc_uart: fix of_iomap leak in `arc_serial_probe`Smatch reports:drivers/tty/serial/arc_uart.c:631 arc_serial_probe() warn: port-\u0026gt;membase  from of_iomap() not released on lines: 631.In arc_serial_probe(), if uart_add_one_port() fails,port-\u0026gt;membase is not released, which would cause a resource leak.To fix this, I replace of_iomap with devm_platform_ioremap_resource.(CVE-2023-53719)\n\nIn the Linux kernel, the following vulnerability has been resolved:posix-timers: Ensure timer ID search-loop limit is validposix_timer_add() tries to allocate a posix timer ID by starting from thecached ID which was stored by the last successful allocation.This is done in a loop searching the ID space for a free slot one byone. The loop has to terminate when the search wrapped around to thestarting point.But that s racy vs. establishing the starting point. That is read outlockless, which leads to the following problem:CPU0                    CPU1posix_timer_add()  start = sig-\u0026gt;posix_timer_id;  lock(hash_lock);  ...       posix_timer_add()  if (++sig-\u0026gt;posix_timer_id \u0026lt; 0)                      start = sig-\u0026gt;posix_timer_id;     sig-\u0026gt;posix_timer_id = 0;So CPU1 can observe a negative start value, i.e. -1, and the loop breaknever happens because the condition can never be true:  if (sig-\u0026gt;posix_timer_id == start)     break;While this is unlikely to ever turn into an endless loop as the ID space ishuge (INT_MAX), the racy read of the start value caught the attention ofKCSAN and Dmitry unearthed that incorrectness.Rewrite it so that all id operations are under the hash lock.(CVE-2023-53728)\n\nIn the Linux kernel, the following vulnerability has been resolved:sunrpc: fix one UAF issue caused by sunrpc kernel tcp socketBUG: KASAN: slab-use-after-free in tcp_write_timer_handler+0x156/0x3e0Read of size 1 at addr ffff888111f322cd by task swapper/0/0CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc4-dirty #7Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1Call Trace: \u0026lt;IRQ\u0026gt; dump_stack_lvl+0x68/0xa0 print_address_description.constprop.0+0x2c/0x3d0 print_report+0xb4/0x270 kasan_report+0xbd/0xf0 tcp_write_timer_handler+0x156/0x3e0 tcp_write_timer+0x66/0x170 call_timer_fn+0xfb/0x1d0 __run_timers+0x3f8/0x480 run_timer_softirq+0x9b/0x100 handle_softirqs+0x153/0x390 __irq_exit_rcu+0x103/0x120 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x76/0x90 \u0026lt;/IRQ\u0026gt; \u0026lt;TASK\u0026gt; asm_sysvec_apic_timer_interrupt+0x1a/0x20RIP: 0010:default_idle+0xf/0x20Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 33 f8 25 00 fb f4 \u0026lt;fa\u0026gt; c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90RSP: 0018:ffffffffa2007e28 EFLAGS: 00000242RAX: 00000000000f3b31 RBX: 1ffffffff4400fc7 RCX: ffffffffa09c3196RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff9f00590fRBP: 0000000000000000 R08: 0000000000000001 R09: ffffed102360835dR10: ffff88811b041aeb R11: 0000000000000001 R12: 0000000000000000R13: ffffffffa202d7c0 R14: 0000000000000000 R15: 00000000000147d0 default_idle_call+0x6b/0xa0 cpuidle_idle_call+0x1af/0x1f0 do_idle+0xbc/0x130 cpu_startup_entry+0x33/0x40 rest_init+0x11f/0x210 start_kernel+0x39a/0x420 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0x97/0xa0 common_startup_64+0x13e/0x141 \u0026lt;/TASK\u0026gt;Allocated by task 595: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x87/0x90 kmem_cache_alloc_noprof+0x12b/0x3f0 copy_net_ns+0x94/0x380 create_new_namespaces+0x24c/0x500 unshare_nsproxy_namespaces+0x75/0xf0 ksys_unshare+0x24e/0x4f0 __x64_sys_unshare+0x1f/0x30 do_syscall_64+0x70/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7eFreed by task 100: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x54/0x70 kmem_cache_free+0x156/0x5d0 cleanup_net+0x5d3/0x670 process_one_work+0x776/0xa90 worker_thread+0x2e2/0x560 kthread+0x1a8/0x1f0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Reproduction script:mkdir -p /mnt/nfssharemkdir -p /mnt/nfs/netns_1mkfs.ext4 /dev/sdbmount /dev/sdb /mnt/nfssharesystemctl restart nfs-serverchmod 777 /mnt/nfsshareexportfs -i -o rw,no_root_squash *:/mnt/nfsshareip netns add netns_1ip link add name veth_1_peer type veth peer veth_1ifconfig veth_1_peer 11.11.0.254 upip link set veth_1 netns netns_1ip netns exec netns_1 ifconfig veth_1 11.11.0.1ip netns exec netns_1 /root/iptables -A OUTPUT -d 11.11.0.254 -p tcp   --tcp-flags FIN FIN  -j DROP(note: In my environment, a DESTROY_CLIENTID operation is always sent immediately, breaking the nfs tcp connection.)ip netns exec netns_1 timeout -s 9 300 mount -t nfs -o proto=tcp,vers=4.1   11.11.0.254:/mnt/nfsshare /mnt/nfs/netns_1ip netns del netns_1The reason here is that the tcp socket in netns_1 (nfs side) has beenshutdown and closed (done in xs_destroy), but the FIN message (with ack)is discarded, and the nfsd side keeps sending retransmission messages.As a result, when the tcp sock in netns_1 processes the received message,it sends the message (FIN message) in the sending queue, and the tcp timeris re-established. When the network namespace is deleted, the net structureaccessed by tcp s timer handler function causes problems.To fix this problem, let s hold netns refcnt for the tcp kernel socket asdone in other modules. This is an ugly hack which can easily be backportedto earlier kernels. A proper fix which cleans up the interfaces willfollow, but may not be so easy to backport.(CVE-2024-53168)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: atm: fix /proc/net/atm/lec handling\n\n/proc/net/atm/lec must ensure safety against dev_lec[] changes.\n\nIt appears it had dev_put() calls without prior dev_hold(),\nleading to imbalance and UAF.(CVE-2025-38180)\n\nIn the Linux kernel, a race condition vulnerability exists in the posix-cpu-timers component. When a non-autoreaping exiting task has passed exit_notify() and calls handle_posix_cpu_timers() from IRQ, it can be reaped by its parent or debugger immediately after unlock_task_sighand(). If a concurrent posix_cpu_timer_del() runs at that moment, it will fail to detect timer-\u0026gt;it.cpu.firing != 0 because cpu_timer_task_rcu() and/or lock_task_sighand() will fail. The fix adds a tsk-\u0026gt;exit_state check to run_posix_cpu_timers().(CVE-2025-38352)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: Validate UAC3 power domain descriptors, too\n\nUAC3 power domain descriptors need to be verified with its variable\nbLength for avoiding the unexpected OOB accesses by malicious\nfirmware, too.(CVE-2025-38729)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla4xxx: Prevent a potential error pointer dereference\n\nThe qla4xxx_get_ep_fwdb() function is supposed to return NULL on error,\nbut qla4xxx_ep_connect() returns error pointers.  Propagating the error\npointers will lead to an Oops in the caller, so change the error pointers\nto NULL.(CVE-2025-39676)\n\nA buffer overflow vulnerability was found in the efivarfs component of the Linux kernel. When dentry-\u0026gt;d_name.len \u0026lt; EFI_VARIABLE_GUID_LEN, \u0026amp;#39;guid\u0026amp;#39; may become negative, causing out-of-bounds reads. This vulnerability can be triggered by parallel search using invalid file names, causing kernel memory to be accessed out of bounds.(CVE-2025-39817)",
  "id": "OESA-2025-2553",
  "modified": "2026-08-06T11:09:38Z",
  "published": "2025-10-31T11:09:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2553"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50405"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50470"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50494"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50505"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50544"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50566"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53265"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53271"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53296"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53372"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53384"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53453"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53481"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53515"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53567"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53604"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53648"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53681"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53719"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53728"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53168"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38180"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38352"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38729"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39676"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39817"
    }
  ],
  "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-2022-50405",
    "CVE-2022-50470",
    "CVE-2022-50494",
    "CVE-2022-50505",
    "CVE-2022-50544",
    "CVE-2022-50566",
    "CVE-2023-53265",
    "CVE-2023-53271",
    "CVE-2023-53296",
    "CVE-2023-53372",
    "CVE-2023-53384",
    "CVE-2023-53453",
    "CVE-2023-53481",
    "CVE-2023-53515",
    "CVE-2023-53567",
    "CVE-2023-53604",
    "CVE-2023-53648",
    "CVE-2023-53681",
    "CVE-2023-53719",
    "CVE-2023-53728",
    "CVE-2024-53168",
    "CVE-2025-38180",
    "CVE-2025-38352",
    "CVE-2025-38729",
    "CVE-2025-39676",
    "CVE-2025-39817"
  ]
}