Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2025-39968 (GCVE-0-2025-39968)
Vulnerability from cvelistv5 – Published: 2025-10-15 07:55 – Updated: 2026-08-05 12:06| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
e284fc280473bed23f2e1ed324e102a48f7d17e1 , < 9176e18681cb0d34c5acc87bda224f5652af2ab8
(git)
Affected: e284fc280473bed23f2e1ed324e102a48f7d17e1 , < e490d8c5a54e0dd1ab22417d72c3a7319cf0f030 (git) Affected: e284fc280473bed23f2e1ed324e102a48f7d17e1 , < 77a35be582dff4c80442ebcdce24d45eed8a6ce4 (git) Affected: e284fc280473bed23f2e1ed324e102a48f7d17e1 , < 02aae5fcdd34c3a55a243d80a1b328a35852a35c (git) Affected: e284fc280473bed23f2e1ed324e102a48f7d17e1 , < edecce7abd7152b48e279b4fa0a883d1839bb577 (git) Affected: e284fc280473bed23f2e1ed324e102a48f7d17e1 , < d33e5d6631ac4fddda235a7815babc9d3f124299 (git) Affected: e284fc280473bed23f2e1ed324e102a48f7d17e1 , < 8b13df5aa877b9e4541e301a58a84c42d84d2d9a (git) Affected: e284fc280473bed23f2e1ed324e102a48f7d17e1 , < cb79fa7118c150c3c76a327894bb2eb878c02619 (git) |
guessed | |
| Linux | Linux |
Affected:
4.17
Unaffected: 0 , < 4.17 (semver) Unaffected: 5.4.300 , ≤ 5.4.* (semver) Unaffected: 5.10.245 , ≤ 5.10.* (semver) Unaffected: 5.15.194 , ≤ 5.15.* (semver) Unaffected: 6.1.155 , ≤ 6.1.* (semver) Unaffected: 6.6.109 , ≤ 6.6.* (semver) Unaffected: 6.12.50 , ≤ 6.12.* (semver) Unaffected: 6.16.10 , ≤ 6.16.* (semver) Unaffected: 6.17 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "9176e18681cb0d34c5acc87bda224f5652af2ab8",
"status": "affected",
"version": "e284fc280473bed23f2e1ed324e102a48f7d17e1",
"versionType": "git"
},
{
"lessThan": "e490d8c5a54e0dd1ab22417d72c3a7319cf0f030",
"status": "affected",
"version": "e284fc280473bed23f2e1ed324e102a48f7d17e1",
"versionType": "git"
},
{
"lessThan": "77a35be582dff4c80442ebcdce24d45eed8a6ce4",
"status": "affected",
"version": "e284fc280473bed23f2e1ed324e102a48f7d17e1",
"versionType": "git"
},
{
"lessThan": "02aae5fcdd34c3a55a243d80a1b328a35852a35c",
"status": "affected",
"version": "e284fc280473bed23f2e1ed324e102a48f7d17e1",
"versionType": "git"
},
{
"lessThan": "edecce7abd7152b48e279b4fa0a883d1839bb577",
"status": "affected",
"version": "e284fc280473bed23f2e1ed324e102a48f7d17e1",
"versionType": "git"
},
{
"lessThan": "d33e5d6631ac4fddda235a7815babc9d3f124299",
"status": "affected",
"version": "e284fc280473bed23f2e1ed324e102a48f7d17e1",
"versionType": "git"
},
{
"lessThan": "8b13df5aa877b9e4541e301a58a84c42d84d2d9a",
"status": "affected",
"version": "e284fc280473bed23f2e1ed324e102a48f7d17e1",
"versionType": "git"
},
{
"lessThan": "cb79fa7118c150c3c76a327894bb2eb878c02619",
"status": "affected",
"version": "e284fc280473bed23f2e1ed324e102a48f7d17e1",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.17"
},
{
"lessThan": "4.17",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.300",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.245",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.194",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.155",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.109",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.50",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.16.*",
"status": "unaffected",
"version": "6.16.10",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.17",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.300",
"versionStartIncluding": "4.17",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.245",
"versionStartIncluding": "4.17",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.194",
"versionStartIncluding": "4.17",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.155",
"versionStartIncluding": "4.17",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.109",
"versionStartIncluding": "4.17",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.50",
"versionStartIncluding": "4.17",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.16.10",
"versionStartIncluding": "4.17",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.17",
"versionStartIncluding": "4.17",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ni40e: add max boundary check for VF filters\n\nThere is no check for max filters that VF can request. Add it."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7.3,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:L - The trigger is a `VIRTCHNL_OP_ADD_CLOUD_FILTER` message on the SR-IOV VF\u2192PF admin-queue mailbox, a PCIe transport rather than a network protocol. The attacker needs local control of an assigned VF \u2014 kernel/root inside a guest VM, or possession of the VFIO device \u2014 so reachability is local, not network or adjacent.\nAC:L - The attacker simply loops `VIRTCHNL_OP_ADD_CLOUD_FILTER` with a filter matching its own MAC; there is no duplicate check, no race, and no memory grooming, so growth is deterministic from the first message. The only precondition \u2014 ADq enabled with spoofchk off \u2014 is inherent to any ADq-capable SR-IOV deployment and is a standard runtime configuration.\nPR:L - Only the ability to drive the VF\u0027s admin queue is needed, which is a low-privileged position relative to the host PF driver under attack, and no host privileges of any kind are required. Notably `i40e_validate_cloud_filter()` accepts basic-mode filters from an untrusted VF, so even the trusted-VF bit is unnecessary.\nUI:N - The malicious VF drives the entire message flood on its own initiative. No host administrator or other user action is required at exploitation time.\nS:C - The attacking VF resides in a guest VM (or VF-assigned container) while the unbounded allocations, leaked memory, service-task starvation and hardware filter-table exhaustion all land in the host PF driver\u0027s security authority. The damage extends to the host and to every other VF sharing the adapter, crossing the guest/host and inter-tenant SR-IOV boundary.\nC:N - The defect is a missing upper bound on counted allocations; there is no out-of-bounds read, no uninitialized data returned, and the VF only ever receives an `aq_ret` status code. The `u16` counter wrap has no consumers, so no memory contents are exposed.\nI:L - Each successful add emits an unratelimited `dev_info()` from `i40e_add_del_cloud_filter()`, so a guest can push tens of thousands of lines through the host kernel log and roll away the host\u0027s diagnostic and audit records, and can also monopolize the PF-wide hardware cloud-filter table so the host\u0027s and other tenants\u0027 legitimate steering rules fail to install. The attacker has no control over which host data is displaced, so the modification is limited rather than arbitrary.\nA:H - A guest can allocate `struct i40e_cloud_filter` objects without limit until the host OOMs, and because `i40e_free_vf_res()`/`i40e_free_vfs()` never walk `vf-\u003ecloud_filter_list`, the memory is permanently leaked across every VF reset and SR-IOV teardown. The flood also monopolizes the PF\u0027s single service-task workqueue with synchronous firmware AQ round-trips, stalling watchdog, link and reset handling and taking host networking \u2014 and thus every guest on the adapter \u2014 down with it."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T12:06:37.397Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/9176e18681cb0d34c5acc87bda224f5652af2ab8"
},
{
"url": "https://git.kernel.org/stable/c/e490d8c5a54e0dd1ab22417d72c3a7319cf0f030"
},
{
"url": "https://git.kernel.org/stable/c/77a35be582dff4c80442ebcdce24d45eed8a6ce4"
},
{
"url": "https://git.kernel.org/stable/c/02aae5fcdd34c3a55a243d80a1b328a35852a35c"
},
{
"url": "https://git.kernel.org/stable/c/edecce7abd7152b48e279b4fa0a883d1839bb577"
},
{
"url": "https://git.kernel.org/stable/c/d33e5d6631ac4fddda235a7815babc9d3f124299"
},
{
"url": "https://git.kernel.org/stable/c/8b13df5aa877b9e4541e301a58a84c42d84d2d9a"
},
{
"url": "https://git.kernel.org/stable/c/cb79fa7118c150c3c76a327894bb2eb878c02619"
}
],
"title": "i40e: add max boundary check for VF filters",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-39968",
"datePublished": "2025-10-15T07:55:52.272Z",
"dateReserved": "2025-04-16T07:20:57.149Z",
"dateUpdated": "2026-08-05T12:06:37.397Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2025-39968",
"date": "2026-09-19",
"epss": "0.00147",
"percentile": "0.04307"
},
"microsoft_vex": {
"current_release_date": "2025-10-16T01:01:21.000Z",
"cve": "CVE-2025-39968",
"id": "msrc_CVE-2025-39968",
"initial_release_date": "2025-10-02T00:00:00.000Z",
"product_status:fixed": "1",
"product_status:known_affected": "2",
"source": "Microsoft CSAF VEX",
"status": "final",
"title": "i40e: add max boundary check for VF filters",
"url": "https://msrc.microsoft.com/csaf/vex/2025/msrc_cve-2025-39968.json",
"version": "1"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "9176e18681cb0d34c5acc87bda224f5652af2ab8",
"status": "affected",
"version": "e284fc280473bed23f2e1ed324e102a48f7d17e1",
"versionType": "git"
},
{
"lessThan": "e490d8c5a54e0dd1ab22417d72c3a7319cf0f030",
"status": "affected",
"version": "e284fc280473bed23f2e1ed324e102a48f7d17e1",
"versionType": "git"
},
{
"lessThan": "77a35be582dff4c80442ebcdce24d45eed8a6ce4",
"status": "affected",
"version": "e284fc280473bed23f2e1ed324e102a48f7d17e1",
"versionType": "git"
},
{
"lessThan": "02aae5fcdd34c3a55a243d80a1b328a35852a35c",
"status": "affected",
"version": "e284fc280473bed23f2e1ed324e102a48f7d17e1",
"versionType": "git"
},
{
"lessThan": "edecce7abd7152b48e279b4fa0a883d1839bb577",
"status": "affected",
"version": "e284fc280473bed23f2e1ed324e102a48f7d17e1",
"versionType": "git"
},
{
"lessThan": "d33e5d6631ac4fddda235a7815babc9d3f124299",
"status": "affected",
"version": "e284fc280473bed23f2e1ed324e102a48f7d17e1",
"versionType": "git"
},
{
"lessThan": "8b13df5aa877b9e4541e301a58a84c42d84d2d9a",
"status": "affected",
"version": "e284fc280473bed23f2e1ed324e102a48f7d17e1",
"versionType": "git"
},
{
"lessThan": "cb79fa7118c150c3c76a327894bb2eb878c02619",
"status": "affected",
"version": "e284fc280473bed23f2e1ed324e102a48f7d17e1",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.17"
},
{
"lessThan": "4.17",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.300",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.245",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.194",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.155",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.109",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.50",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.16.*",
"status": "unaffected",
"version": "6.16.10",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.17",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ni40e: add max boundary check for VF filters\n\nThere is no check for max filters that VF can request. Add it."
}
],
"id": "CVE-2025-39968",
"lastModified": "2026-07-30T06:24:02.520",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.3,
"baseSeverity": "HIGH",
"confidentialityImpact": "NONE",
"integrityImpact": "LOW",
"privilegesRequired": "LOW",
"scope": "CHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:H",
"version": "3.1"
},
"exploitabilityScore": 2.0,
"impactScore": 4.7,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
}
]
},
"published": "2025-10-15T08:15:34.350",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/02aae5fcdd34c3a55a243d80a1b328a35852a35c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/77a35be582dff4c80442ebcdce24d45eed8a6ce4"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/8b13df5aa877b9e4541e301a58a84c42d84d2d9a"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/9176e18681cb0d34c5acc87bda224f5652af2ab8"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/cb79fa7118c150c3c76a327894bb2eb878c02619"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/d33e5d6631ac4fddda235a7815babc9d3f124299"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/e490d8c5a54e0dd1ab22417d72c3a7319cf0f030"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/edecce7abd7152b48e279b4fa0a883d1839bb577"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Deferred"
}
},
"redhat_vex": {
"aggregate_severity": "Moderate",
"current_release_date": "2026-07-30T08:53:49+00:00",
"cve": "CVE-2025-39968",
"id": "CVE-2025-39968",
"initial_release_date": "2025-10-15T00:00:00+00:00",
"product_status:known_affected": "260",
"product_status:known_not_affected": "14",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: Linux kernel i40e: Resource exhaustion via unbounded VF filter requests",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2025/cve-2025-39968.json",
"version": "3"
}
}
}
CERTFR-2026-AVI-0602
Vulnerability from certfr_avis - Published: 2026-05-15 - Updated: 2026-05-15
De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Certaines d'entre elles permettent à un attaquant de provoquer une élévation de privilèges, une atteinte à la confidentialité des données et une atteinte à l'intégrité des données.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Title | Publication Time | Tags | ||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Ubuntu 16.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 20.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 24.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 18.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 22.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
}
],
"affected_systems_content": "",
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2025-40166",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40166"
},
{
"name": "CVE-2025-71075",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71075"
},
{
"name": "CVE-2025-40273",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40273"
},
{
"name": "CVE-2025-39992",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39992"
},
{
"name": "CVE-2024-50142",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50142"
},
{
"name": "CVE-2025-39987",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39987"
},
{
"name": "CVE-2025-71086",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71086"
},
{
"name": "CVE-2025-39812",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39812"
},
{
"name": "CVE-2026-23167",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23167"
},
{
"name": "CVE-2025-40156",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40156"
},
{
"name": "CVE-2025-71065",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71065"
},
{
"name": "CVE-2025-68342",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68342"
},
{
"name": "CVE-2025-68374",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68374"
},
{
"name": "CVE-2025-40137",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40137"
},
{
"name": "CVE-2025-22107",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22107"
},
{
"name": "CVE-2026-23098",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23098"
},
{
"name": "CVE-2025-39808",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39808"
},
{
"name": "CVE-2025-68286",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68286"
},
{
"name": "CVE-2025-40057",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40057"
},
{
"name": "CVE-2025-71094",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71094"
},
{
"name": "CVE-2025-68788",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68788"
},
{
"name": "CVE-2025-40055",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40055"
},
{
"name": "CVE-2025-39876",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39876"
},
{
"name": "CVE-2025-40314",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40314"
},
{
"name": "CVE-2025-40029",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40029"
},
{
"name": "CVE-2025-40037",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40037"
},
{
"name": "CVE-2025-40306",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40306"
},
{
"name": "CVE-2025-40008",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40008"
},
{
"name": "CVE-2025-39947",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39947"
},
{
"name": "CVE-2025-68778",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68778"
},
{
"name": "CVE-2025-40048",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40048"
},
{
"name": "CVE-2025-40254",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40254"
},
{
"name": "CVE-2025-71064",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71064"
},
{
"name": "CVE-2025-40219",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40219"
},
{
"name": "CVE-2025-68200",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68200"
},
{
"name": "CVE-2025-39902",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39902"
},
{
"name": "CVE-2025-40043",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40043"
},
{
"name": "CVE-2025-68725",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68725"
},
{
"name": "CVE-2025-68176",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68176"
},
{
"name": "CVE-2025-68741",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68741"
},
{
"name": "CVE-2025-68204",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68204"
},
{
"name": "CVE-2025-68795",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68795"
},
{
"name": "CVE-2025-68349",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68349"
},
{
"name": "CVE-2025-39948",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39948"
},
{
"name": "CVE-2025-39826",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39826"
},
{
"name": "CVE-2025-68380",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68380"
},
{
"name": "CVE-2026-23269",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23269"
},
{
"name": "CVE-2025-39973",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39973"
},
{
"name": "CVE-2025-39881",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39881"
},
{
"name": "CVE-2023-2640",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2640"
},
{
"name": "CVE-2025-68283",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68283"
},
{
"name": "CVE-2025-68246",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68246"
},
{
"name": "CVE-2025-68339",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68339"
},
{
"name": "CVE-2025-40287",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40287"
},
{
"name": "CVE-2025-39943",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39943"
},
{
"name": "CVE-2025-39945",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39945"
},
{
"name": "CVE-2023-53421",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53421"
},
{
"name": "CVE-2025-39883",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39883"
},
{
"name": "CVE-2025-71071",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71071"
},
{
"name": "CVE-2025-71191",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71191"
},
{
"name": "CVE-2025-68295",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68295"
},
{
"name": "CVE-2025-23129",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23129"
},
{
"name": "CVE-2025-68728",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68728"
},
{
"name": "CVE-2025-68364",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68364"
},
{
"name": "CVE-2025-40100",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40100"
},
{
"name": "CVE-2025-71087",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71087"
},
{
"name": "CVE-2025-40285",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40285"
},
{
"name": "CVE-2025-39827",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39827"
},
{
"name": "CVE-2025-22106",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22106"
},
{
"name": "CVE-2025-68287",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68287"
},
{
"name": "CVE-2025-40240",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40240"
},
{
"name": "CVE-2025-39828",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39828"
},
{
"name": "CVE-2025-71135",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71135"
},
{
"name": "CVE-2025-40081",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40081"
},
{
"name": "CVE-2025-68746",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68746"
},
{
"name": "CVE-2025-68773",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68773"
},
{
"name": "CVE-2025-71133",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71133"
},
{
"name": "CVE-2025-40026",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40026"
},
{
"name": "CVE-2025-40153",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40153"
},
{
"name": "CVE-2025-40103",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40103"
},
{
"name": "CVE-2025-40294",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40294"
},
{
"name": "CVE-2025-68796",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68796"
},
{
"name": "CVE-2025-40016",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40016"
},
{
"name": "CVE-2025-40121",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40121"
},
{
"name": "CVE-2025-40312",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40312"
},
{
"name": "CVE-2025-40204",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40204"
},
{
"name": "CVE-2025-68220",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68220"
},
{
"name": "CVE-2025-22125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22125"
},
{
"name": "CVE-2025-40171",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40171"
},
{
"name": "CVE-2025-68302",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68302"
},
{
"name": "CVE-2025-68238",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68238"
},
{
"name": "CVE-2025-68297",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68297"
},
{
"name": "CVE-2025-40221",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40221"
},
{
"name": "CVE-2025-68804",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68804"
},
{
"name": "CVE-2025-68769",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68769"
},
{
"name": "CVE-2025-39811",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39811"
},
{
"name": "CVE-2025-68794",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68794"
},
{
"name": "CVE-2025-40056",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40056"
},
{
"name": "CVE-2025-39911",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39911"
},
{
"name": "CVE-2025-40125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40125"
},
{
"name": "CVE-2025-40350",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40350"
},
{
"name": "CVE-2025-40309",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40309"
},
{
"name": "CVE-2025-40349",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40349"
},
{
"name": "CVE-2025-40052",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40052"
},
{
"name": "CVE-2025-38408",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38408"
},
{
"name": "CVE-2025-71088",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71088"
},
{
"name": "CVE-2025-40343",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40343"
},
{
"name": "CVE-2025-68173",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68173"
},
{
"name": "CVE-2026-23090",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23090"
},
{
"name": "CVE-2025-22103",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22103"
},
{
"name": "CVE-2025-68307",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68307"
},
{
"name": "CVE-2025-40308",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40308"
},
{
"name": "CVE-2025-40187",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40187"
},
{
"name": "CVE-2025-40315",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40315"
},
{
"name": "CVE-2025-37860",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37860"
},
{
"name": "CVE-2025-39913",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39913"
},
{
"name": "CVE-2025-68231",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68231"
},
{
"name": "CVE-2025-39950",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39950"
},
{
"name": "CVE-2026-23064",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23064"
},
{
"name": "CVE-2025-38591",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38591"
},
{
"name": "CVE-2025-68806",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68806"
},
{
"name": "CVE-2025-40092",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40092"
},
{
"name": "CVE-2025-71098",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71098"
},
{
"name": "CVE-2025-40251",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40251"
},
{
"name": "CVE-2025-21735",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21735"
},
{
"name": "CVE-2025-71078",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71078"
},
{
"name": "CVE-2025-39967",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39967"
},
{
"name": "CVE-2025-68184",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68184"
},
{
"name": "CVE-2025-40107",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40107"
},
{
"name": "CVE-2025-71083",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71083"
},
{
"name": "CVE-2026-23061",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23061"
},
{
"name": "CVE-2025-40115",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40115"
},
{
"name": "CVE-2025-68813",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68813"
},
{
"name": "CVE-2025-22121",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22121"
},
{
"name": "CVE-2025-68365",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68365"
},
{
"name": "CVE-2025-68265",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68265"
},
{
"name": "CVE-2026-23119",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23119"
},
{
"name": "CVE-2025-71085",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71085"
},
{
"name": "CVE-2026-23268",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23268"
},
{
"name": "CVE-2025-39920",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39920"
},
{
"name": "CVE-2025-40058",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40058"
},
{
"name": "CVE-2025-68344",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68344"
},
{
"name": "CVE-2025-40347",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40347"
},
{
"name": "CVE-2025-71154",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71154"
},
{
"name": "CVE-2022-49046",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49046"
},
{
"name": "CVE-2025-40198",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40198"
},
{
"name": "CVE-2025-39942",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39942"
},
{
"name": "CVE-2025-68310",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68310"
},
{
"name": "CVE-2025-68179",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68179"
},
{
"name": "CVE-2025-68229",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68229"
},
{
"name": "CVE-2025-68257",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68257"
},
{
"name": "CVE-2025-39929",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39929"
},
{
"name": "CVE-2025-39949",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39949"
},
{
"name": "CVE-2024-46816",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46816"
},
{
"name": "CVE-2025-71084",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71084"
},
{
"name": "CVE-2025-40173",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40173"
},
{
"name": "CVE-2026-23049",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23049"
},
{
"name": "CVE-2025-68321",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68321"
},
{
"name": "CVE-2025-68347",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68347"
},
{
"name": "CVE-2025-40010",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40010"
},
{
"name": "CVE-2025-39944",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39944"
},
{
"name": "CVE-2025-39923",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39923"
},
{
"name": "CVE-2025-68235",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68235"
},
{
"name": "CVE-2025-68770",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68770"
},
{
"name": "CVE-2025-39866",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39866"
},
{
"name": "CVE-2025-39843",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39843"
},
{
"name": "CVE-2025-40202",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40202"
},
{
"name": "CVE-2025-40311",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40311"
},
{
"name": "CVE-2025-68814",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68814"
},
{
"name": "CVE-2025-40237",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40237"
},
{
"name": "CVE-2025-68780",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68780"
},
{
"name": "CVE-2025-39953",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39953"
},
{
"name": "CVE-2025-71081",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71081"
},
{
"name": "CVE-2026-23101",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23101"
},
{
"name": "CVE-2026-23407",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23407"
},
{
"name": "CVE-2026-23099",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23099"
},
{
"name": "CVE-2025-40167",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40167"
},
{
"name": "CVE-2025-38105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38105"
},
{
"name": "CVE-2025-39969",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39969"
},
{
"name": "CVE-2025-71121",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71121"
},
{
"name": "CVE-2025-40194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40194"
},
{
"name": "CVE-2025-40333",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40333"
},
{
"name": "CVE-2025-38022",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38022"
},
{
"name": "CVE-2025-40245",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40245"
},
{
"name": "CVE-2025-39899",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39899"
},
{
"name": "CVE-2025-71080",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71080"
},
{
"name": "CVE-2023-53520",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53520"
},
{
"name": "CVE-2026-23085",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23085"
},
{
"name": "CVE-2025-40360",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40360"
},
{
"name": "CVE-2026-23209",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23209"
},
{
"name": "CVE-2025-71136",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71136"
},
{
"name": "CVE-2025-22105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22105"
},
{
"name": "CVE-2025-68354",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68354"
},
{
"name": "CVE-2025-68801",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68801"
},
{
"name": "CVE-2025-21833",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21833"
},
{
"name": "CVE-2026-23150",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23150"
},
{
"name": "CVE-2025-40104",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40104"
},
{
"name": "CVE-2025-68258",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68258"
},
{
"name": "CVE-2025-39853",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39853"
},
{
"name": "CVE-2025-40001",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40001"
},
{
"name": "CVE-2025-39871",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39871"
},
{
"name": "CVE-2025-39857",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39857"
},
{
"name": "CVE-2025-38709",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38709"
},
{
"name": "CVE-2025-40035",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40035"
},
{
"name": "CVE-2025-40322",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40322"
},
{
"name": "CVE-2025-39988",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39988"
},
{
"name": "CVE-2025-40313",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40313"
},
{
"name": "CVE-2025-39865",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39865"
},
{
"name": "CVE-2025-71138",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71138"
},
{
"name": "CVE-2025-40233",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40233"
},
{
"name": "CVE-2025-40172",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40172"
},
{
"name": "CVE-2025-40020",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40020"
},
{
"name": "CVE-2024-46777",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46777"
},
{
"name": "CVE-2025-40188",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40188"
},
{
"name": "CVE-2025-40271",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40271"
},
{
"name": "CVE-2025-68291",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68291"
},
{
"name": "CVE-2025-39877",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39877"
},
{
"name": "CVE-2025-71122",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71122"
},
{
"name": "CVE-2025-38502",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38502"
},
{
"name": "CVE-2025-39886",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39886"
},
{
"name": "CVE-2025-68763",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68763"
},
{
"name": "CVE-2025-71144",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71144"
},
{
"name": "CVE-2025-68308",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68308"
},
{
"name": "CVE-2025-40242",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40242"
},
{
"name": "CVE-2025-39838",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39838"
},
{
"name": "CVE-2025-39823",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39823"
},
{
"name": "CVE-2025-68198",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68198"
},
{
"name": "CVE-2026-23408",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23408"
},
{
"name": "CVE-2025-38234",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38234"
},
{
"name": "CVE-2025-39864",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39864"
},
{
"name": "CVE-2025-40013",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40013"
},
{
"name": "CVE-2025-68190",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68190"
},
{
"name": "CVE-2025-40169",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40169"
},
{
"name": "CVE-2025-39824",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39824"
},
{
"name": "CVE-2025-40252",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40252"
},
{
"name": "CVE-2025-68218",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68218"
},
{
"name": "CVE-2025-40049",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40049"
},
{
"name": "CVE-2025-68255",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68255"
},
{
"name": "CVE-2025-68322",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68322"
},
{
"name": "CVE-2025-39927",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39927"
},
{
"name": "CVE-2025-40024",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40024"
},
{
"name": "CVE-2025-40238",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40238"
},
{
"name": "CVE-2025-40277",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40277"
},
{
"name": "CVE-2025-40070",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40070"
},
{
"name": "CVE-2025-40106",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40106"
},
{
"name": "CVE-2025-40272",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40272"
},
{
"name": "CVE-2025-39842",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39842"
},
{
"name": "CVE-2025-40047",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40047"
},
{
"name": "CVE-2026-23133",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23133"
},
{
"name": "CVE-2026-23406",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23406"
},
{
"name": "CVE-2025-71093",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71093"
},
{
"name": "CVE-2025-71102",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71102"
},
{
"name": "CVE-2026-23170",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23170"
},
{
"name": "CVE-2025-68759",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68759"
},
{
"name": "CVE-2026-23273",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23273"
},
{
"name": "CVE-2025-71188",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71188"
},
{
"name": "CVE-2025-39815",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39815"
},
{
"name": "CVE-2025-40345",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40345"
},
{
"name": "CVE-2025-40205",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40205"
},
{
"name": "CVE-2026-23125",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23125"
},
{
"name": "CVE-2025-39849",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39849"
},
{
"name": "CVE-2025-40033",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40033"
},
{
"name": "CVE-2025-38057",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38057"
},
{
"name": "CVE-2025-68733",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68733"
},
{
"name": "CVE-2025-39894",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39894"
},
{
"name": "CVE-2025-39861",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39861"
},
{
"name": "CVE-2025-40269",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40269"
},
{
"name": "CVE-2025-68335",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68335"
},
{
"name": "CVE-2025-71079",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71079"
},
{
"name": "CVE-2025-39940",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39940"
},
{
"name": "CVE-2026-22997",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22997"
},
{
"name": "CVE-2025-71153",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71153"
},
{
"name": "CVE-2025-39977",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39977"
},
{
"name": "CVE-2025-68330",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68330"
},
{
"name": "CVE-2023-53662",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53662"
},
{
"name": "CVE-2025-71196",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71196"
},
{
"name": "CVE-2024-27388",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27388"
},
{
"name": "CVE-2025-40027",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40027"
},
{
"name": "CVE-2025-39885",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39885"
},
{
"name": "CVE-2025-68180",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68180"
},
{
"name": "CVE-2025-68772",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68772"
},
{
"name": "CVE-2025-68343",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68343"
},
{
"name": "CVE-2024-57795",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57795"
},
{
"name": "CVE-2026-23078",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23078"
},
{
"name": "CVE-2025-68201",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68201"
},
{
"name": "CVE-2025-40289",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40289"
},
{
"name": "CVE-2025-71143",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71143"
},
{
"name": "CVE-2025-68785",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68785"
},
{
"name": "CVE-2025-71130",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71130"
},
{
"name": "CVE-2025-68808",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68808"
},
{
"name": "CVE-2025-68223",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68223"
},
{
"name": "CVE-2025-68783",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68783"
},
{
"name": "CVE-2025-39970",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39970"
},
{
"name": "CVE-2025-40292",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40292"
},
{
"name": "CVE-2025-71147",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71147"
},
{
"name": "CVE-2025-40032",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40032"
},
{
"name": "CVE-2025-39981",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39981"
},
{
"name": "CVE-2025-68724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68724"
},
{
"name": "CVE-2025-39994",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39994"
},
{
"name": "CVE-2026-23103",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23103"
},
{
"name": "CVE-2026-23074",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23074"
},
{
"name": "CVE-2025-71126",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71126"
},
{
"name": "CVE-2025-68786",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68786"
},
{
"name": "CVE-2025-71199",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71199"
},
{
"name": "CVE-2023-32629",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-32629"
},
{
"name": "CVE-2025-68797",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68797"
},
{
"name": "CVE-2025-38627",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38627"
},
{
"name": "CVE-2025-40206",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40206"
},
{
"name": "CVE-2025-40218",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40218"
},
{
"name": "CVE-2025-40088",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40088"
},
{
"name": "CVE-2025-40220",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40220"
},
{
"name": "CVE-2025-39845",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39845"
},
{
"name": "CVE-2025-68237",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68237"
},
{
"name": "CVE-2025-40257",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40257"
},
{
"name": "CVE-2025-68259",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68259"
},
{
"name": "CVE-2025-71125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71125"
},
{
"name": "CVE-2025-71108",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71108"
},
{
"name": "CVE-2025-71069",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71069"
},
{
"name": "CVE-2025-68312",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68312"
},
{
"name": "CVE-2025-68284",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68284"
},
{
"name": "CVE-2025-40062",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40062"
},
{
"name": "CVE-2025-68194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68194"
},
{
"name": "CVE-2025-40067",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40067"
},
{
"name": "CVE-2025-40109",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40109"
},
{
"name": "CVE-2025-40101",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40101"
},
{
"name": "CVE-2025-40006",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40006"
},
{
"name": "CVE-2026-23083",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23083"
},
{
"name": "CVE-2025-40038",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40038"
},
{
"name": "CVE-2025-68183",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68183"
},
{
"name": "CVE-2025-39805",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39805"
},
{
"name": "CVE-2025-68774",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68774"
},
{
"name": "CVE-2025-40263",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40263"
},
{
"name": "CVE-2025-40353",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40353"
},
{
"name": "CVE-2025-40011",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40011"
},
{
"name": "CVE-2026-23108",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23108"
},
{
"name": "CVE-2025-40085",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40085"
},
{
"name": "CVE-2025-38232",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38232"
},
{
"name": "CVE-2025-68244",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68244"
},
{
"name": "CVE-2025-40231",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40231"
},
{
"name": "CVE-2025-40278",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40278"
},
{
"name": "CVE-2025-71194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71194"
},
{
"name": "CVE-2025-22113",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22113"
},
{
"name": "CVE-2025-40176",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40176"
},
{
"name": "CVE-2025-40342",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40342"
},
{
"name": "CVE-2026-22999",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22999"
},
{
"name": "CVE-2025-71082",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71082"
},
{
"name": "CVE-2025-68222",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68222"
},
{
"name": "CVE-2025-68765",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68765"
},
{
"name": "CVE-2026-23089",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23089"
},
{
"name": "CVE-2025-23143",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23143"
},
{
"name": "CVE-2025-71132",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71132"
},
{
"name": "CVE-2026-23071",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23071"
},
{
"name": "CVE-2026-23056",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23056"
},
{
"name": "CVE-2025-40193",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40193"
},
{
"name": "CVE-2025-71077",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71077"
},
{
"name": "CVE-2025-40279",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40279"
},
{
"name": "CVE-2025-68328",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68328"
},
{
"name": "CVE-2025-40201",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40201"
},
{
"name": "CVE-2025-71140",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71140"
},
{
"name": "CVE-2025-40084",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40084"
},
{
"name": "CVE-2025-22111",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22111"
},
{
"name": "CVE-2024-49938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49938"
},
{
"name": "CVE-2026-23063",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23063"
},
{
"name": "CVE-2026-23073",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23073"
},
{
"name": "CVE-2025-68311",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68311"
},
{
"name": "CVE-2025-71114",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71114"
},
{
"name": "CVE-2026-23058",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23058"
},
{
"name": "CVE-2025-71067",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71067"
},
{
"name": "CVE-2025-68744",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68744"
},
{
"name": "CVE-2025-68320",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68320"
},
{
"name": "CVE-2026-23038",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23038"
},
{
"name": "CVE-2025-40341",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40341"
},
{
"name": "CVE-2025-40183",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40183"
},
{
"name": "CVE-2025-71151",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71151"
},
{
"name": "CVE-2024-50008",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50008"
},
{
"name": "CVE-2025-68172",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68172"
},
{
"name": "CVE-2025-71186",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71186"
},
{
"name": "CVE-2025-39998",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39998"
},
{
"name": "CVE-2025-68821",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68821"
},
{
"name": "CVE-2026-23026",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23026"
},
{
"name": "CVE-2025-40134",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40134"
},
{
"name": "CVE-2026-23128",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23128"
},
{
"name": "CVE-2025-68325",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68325"
},
{
"name": "CVE-2025-71190",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71190"
},
{
"name": "CVE-2025-39968",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39968"
},
{
"name": "CVE-2025-71089",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71089"
},
{
"name": "CVE-2025-40358",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40358"
},
{
"name": "CVE-2025-40165",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40165"
},
{
"name": "CVE-2025-40328",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40328"
},
{
"name": "CVE-2025-68332",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68332"
},
{
"name": "CVE-2025-39986",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39986"
},
{
"name": "CVE-2025-71104",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71104"
},
{
"name": "CVE-2025-39901",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39901"
},
{
"name": "CVE-2025-40283",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40283"
},
{
"name": "CVE-2025-39955",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39955"
},
{
"name": "CVE-2025-40324",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40324"
},
{
"name": "CVE-2025-68378",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68378"
},
{
"name": "CVE-2025-71141",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71141"
},
{
"name": "CVE-2026-23146",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23146"
},
{
"name": "CVE-2026-23037",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23037"
},
{
"name": "CVE-2026-23410",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23410"
},
{
"name": "CVE-2025-40250",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40250"
},
{
"name": "CVE-2025-71101",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71101"
},
{
"name": "CVE-2025-40264",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40264"
},
{
"name": "CVE-2026-23001",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23001"
},
{
"name": "CVE-2025-68367",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68367"
},
{
"name": "CVE-2025-40226",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40226"
},
{
"name": "CVE-2025-40078",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40078"
},
{
"name": "CVE-2025-68820",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68820"
},
{
"name": "CVE-2025-68756",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68756"
},
{
"name": "CVE-2025-40321",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40321"
},
{
"name": "CVE-2025-40116",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40116"
},
{
"name": "CVE-2025-39895",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39895"
},
{
"name": "CVE-2023-54207",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54207"
},
{
"name": "CVE-2025-68249",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68249"
},
{
"name": "CVE-2025-68740",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68740"
},
{
"name": "CVE-2025-39934",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39934"
},
{
"name": "CVE-2025-39978",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39978"
},
{
"name": "CVE-2025-40179",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40179"
},
{
"name": "CVE-2025-68742",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68742"
},
{
"name": "CVE-2025-40127",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40127"
},
{
"name": "CVE-2025-40282",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40282"
},
{
"name": "CVE-2025-39996",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39996"
},
{
"name": "CVE-2025-40053",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40053"
},
{
"name": "CVE-2025-39951",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39951"
},
{
"name": "CVE-2025-40120",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40120"
},
{
"name": "CVE-2025-68816",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68816"
},
{
"name": "CVE-2025-39914",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39914"
},
{
"name": "CVE-2025-68192",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68192"
},
{
"name": "CVE-2025-39697",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39697"
},
{
"name": "CVE-2025-68379",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68379"
},
{
"name": "CVE-2025-68256",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68256"
},
{
"name": "CVE-2025-68777",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68777"
},
{
"name": "CVE-2025-68254",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68254"
},
{
"name": "CVE-2025-39938",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39938"
},
{
"name": "CVE-2025-40243",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40243"
},
{
"name": "CVE-2025-40196",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40196"
},
{
"name": "CVE-2025-39982",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39982"
},
{
"name": "CVE-2025-40129",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40129"
},
{
"name": "CVE-2025-39965",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39965"
},
{
"name": "CVE-2025-38556",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38556"
},
{
"name": "CVE-2025-68171",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68171"
},
{
"name": "CVE-2025-39932",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39932"
},
{
"name": "CVE-2025-40301",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40301"
},
{
"name": "CVE-2025-39810",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39810"
},
{
"name": "CVE-2025-71109",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71109"
},
{
"name": "CVE-2025-40207",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40207"
},
{
"name": "CVE-2025-40095",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40095"
},
{
"name": "CVE-2025-71118",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71118"
},
{
"name": "CVE-2025-39860",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39860"
},
{
"name": "CVE-2025-40286",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40286"
},
{
"name": "CVE-2025-68327",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68327"
},
{
"name": "CVE-2025-40318",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40318"
},
{
"name": "CVE-2025-71150",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71150"
},
{
"name": "CVE-2025-40266",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40266"
},
{
"name": "CVE-2026-23091",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23091"
},
{
"name": "CVE-2025-68241",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68241"
},
{
"name": "CVE-2025-40118",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40118"
},
{
"name": "CVE-2025-40021",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40021"
},
{
"name": "CVE-2025-39839",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39839"
},
{
"name": "CVE-2026-23121",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23121"
},
{
"name": "CVE-2025-68734",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68734"
},
{
"name": "CVE-2025-68776",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68776"
},
{
"name": "CVE-2025-71066",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71066"
},
{
"name": "CVE-2025-39848",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39848"
},
{
"name": "CVE-2025-68799",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68799"
},
{
"name": "CVE-2025-68345",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68345"
},
{
"name": "CVE-2025-40044",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40044"
},
{
"name": "CVE-2025-71097",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71097"
},
{
"name": "CVE-2025-40105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40105"
},
{
"name": "CVE-2025-68288",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68288"
},
{
"name": "CVE-2025-39916",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39916"
},
{
"name": "CVE-2025-40112",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40112"
},
{
"name": "CVE-2025-71107",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71107"
},
{
"name": "CVE-2025-40079",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40079"
},
{
"name": "CVE-2025-40310",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40310"
},
{
"name": "CVE-2025-40083",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40083"
},
{
"name": "CVE-2025-71111",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71111"
},
{
"name": "CVE-2026-23087",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23087"
},
{
"name": "CVE-2025-39971",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39971"
},
{
"name": "CVE-2025-71185",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71185"
},
{
"name": "CVE-2025-40154",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40154"
},
{
"name": "CVE-2025-40331",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40331"
},
{
"name": "CVE-2025-68811",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68811"
},
{
"name": "CVE-2026-23096",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23096"
},
{
"name": "CVE-2025-68337",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68337"
},
{
"name": "CVE-2025-40093",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40093"
},
{
"name": "CVE-2026-23405",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23405"
},
{
"name": "CVE-2025-39825",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39825"
},
{
"name": "CVE-2025-71131",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71131"
},
{
"name": "CVE-2025-40149",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40149"
},
{
"name": "CVE-2026-23403",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23403"
},
{
"name": "CVE-2025-40164",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40164"
},
{
"name": "CVE-2025-39852",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39852"
},
{
"name": "CVE-2026-23164",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23164"
},
{
"name": "CVE-2025-71116",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71116"
},
{
"name": "CVE-2025-40235",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40235"
},
{
"name": "CVE-2025-39991",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39991"
},
{
"name": "CVE-2026-23124",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23124"
},
{
"name": "CVE-2025-68208",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68208"
},
{
"name": "CVE-2025-68362",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68362"
},
{
"name": "CVE-2025-39806",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39806"
},
{
"name": "CVE-2025-68290",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68290"
},
{
"name": "CVE-2025-40280",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40280"
},
{
"name": "CVE-2025-40099",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40099"
},
{
"name": "CVE-2025-71162",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71162"
},
{
"name": "CVE-2026-23075",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23075"
},
{
"name": "CVE-2026-23120",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23120"
},
{
"name": "CVE-2025-40031",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40031"
},
{
"name": "CVE-2025-40180",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40180"
},
{
"name": "CVE-2025-40293",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40293"
},
{
"name": "CVE-2025-39851",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39851"
},
{
"name": "CVE-2025-68331",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68331"
},
{
"name": "CVE-2025-40126",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40126"
},
{
"name": "CVE-2025-39972",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39972"
},
{
"name": "CVE-2026-23105",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23105"
},
{
"name": "CVE-2025-68305",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68305"
},
{
"name": "CVE-2025-68214",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68214"
},
{
"name": "CVE-2025-40320",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40320"
},
{
"name": "CVE-2025-39870",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39870"
},
{
"name": "CVE-2025-68753",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68753"
},
{
"name": "CVE-2025-68369",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68369"
},
{
"name": "CVE-2025-39807",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39807"
},
{
"name": "CVE-2025-68775",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68775"
},
{
"name": "CVE-2025-71112",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71112"
},
{
"name": "CVE-2025-22022",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22022"
},
{
"name": "CVE-2025-40192",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40192"
},
{
"name": "CVE-2025-40200",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40200"
},
{
"name": "CVE-2025-68818",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68818"
},
{
"name": "CVE-2025-40124",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40124"
},
{
"name": "CVE-2025-39880",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39880"
},
{
"name": "CVE-2025-40094",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40094"
},
{
"name": "CVE-2025-40160",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40160"
},
{
"name": "CVE-2025-40284",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40284"
},
{
"name": "CVE-2025-38125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38125"
},
{
"name": "CVE-2025-40077",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40077"
},
{
"name": "CVE-2025-40071",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40071"
},
{
"name": "CVE-2025-71148",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71148"
},
{
"name": "CVE-2025-68366",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68366"
},
{
"name": "CVE-2025-40305",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40305"
},
{
"name": "CVE-2025-40080",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40080"
},
{
"name": "CVE-2025-39846",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39846"
},
{
"name": "CVE-2024-36347",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36347"
},
{
"name": "CVE-2025-68815",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68815"
},
{
"name": "CVE-2025-40307",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40307"
},
{
"name": "CVE-2026-23095",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23095"
},
{
"name": "CVE-2025-40111",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40111"
},
{
"name": "CVE-2025-68346",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68346"
},
{
"name": "CVE-2025-71163",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71163"
},
{
"name": "CVE-2025-40211",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40211"
},
{
"name": "CVE-2025-40068",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40068"
},
{
"name": "CVE-2025-68315",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68315"
},
{
"name": "CVE-2025-39850",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39850"
},
{
"name": "CVE-2025-40042",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40042"
},
{
"name": "CVE-2025-40155",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40155"
},
{
"name": "CVE-2025-71096",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71096"
},
{
"name": "CVE-2025-39844",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39844"
},
{
"name": "CVE-2025-71095",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71095"
},
{
"name": "CVE-2025-71105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71105"
},
{
"name": "CVE-2025-68266",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68266"
},
{
"name": "CVE-2025-68771",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68771"
},
{
"name": "CVE-2025-39961",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39961"
},
{
"name": "CVE-2025-68363",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68363"
},
{
"name": "CVE-2025-40248",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40248"
},
{
"name": "CVE-2026-23411",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23411"
},
{
"name": "CVE-2025-68303",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68303"
},
{
"name": "CVE-2025-39863",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39863"
},
{
"name": "CVE-2025-40259",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40259"
},
{
"name": "CVE-2025-68757",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68757"
},
{
"name": "CVE-2025-71068",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71068"
},
{
"name": "CVE-2025-23130",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23130"
},
{
"name": "CVE-2025-40329",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40329"
},
{
"name": "CVE-2025-39957",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39957"
},
{
"name": "CVE-2026-23033",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23033"
},
{
"name": "CVE-2025-39931",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39931"
},
{
"name": "CVE-2026-23409",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23409"
},
{
"name": "CVE-2026-23145",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23145"
},
{
"name": "CVE-2026-23003",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23003"
},
{
"name": "CVE-2025-39937",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39937"
},
{
"name": "CVE-2025-68766",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68766"
},
{
"name": "CVE-2025-39817",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39817"
},
{
"name": "CVE-2026-23076",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23076"
},
{
"name": "CVE-2025-40060",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40060"
},
{
"name": "CVE-2025-39891",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39891"
},
{
"name": "CVE-2025-40059",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40059"
},
{
"name": "CVE-2025-68168",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68168"
},
{
"name": "CVE-2025-71123",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71123"
},
{
"name": "CVE-2025-68206",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68206"
},
{
"name": "CVE-2025-68372",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68372"
},
{
"name": "CVE-2026-23404",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23404"
},
{
"name": "CVE-2026-23112",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23112"
},
{
"name": "CVE-2025-22124",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22124"
},
{
"name": "CVE-2025-68313",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68313"
},
{
"name": "CVE-2025-71137",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71137"
},
{
"name": "CVE-2026-23084",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23084"
},
{
"name": "CVE-2025-40123",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40123"
},
{
"name": "CVE-2025-68301",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68301"
},
{
"name": "CVE-2025-39854",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39854"
},
{
"name": "CVE-2026-23011",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23011"
},
{
"name": "CVE-2025-68217",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68217"
},
{
"name": "CVE-2025-40178",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40178"
},
{
"name": "CVE-2025-68289",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68289"
},
{
"name": "CVE-2025-40363",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40363"
},
{
"name": "CVE-2025-39869",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39869"
},
{
"name": "CVE-2025-40253",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40253"
},
{
"name": "CVE-2025-39985",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39985"
},
{
"name": "CVE-2025-68245",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68245"
},
{
"name": "CVE-2025-68213",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68213"
},
{
"name": "CVE-2025-39952",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39952"
},
{
"name": "CVE-2025-40317",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40317"
},
{
"name": "CVE-2025-68809",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68809"
},
{
"name": "CVE-2025-68233",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68233"
},
{
"name": "CVE-2025-71120",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71120"
},
{
"name": "CVE-2026-23060",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23060"
},
{
"name": "CVE-2025-68282",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68282"
},
{
"name": "CVE-2025-68817",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68817"
},
{
"name": "CVE-2025-71119",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71119"
},
{
"name": "CVE-2025-68787",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68787"
},
{
"name": "CVE-2025-23133",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23133"
},
{
"name": "CVE-2025-68782",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68782"
},
{
"name": "CVE-2025-71197",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71197"
},
{
"name": "CVE-2025-68177",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68177"
},
{
"name": "CVE-2025-68758",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68758"
},
{
"name": "CVE-2025-68191",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68191"
},
{
"name": "CVE-2025-71113",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71113"
},
{
"name": "CVE-2025-71127",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71127"
},
{
"name": "CVE-2026-22998",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22998"
},
{
"name": "CVE-2025-40141",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40141"
},
{
"name": "CVE-2025-68340",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68340"
},
{
"name": "CVE-2025-39678",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39678"
},
{
"name": "CVE-2025-68219",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68219"
},
{
"name": "CVE-2025-40288",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40288"
},
{
"name": "CVE-2025-40258",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40258"
},
{
"name": "CVE-2025-40281",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40281"
},
{
"name": "CVE-2025-68185",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68185"
},
{
"name": "CVE-2025-40304",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40304"
},
{
"name": "CVE-2025-40110",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40110"
},
{
"name": "CVE-2025-40268",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40268"
},
{
"name": "CVE-2026-23111",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23111"
},
{
"name": "CVE-2025-39980",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39980"
},
{
"name": "CVE-2025-40325",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40325"
},
{
"name": "CVE-2025-40009",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40009"
},
{
"name": "CVE-2025-68798",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68798"
},
{
"name": "CVE-2025-68336",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68336"
},
{
"name": "CVE-2025-40303",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40303"
},
{
"name": "CVE-2025-68810",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68810"
},
{
"name": "CVE-2025-68178",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68178"
},
{
"name": "CVE-2025-40337",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40337"
},
{
"name": "CVE-2025-40346",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40346"
},
{
"name": "CVE-2025-40036",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40036"
},
{
"name": "CVE-2026-23097",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23097"
},
{
"name": "CVE-2025-39832",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39832"
},
{
"name": "CVE-2025-40000",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40000"
},
{
"name": "CVE-2025-40262",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40262"
},
{
"name": "CVE-2025-39813",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39813"
},
{
"name": "CVE-2025-68819",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68819"
},
{
"name": "CVE-2026-23231",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23231"
},
{
"name": "CVE-2025-40261",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40261"
},
{
"name": "CVE-2025-38643",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38643"
},
{
"name": "CVE-2025-71072",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71072"
},
{
"name": "CVE-2025-40030",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40030"
},
{
"name": "CVE-2025-40244",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40244"
},
{
"name": "CVE-2025-39995",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39995"
},
{
"name": "CVE-2025-39847",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39847"
},
{
"name": "CVE-2025-39819",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39819"
},
{
"name": "CVE-2025-68732",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68732"
},
{
"name": "CVE-2025-40323",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40323"
},
{
"name": "CVE-2025-39835",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39835"
},
{
"name": "CVE-2025-68285",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68285"
},
{
"name": "CVE-2025-40096",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40096"
},
{
"name": "CVE-2026-23093",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23093"
},
{
"name": "CVE-2025-37849",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37849"
},
{
"name": "CVE-2025-39841",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39841"
},
{
"name": "CVE-2025-68371",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68371"
},
{
"name": "CVE-2025-40275",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40275"
},
{
"name": "CVE-2025-39907",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39907"
},
{
"name": "CVE-2025-68211",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68211"
},
{
"name": "CVE-2025-39829",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39829"
},
{
"name": "CVE-2025-71091",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71091"
},
{
"name": "CVE-2025-39909",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39909"
},
{
"name": "CVE-2025-68227",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68227"
},
{
"name": "CVE-2025-40339",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40339"
},
{
"name": "CVE-2025-40140",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40140"
},
{
"name": "CVE-2025-40223",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40223"
},
{
"name": "CVE-2025-40061",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40061"
},
{
"name": "CVE-2025-68263",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68263"
},
{
"name": "CVE-2025-68800",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68800"
},
{
"name": "CVE-2025-68261",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68261"
},
{
"name": "CVE-2025-68755",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68755"
},
{
"name": "CVE-2025-71149",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71149"
},
{
"name": "CVE-2025-68767",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68767"
},
{
"name": "CVE-2025-39873",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39873"
},
{
"name": "CVE-2025-40159",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40159"
},
{
"name": "CVE-2025-40319",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40319"
},
{
"name": "CVE-2025-68727",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68727"
},
{
"name": "CVE-2026-23080",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23080"
},
{
"name": "CVE-2025-39836",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39836"
},
{
"name": "CVE-2025-40051",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40051"
},
{
"name": "CVE-2025-40351",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40351"
},
{
"name": "CVE-2025-68264",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68264"
},
{
"name": "CVE-2025-40087",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40087"
},
{
"name": "CVE-2025-68764",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68764"
}
],
"initial_release_date": "2026-05-15T00:00:00",
"last_revision_date": "2026-05-15T00:00:00",
"links": [],
"reference": "CERTFR-2026-AVI-0602",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2026-05-15T00:00:00.000000"
}
],
"risks": [
{
"description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "D\u00e9ni de service"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
},
{
"description": "\u00c9l\u00e9vation de privil\u00e8ges"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans le noyau Linux d\u0027Ubuntu. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une \u00e9l\u00e9vation de privil\u00e8ges, une atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es et une atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux d\u0027Ubuntu",
"vendor_advisories": [
{
"published_at": "2026-05-07",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8261-1",
"url": "https://ubuntu.com/security/notices/USN-8261-1"
},
{
"published_at": "2026-05-11",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8266-1",
"url": "https://ubuntu.com/security/notices/USN-8266-1"
},
{
"published_at": "2026-05-11",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8180-6",
"url": "https://ubuntu.com/security/notices/USN-8180-6"
},
{
"published_at": "2026-05-11",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8254-2",
"url": "https://ubuntu.com/security/notices/USN-8254-2"
},
{
"published_at": "2026-05-11",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8265-1",
"url": "https://ubuntu.com/security/notices/USN-8265-1"
},
{
"published_at": "2026-05-07",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8260-1",
"url": "https://ubuntu.com/security/notices/USN-8260-1"
},
{
"published_at": "2026-05-07",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8258-1",
"url": "https://ubuntu.com/security/notices/USN-8258-1"
},
{
"published_at": "2026-05-11",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8267-1",
"url": "https://ubuntu.com/security/notices/USN-8267-1"
},
{
"published_at": "2026-05-11",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8200-3",
"url": "https://ubuntu.com/security/notices/USN-8200-3"
},
{
"published_at": "2026-05-11",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8255-2",
"url": "https://ubuntu.com/security/notices/USN-8255-2"
}
]
}
FKIE_CVE-2025-39968
Vulnerability from fkie_nvd - Published: 2025-10-15 08:15 - Updated: 2026-07-30 06:24| Vendor | Product | Version |
|---|
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "9176e18681cb0d34c5acc87bda224f5652af2ab8",
"status": "affected",
"version": "e284fc280473bed23f2e1ed324e102a48f7d17e1",
"versionType": "git"
},
{
"lessThan": "e490d8c5a54e0dd1ab22417d72c3a7319cf0f030",
"status": "affected",
"version": "e284fc280473bed23f2e1ed324e102a48f7d17e1",
"versionType": "git"
},
{
"lessThan": "77a35be582dff4c80442ebcdce24d45eed8a6ce4",
"status": "affected",
"version": "e284fc280473bed23f2e1ed324e102a48f7d17e1",
"versionType": "git"
},
{
"lessThan": "02aae5fcdd34c3a55a243d80a1b328a35852a35c",
"status": "affected",
"version": "e284fc280473bed23f2e1ed324e102a48f7d17e1",
"versionType": "git"
},
{
"lessThan": "edecce7abd7152b48e279b4fa0a883d1839bb577",
"status": "affected",
"version": "e284fc280473bed23f2e1ed324e102a48f7d17e1",
"versionType": "git"
},
{
"lessThan": "d33e5d6631ac4fddda235a7815babc9d3f124299",
"status": "affected",
"version": "e284fc280473bed23f2e1ed324e102a48f7d17e1",
"versionType": "git"
},
{
"lessThan": "8b13df5aa877b9e4541e301a58a84c42d84d2d9a",
"status": "affected",
"version": "e284fc280473bed23f2e1ed324e102a48f7d17e1",
"versionType": "git"
},
{
"lessThan": "cb79fa7118c150c3c76a327894bb2eb878c02619",
"status": "affected",
"version": "e284fc280473bed23f2e1ed324e102a48f7d17e1",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.17"
},
{
"lessThan": "4.17",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.300",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.245",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.194",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.155",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.109",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.50",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.16.*",
"status": "unaffected",
"version": "6.16.10",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.17",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ni40e: add max boundary check for VF filters\n\nThere is no check for max filters that VF can request. Add it."
}
],
"id": "CVE-2025-39968",
"lastModified": "2026-07-30T06:24:02.520",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.3,
"baseSeverity": "HIGH",
"confidentialityImpact": "NONE",
"integrityImpact": "LOW",
"privilegesRequired": "LOW",
"scope": "CHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:H",
"version": "3.1"
},
"exploitabilityScore": 2.0,
"impactScore": 4.7,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
}
]
},
"published": "2025-10-15T08:15:34.350",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/02aae5fcdd34c3a55a243d80a1b328a35852a35c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/77a35be582dff4c80442ebcdce24d45eed8a6ce4"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/8b13df5aa877b9e4541e301a58a84c42d84d2d9a"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/9176e18681cb0d34c5acc87bda224f5652af2ab8"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/cb79fa7118c150c3c76a327894bb2eb878c02619"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/d33e5d6631ac4fddda235a7815babc9d3f124299"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/e490d8c5a54e0dd1ab22417d72c3a7319cf0f030"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/edecce7abd7152b48e279b4fa0a883d1839bb577"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Deferred"
}
GHSA-PRJ5-RQWF-24V6
Vulnerability from github – Published: 2025-10-15 09:30 – Updated: 2026-07-30 06:32In the Linux kernel, the following vulnerability has been resolved:
i40e: add max boundary check for VF filters
There is no check for max filters that VF can request. Add it.
{
"affected": [],
"aliases": [
"CVE-2025-39968"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-15T08:15:34Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ni40e: add max boundary check for VF filters\n\nThere is no check for max filters that VF can request. Add it.",
"id": "GHSA-prj5-rqwf-24v6",
"modified": "2026-07-30T06:32:11Z",
"published": "2025-10-15T09:30:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39968"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/02aae5fcdd34c3a55a243d80a1b328a35852a35c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/77a35be582dff4c80442ebcdce24d45eed8a6ce4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8b13df5aa877b9e4541e301a58a84c42d84d2d9a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9176e18681cb0d34c5acc87bda224f5652af2ab8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cb79fa7118c150c3c76a327894bb2eb878c02619"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d33e5d6631ac4fddda235a7815babc9d3f124299"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e490d8c5a54e0dd1ab22417d72c3a7319cf0f030"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/edecce7abd7152b48e279b4fa0a883d1839bb577"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:H",
"type": "CVSS_V3"
}
]
}
MSRC_CVE-2025-39968
Vulnerability from csaf_microsoft - Published: 2025-10-02 00:00 - Updated: 2025-10-16 01:01OESA-2025-2532 (CVE-2025-21801)
Vulnerability from osv_openeuler – Published: 2025-10-24 11:09 – Updated: 2026-08-06 11:09 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
net: ravb: Fix missing rtnl lock in suspend/resume path
Fix the suspend/resume path by ensuring the rtnl lock is held where required. Calls to ravb_open, ravb_close and wol operations must be performed under the rtnl lock to prevent conflicts with ongoing ndo operations.
Without this fix, the following warning is triggered: [ 39.032969] ============================= [ 39.032983] WARNING: suspicious RCU usage [ 39.033019] ----------------------------- [ 39.033033] drivers/net/phy/phy_device.c:2004 suspicious rcu_dereference_protected() usage! ... [ 39.033597] stack backtrace: [ 39.033613] CPU: 0 UID: 0 PID: 174 Comm: python3 Not tainted 6.13.0-rc7-next-20250116-arm64-renesas-00002-g35245dfdc62c #7 [ 39.033623] Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) [ 39.033628] Call trace: [ 39.033633] show_stack+0x14/0x1c (C) [ 39.033652] dump_stack_lvl+0xb4/0xc4 [ 39.033664] dump_stack+0x14/0x1c [ 39.033671] lockdep_rcu_suspicious+0x16c/0x22c [ 39.033682] phy_detach+0x160/0x190 [ 39.033694] phy_disconnect+0x40/0x54 [ 39.033703] ravb_close+0x6c/0x1cc [ 39.033714] ravb_suspend+0x48/0x120 [ 39.033721] dpm_run_callback+0x4c/0x14c [ 39.033731] device_suspend+0x11c/0x4dc [ 39.033740] dpm_suspend+0xdc/0x214 [ 39.033748] dpm_suspend_start+0x48/0x60 [ 39.033758] suspend_devices_and_enter+0x124/0x574 [ 39.033769] pm_suspend+0x1ac/0x274 [ 39.033778] state_store+0x88/0x124 [ 39.033788] kobj_attr_store+0x14/0x24 [ 39.033798] sysfs_kf_write+0x48/0x6c [ 39.033808] kernfs_fop_write_iter+0x118/0x1a8 [ 39.033817] vfs_write+0x27c/0x378 [ 39.033825] ksys_write+0x64/0xf4 [ 39.033833] __arm64_sys_write+0x18/0x20 [ 39.033841] invoke_syscall+0x44/0x104 [ 39.033852] el0_svc_common.constprop.0+0xb4/0xd4 [ 39.033862] do_el0_svc+0x18/0x20 [ 39.033870] el0_svc+0x3c/0xf0 [ 39.033880] el0t_64_sync_handler+0xc0/0xc4 [ 39.033888] el0t_64_sync+0x154/0x158 [ 39.041274] ravb 11c30000.ethernet eth0: Link is Down(CVE-2025-21801)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btrtl: Prevent potential NULL dereference
The btrtl_initialize() function checks that rtl_load_file() either had an error or it loaded a zero length file. However, if it loaded a zero length file then the error code is not set correctly. It results in an error pointer vs NULL bug, followed by a NULL pointer dereference. This was detected by Smatch:
drivers/bluetooth/btrtl.c:592 btrtl_initialize() warn: passing zero to 'ERR_PTR'(CVE-2025-37792)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: ets: Fix double list add in class with netem as child qdisc
As described in Gerrard's report 1, there are use cases where a netem child qdisc will make the parent qdisc's enqueue callback reentrant. In the case of ets, there won't be a UAF, but the code will add the same classifier to the list twice, which will cause memory corruption.
In addition to checking for qlen being zero, this patch checks whether the class was already added to the active_list (cl_is_active) before doing the addition to cater for the reentrant case.
1 https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/(CVE-2025-37914)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: adjust subpage bit start based on sectorsize
When running machines with 64k page size and a 16k nodesize we started seeing tree log corruption in production. This turned out to be because we were not writing out dirty blocks sometimes, so this in fact affects all metadata writes.
When writing out a subpage EB we scan the subpage bitmap for a dirty range. If the range isn't dirty we do
bit_start++;
to move onto the next bit. The problem is the bitmap is based on the number of sectors that an EB has. So in this case, we have a 64k pagesize, 16k nodesize, but a 4k sectorsize. This means our bitmap is 4 bits for every node. With a 64k page size we end up with 4 nodes per page.
To make this easier this is how everything looks
[0 16k 32k 48k ] logical address [0 4 8 12 ] radix tree offset [ 64k page ] folio [ 16k eb ][ 16k eb ][ 16k eb ][ 16k eb ] extent buffers [ | | | | | | | | | | | | | | | | ] bitmap
Now we use all of our addressing based on fs_info->sectorsize_bits, so as you can see the above our 16k eb->start turns into radix entry 4.
When we find a dirty range for our eb, we correctly do bit_start += sectors_per_node, because if we start at bit 0, the next bit for the next eb is 4, to correspond to eb->start 16k.
However if our range is clean, we will do bit_start++, which will now put us offset from our radix tree entries.
In our case, assume that the first time we check the bitmap the block is not dirty, we increment bit_start so now it == 1, and then we loop around and check again. This time it is dirty, and we go to find that start using the following equation
start = folio_start + bit_start * fs_info->sectorsize;
so in the case above, eb->start 0 is now dirty, and we calculate start as
0 + 1 * fs_info->sectorsize = 4096
4096 >> 12 = 1
Now we're looking up the radix tree for 1, and we won't find an eb. What's worse is now we're using bit_start == 1, so we do bit_start += sectors_per_node, which is now 5. If that eb is dirty we will run into the same thing, we will look at an offset that is not populated in the radix tree, and now we're skipping the writeout of dirty extent buffers.
The best fix for this is to not use sectorsize_bits to address nodes, but that's a larger change. Since this is a fs corruption problem fix it simply by always using sectors_per_node to increment the start bit.(CVE-2025-37931)
In the Linux kernel, the following vulnerability has been resolved:
bus: fsl-mc: fix double-free on mc_dev
The blamed commit tried to simplify how the deallocations are done but, in the process, introduced a double-free on the mc_dev variable.
In case the MC device is a DPRC, a new mc_bus is allocated and the mc_dev variable is just a reference to one of its fields. In this circumstance, on the error path only the mc_bus should be freed.
This commit introduces back the following checkpatch warning which is a false-positive.
WARNING: kfree(NULL) is safe and this check is probably not required + if (mc_bus) + kfree(mc_bus);(CVE-2025-38313)
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to bail out in get_new_segment()
------------[ cut here ]------------ WARNING: CPU: 3 PID: 579 at fs/f2fs/segment.c:2832 new_curseg+0x5e8/0x6dc pc : new_curseg+0x5e8/0x6dc Call trace: new_curseg+0x5e8/0x6dc f2fs_allocate_data_block+0xa54/0xe28 do_write_page+0x6c/0x194 f2fs_do_write_node_page+0x38/0x78 __write_node_page+0x248/0x6d4 f2fs_sync_node_pages+0x524/0x72c f2fs_write_checkpoint+0x4bc/0x9b0 __checkpoint_and_complete_reqs+0x80/0x244 issue_checkpoint_thread+0x8c/0xec kthread+0x114/0x1bc ret_from_fork+0x10/0x20
get_new_segment() detects inconsistent status in between free_segmap and free_secmap, let's record such error into super block, and bail out get_new_segment() instead of continue using the segment.(CVE-2025-38333)
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: fix GCC_GCC_PCIE_HOT_RST definition for WCN7850
GCC_GCC_PCIE_HOT_RST is wrongly defined for WCN7850, causing kernel crash on some specific platforms.
Since this register is divergent for WCN7850 and QCN9274, move it to register table to allow different definitions. Then correct the register address for WCN7850 to fix this issue.
Note IPQ5332 is not affected as it is not PCIe based device.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3(CVE-2025-38414)
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: cancle set bad inode after removing name fails
The reproducer uses a file0 on a ntfs3 file system with a corrupted i_link. When renaming, the file0's inode is marked as a bad inode because the file name cannot be deleted.
The underlying bug is that make_bad_inode() is called on a live inode. In some cases it's "icache lookup finds a normal inode, d_splice_alias() is called to attach it to dentry, while another thread decides to call make_bad_inode() on it - that would evict it from icache, but we'd already found it there earlier". In some it's outright "we have an inode attached to dentry - that's how we got it in the first place; let's call make_bad_inode() on it just for shits and giggles".(CVE-2025-38615)
In the Linux kernel, the following vulnerability has been resolved:
scsi: libiscsi: Initialize iscsi_conn->dd_data only if memory is allocated
In case of an ib_fast_reg_mr allocation failure during iSER setup, the machine hits a panic because iscsi_conn->dd_data is initialized unconditionally, even when no memory is allocated (dd_size == 0). This leads invalid pointer dereference during connection teardown.
Fix by setting iscsi_conn->dd_data only if memory is actually allocated.
Panic trace:
iser: iser_create_fastreg_desc: Failed to allocate ib_fast_reg_mr err=-12 iser: iser_alloc_rx_descriptors: failed allocating rx descriptors / data buffers BUG: unable to handle page fault for address: fffffffffffffff8 RIP: 0010:swake_up_locked.part.5+0xa/0x40 Call Trace: complete+0x31/0x40 iscsi_iser_conn_stop+0x88/0xb0 [ib_iser] iscsi_stop_conn+0x66/0xc0 [scsi_transport_iscsi] iscsi_if_stop_conn+0x14a/0x150 [scsi_transport_iscsi] iscsi_if_rx+0x1135/0x1834 [scsi_transport_iscsi] ? netlink_lookup+0x12f/0x1b0 ? netlink_deliver_tap+0x2c/0x200 netlink_unicast+0x1ab/0x280 netlink_sendmsg+0x257/0x4f0 ? _copy_from_user+0x29/0x60 sock_sendmsg+0x5f/0x70(CVE-2025-38700)
In the Linux kernel, the following vulnerability has been resolved:
ext4: do not BUG when INLINE_DATA_FL lacks system.data xattr
A syzbot fuzzed image triggered a BUG_ON in ext4_update_inline_data() when an inode had the INLINE_DATA_FL flag set but was missing the system.data extended attribute.
Since this can happen due to a maiciouly fuzzed file system, we shouldn't BUG, but rather, report it as a corrupted file system.
Add similar replacements of BUG_ON with EXT4_ERROR_INODE() ii ext4_create_inline_data() and ext4_inline_data_truncate().(CVE-2025-38701)
In the Linux kernel, the following vulnerability has been resolved:
loop: Avoid updating block size under exclusive owner
Syzbot came up with a reproducer where a loop device block size is changed underneath a mounted filesystem. This causes a mismatch between the block device block size and the block size stored in the superblock causing confusion in various places such as fs/buffer.c. The particular issue triggered by syzbot was a warning in __getblk_slow() due to requested buffer size not matching block device block size.
Fix the problem by getting exclusive hold of the loop device to change its block size. This fails if somebody (such as filesystem) has already an exclusive ownership of the block device and thus prevents modifying the loop device under some exclusive owner which doesn't expect it.(CVE-2025-38709)
In the Linux kernel, the following vulnerability has been resolved:
fs/buffer: fix use-after-free when call bh_read() helper
There's issue as follows: BUG: KASAN: stack-out-of-bounds in end_buffer_read_sync+0xe3/0x110 Read of size 8 at addr ffffc9000168f7f8 by task swapper/3/0 CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.16.0-862.14.0.6.x86_64 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <IRQ> dump_stack_lvl+0x55/0x70 print_address_description.constprop.0+0x2c/0x390 print_report+0xb4/0x270 kasan_report+0xb8/0xf0 end_buffer_read_sync+0xe3/0x110 end_bio_bh_io_sync+0x56/0x80 blk_update_request+0x30a/0x720 scsi_end_request+0x51/0x2b0 scsi_io_completion+0xe3/0x480 ? scsi_device_unbusy+0x11e/0x160 blk_complete_reqs+0x7b/0x90 handle_softirqs+0xef/0x370 irq_exit_rcu+0xa5/0xd0 sysvec_apic_timer_interrupt+0x6e/0x90 </IRQ>
Above issue happens when do ntfs3 filesystem mount, issue may happens as follows: mount IRQ ntfs_fill_super read_cache_page do_read_cache_folio filemap_read_folio mpage_read_folio do_mpage_readpage ntfs_get_block_vbo bh_read submit_bh wait_on_buffer(bh); blk_complete_reqs scsi_io_completion scsi_end_request blk_update_request end_bio_bh_io_sync end_buffer_read_sync __end_buffer_read_notouch unlock_buffer
wait_on_buffer(bh);--> return will return to caller
put_bh
--> trigger stack-out-of-bounds
In the mpage_read_folio() function, the stack variable 'map_bh' is passed to ntfs_get_block_vbo(). Once unlock_buffer() unlocks and wait_on_buffer() returns to continue processing, the stack variable is likely to be reclaimed. Consequently, during the end_buffer_read_sync() process, calling put_bh() may result in stack overrun.
If the bh is not allocated on the stack, it belongs to a folio. Freeing a buffer head which belongs to a folio is done by drop_buffers() which will fail to free buffers which are still locked. So it is safe to call put_bh() before __end_buffer_read_notouch().(CVE-2025-39691)
In the Linux kernel, the following vulnerability has been resolved:
soc: qcom: mdt_loader: Ensure we don't read past the ELF header
When the MDT loader is used in remoteproc, the ELF header is sanitized beforehand, but that's not necessary the case for other clients.
Validate the size of the firmware buffer to ensure that we don't read past the end as we iterate over the header. e_phentsize and e_shentsize are validated as well, to ensure that the assumptions about step size in the traversal are valid.(CVE-2025-39787)
In the Linux kernel, the following vulnerability has been resolved:
block: avoid possible overflow for chunk_sectors check in blk_stack_limits()
In blk_stack_limits(), we check that the t->chunk_sectors value is a multiple of the t->physical_block_size value.
However, by finding the chunk_sectors value in bytes, we may overflow the unsigned int which holds chunk_sectors, so change the check to be based on sectors.(CVE-2025-39795)
In the Linux kernel, the following vulnerability has been resolved:
pcmcia: Add error handling for add_interval() in do_validate_mem()
In the do_validate_mem(), the call to add_interval() does not handle errors. If kmalloc() fails in add_interval(), it could result in a null pointer being inserted into the linked list, leading to illegal memory access when sub_interval() is called next.
This patch adds an error handling for the add_interval(). If add_interval() returns an error, the function will return early with the error code.(CVE-2025-39920)
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: qcom: bam_dma: Fix DT error handling for num-channels/ees
When we don't have a clock specified in the device tree, we have no way to ensure the BAM is on. This is often the case for remotely-controlled or remotely-powered BAM instances. In this case, we need to read num-channels from the DT to have all the necessary information to complete probing.
However, at the moment invalid device trees without clock and without num-channels still continue probing, because the error handling is missing return statements. The driver will then later try to read the number of channels from the registers. This is unsafe, because it relies on boot firmware and lucky timing to succeed. Unfortunately, the lack of proper error handling here has been abused for several Qualcomm SoCs upstream, causing early boot crashes in several situations [1, 2].
Avoid these early crashes by erroring out when any of the required DT properties are missing. Note that this will break some of the existing DTs upstream (mainly BAM instances related to the crypto engine). However, clearly these DTs have never been tested properly, since the error in the kernel log was just ignored. It's safer to disable the crypto engine for these broken DTBs.
In the Linux kernel i40e driver, there is a security vulnerability: the driver lacks boundary checks for the maximum number of virtual function (VF) filters. An attacker could potentially exploit this vulnerability to request filter counts beyond the boundaries, leading to potential security issues.(CVE-2025-39968)
In the Linux kernel, the following vulnerability has been resolved: i40e: fix idx validation in config queues msg. Ensure idx is within range of active/initialized TCs when iterating over vf->ch[idx] in i40e_vc_config_queues_msg().(CVE-2025-39971)
In the Linux kernel, the following vulnerability has been resolved:
x86/mce: use is_copy_from_user() to determine copy-from-user context
Patch series "mm/hwpoison: Fix regressions in memory failure handling", v4.
1. What am I trying to do:
This patchset resolves two critical regressions related to memory failure handling that have appeared in the upstream kernel since version 5.17, as compared to 5.10 LTS.
- copyin case: poison found in user page while kernel copying from user space
- instr case: poison found while instruction fetching in user space
2. What is the expected outcome and why
- For copyin case:
Kernel can recover from poison found where kernel is doing get_user() or copy_from_user() if those places get an error return and the kernel return -EFAULT to the process instead of crashing. More specifily, MCE handler checks the fixup handler type to decide whether an in kernel #MC can be recovered. When EX_TYPE_UACCESS is found, the PC jumps to recovery code specified in _ASM_EXTABLE_FAULT() and return a -EFAULT to user space.
- For instr case:
If a poison found while instruction fetching in user space, full recovery is possible. User process takes #PF, Linux allocates a new page and fills by reading from storage.
3. What actually happens and why
- For copyin case: kernel panic since v5.17
Commit 4c132d1d844a ("x86/futex: Remove .fixup usage") introduced a new extable fixup type, EX_TYPE_EFAULT_REG, and later patches updated the extable fixup type for copy-from-user operations, changing it from EX_TYPE_UACCESS to EX_TYPE_EFAULT_REG. It breaks previous EX_TYPE_UACCESS handling when posion found in get_user() or copy_from_user().
- For instr case: user process is killed by a SIGBUS signal due to #CMCI and #MCE race
When an uncorrected memory error is consumed there is a race between the CMCI from the memory controller reporting an uncorrected error with a UCNA signature, and the core reporting and SRAR signature machine check when the data is about to be consumed.
Background: why UNcorrected errors tied to CMCI in Intel platform 1
Prior to Icelake memory controllers reported patrol scrub events that detected a previously unseen uncorrected error in memory by signaling a broadcast machine check with an SRAO (Software Recoverable Action Optional) signature in the machine check bank. This was overkill because it's not an urgent problem that no core is on the verge of consuming that bad data. It's also found that multi SRAO UCE may cause nested MCE interrupts and finally become an IERR.
Hence, Intel downgrades the machine check bank signature of patrol scrub from SRAO to UCNA (Uncorrected, No Action required), and signal changed to
CMCI. Just to add to the confusion, Linux does take an action (in
uc_decode_notifier()) to try to offline the page despite the UCNA signature name.
Background: why #CMCI and #MCE race when poison is consuming in
Intel platform [1]
Having decided that CMCI/UCNA is the best action for patrol scrub errors, the memory controller uses it for reads too. But the memory controller is executing asynchronously from the core, and can't tell the difference between a "real" read and a speculative read. So it will do CMCI/UCNA if an error is found in any read.
Thus:
1) Core is clever and thinks address A is needed soon, issues a speculative read.
2) Core finds it is going to use address A soon after sending the read request
3) The CMCI from the memory controller is in a race with MCE from the core that will soon try to retire the load from address A.
Quite often (because speculation has got better) the CMCI from the memory controller is delivered before the core is committed to the instruction reading address A, so the interrupt is taken, and Linux offlines the page (marking it as poison).
Why user process is killed for instr case
Commit 046545a661af ("mm/hwpoison: fix error page recovered but reported "not ---truncated---(CVE-2025-39989)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-113.0.0.119.oe2403sp2.aarch64.rpm",
"bpftool-debuginfo-6.6.0-113.0.0.119.oe2403sp2.aarch64.rpm",
"kernel-6.6.0-113.0.0.119.oe2403sp2.aarch64.rpm",
"kernel-debuginfo-6.6.0-113.0.0.119.oe2403sp2.aarch64.rpm",
"kernel-debugsource-6.6.0-113.0.0.119.oe2403sp2.aarch64.rpm",
"kernel-devel-6.6.0-113.0.0.119.oe2403sp2.aarch64.rpm",
"kernel-extra-modules-6.6.0-113.0.0.119.oe2403sp2.aarch64.rpm",
"kernel-headers-6.6.0-113.0.0.119.oe2403sp2.aarch64.rpm",
"kernel-source-6.6.0-113.0.0.119.oe2403sp2.aarch64.rpm",
"kernel-tools-6.6.0-113.0.0.119.oe2403sp2.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-113.0.0.119.oe2403sp2.aarch64.rpm",
"kernel-tools-devel-6.6.0-113.0.0.119.oe2403sp2.aarch64.rpm",
"perf-6.6.0-113.0.0.119.oe2403sp2.aarch64.rpm",
"perf-debuginfo-6.6.0-113.0.0.119.oe2403sp2.aarch64.rpm",
"python3-perf-6.6.0-113.0.0.119.oe2403sp2.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-113.0.0.119.oe2403sp2.aarch64.rpm"
],
"src": [
"kernel-6.6.0-113.0.0.119.oe2403sp2.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-113.0.0.119.oe2403sp2.x86_64.rpm",
"bpftool-debuginfo-6.6.0-113.0.0.119.oe2403sp2.x86_64.rpm",
"kernel-6.6.0-113.0.0.119.oe2403sp2.x86_64.rpm",
"kernel-debuginfo-6.6.0-113.0.0.119.oe2403sp2.x86_64.rpm",
"kernel-debugsource-6.6.0-113.0.0.119.oe2403sp2.x86_64.rpm",
"kernel-devel-6.6.0-113.0.0.119.oe2403sp2.x86_64.rpm",
"kernel-extra-modules-6.6.0-113.0.0.119.oe2403sp2.x86_64.rpm",
"kernel-headers-6.6.0-113.0.0.119.oe2403sp2.x86_64.rpm",
"kernel-source-6.6.0-113.0.0.119.oe2403sp2.x86_64.rpm",
"kernel-tools-6.6.0-113.0.0.119.oe2403sp2.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-113.0.0.119.oe2403sp2.x86_64.rpm",
"kernel-tools-devel-6.6.0-113.0.0.119.oe2403sp2.x86_64.rpm",
"perf-6.6.0-113.0.0.119.oe2403sp2.x86_64.rpm",
"perf-debuginfo-6.6.0-113.0.0.119.oe2403sp2.x86_64.rpm",
"python3-perf-6.6.0-113.0.0.119.oe2403sp2.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-113.0.0.119.oe2403sp2.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS-SP2",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-113.0.0.119.oe2403sp2"
}
],
"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: 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\nBluetooth: btrtl: Prevent potential NULL dereference\n\nThe btrtl_initialize() function checks that rtl_load_file() either\nhad an error or it loaded a zero length file. However, if it loaded\na zero length file then the error code is not set correctly. It\nresults in an error pointer vs NULL bug, followed by a NULL pointer\ndereference. This was detected by Smatch:\n\ndrivers/bluetooth/btrtl.c:592 btrtl_initialize() warn: passing zero to \u0026apos;ERR_PTR\u0026apos;(CVE-2025-37792)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: ets: Fix double list add in class with netem as child qdisc\n\nAs described in Gerrard\u0026apos;s report [1], there are use cases where a netem\nchild qdisc will make the parent qdisc\u0026apos;s enqueue callback reentrant.\nIn the case of ets, there won\u0026apos;t be a UAF, but the code will add the same\nclassifier to the list twice, which will cause memory corruption.\n\nIn addition to checking for qlen being zero, this patch checks whether\nthe class was already added to the active_list (cl_is_active) before\ndoing the addition to cater for the reentrant case.\n\n[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/(CVE-2025-37914)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: adjust subpage bit start based on sectorsize\n\nWhen running machines with 64k page size and a 16k nodesize we started\nseeing tree log corruption in production. This turned out to be because\nwe were not writing out dirty blocks sometimes, so this in fact affects\nall metadata writes.\n\nWhen writing out a subpage EB we scan the subpage bitmap for a dirty\nrange. If the range isn\u0026apos;t dirty we do\n\n\tbit_start++;\n\nto move onto the next bit. The problem is the bitmap is based on the\nnumber of sectors that an EB has. So in this case, we have a 64k\npagesize, 16k nodesize, but a 4k sectorsize. This means our bitmap is 4\nbits for every node. With a 64k page size we end up with 4 nodes per\npage.\n\nTo make this easier this is how everything looks\n\n[0 16k 32k 48k ] logical address\n[0 4 8 12 ] radix tree offset\n[ 64k page ] folio\n[ 16k eb ][ 16k eb ][ 16k eb ][ 16k eb ] extent buffers\n[ | | | | | | | | | | | | | | | | ] bitmap\n\nNow we use all of our addressing based on fs_info-\u0026gt;sectorsize_bits, so\nas you can see the above our 16k eb-\u0026gt;start turns into radix entry 4.\n\nWhen we find a dirty range for our eb, we correctly do bit_start +=\nsectors_per_node, because if we start at bit 0, the next bit for the\nnext eb is 4, to correspond to eb-\u0026gt;start 16k.\n\nHowever if our range is clean, we will do bit_start++, which will now\nput us offset from our radix tree entries.\n\nIn our case, assume that the first time we check the bitmap the block is\nnot dirty, we increment bit_start so now it == 1, and then we loop\naround and check again. This time it is dirty, and we go to find that\nstart using the following equation\n\n\tstart = folio_start + bit_start * fs_info-\u0026gt;sectorsize;\n\nso in the case above, eb-\u0026gt;start 0 is now dirty, and we calculate start\nas\n\n\t0 + 1 * fs_info-\u0026gt;sectorsize = 4096\n\t4096 \u0026gt;\u0026gt; 12 = 1\n\nNow we\u0026apos;re looking up the radix tree for 1, and we won\u0026apos;t find an eb.\nWhat\u0026apos;s worse is now we\u0026apos;re using bit_start == 1, so we do bit_start +=\nsectors_per_node, which is now 5. If that eb is dirty we will run into\nthe same thing, we will look at an offset that is not populated in the\nradix tree, and now we\u0026apos;re skipping the writeout of dirty extent buffers.\n\nThe best fix for this is to not use sectorsize_bits to address nodes,\nbut that\u0026apos;s a larger change. Since this is a fs corruption problem fix\nit simply by always using sectors_per_node to increment the start bit.(CVE-2025-37931)\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\nf2fs: fix to bail out in get_new_segment()\n\n------------[ cut here ]------------\nWARNING: CPU: 3 PID: 579 at fs/f2fs/segment.c:2832 new_curseg+0x5e8/0x6dc\npc : new_curseg+0x5e8/0x6dc\nCall trace:\n new_curseg+0x5e8/0x6dc\n f2fs_allocate_data_block+0xa54/0xe28\n do_write_page+0x6c/0x194\n f2fs_do_write_node_page+0x38/0x78\n __write_node_page+0x248/0x6d4\n f2fs_sync_node_pages+0x524/0x72c\n f2fs_write_checkpoint+0x4bc/0x9b0\n __checkpoint_and_complete_reqs+0x80/0x244\n issue_checkpoint_thread+0x8c/0xec\n kthread+0x114/0x1bc\n ret_from_fork+0x10/0x20\n\nget_new_segment() detects inconsistent status in between free_segmap\nand free_secmap, let\u0026apos;s record such error into super block, and bail\nout get_new_segment() instead of continue using the segment.(CVE-2025-38333)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath12k: fix GCC_GCC_PCIE_HOT_RST definition for WCN7850\n\nGCC_GCC_PCIE_HOT_RST is wrongly defined for WCN7850, causing kernel crash\non some specific platforms.\n\nSince this register is divergent for WCN7850 and QCN9274, move it to\nregister table to allow different definitions. Then correct the register\naddress for WCN7850 to fix this issue.\n\nNote IPQ5332 is not affected as it is not PCIe based device.\n\nTested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3(CVE-2025-38414)\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\nscsi: libiscsi: Initialize iscsi_conn-\u0026gt;dd_data only if memory is allocated\n\nIn case of an ib_fast_reg_mr allocation failure during iSER setup, the\nmachine hits a panic because iscsi_conn-\u0026gt;dd_data is initialized\nunconditionally, even when no memory is allocated (dd_size == 0). This\nleads invalid pointer dereference during connection teardown.\n\nFix by setting iscsi_conn-\u0026gt;dd_data only if memory is actually allocated.\n\nPanic trace:\n------------\n iser: iser_create_fastreg_desc: Failed to allocate ib_fast_reg_mr err=-12\n iser: iser_alloc_rx_descriptors: failed allocating rx descriptors / data buffers\n BUG: unable to handle page fault for address: fffffffffffffff8\n RIP: 0010:swake_up_locked.part.5+0xa/0x40\n Call Trace:\n complete+0x31/0x40\n iscsi_iser_conn_stop+0x88/0xb0 [ib_iser]\n iscsi_stop_conn+0x66/0xc0 [scsi_transport_iscsi]\n iscsi_if_stop_conn+0x14a/0x150 [scsi_transport_iscsi]\n iscsi_if_rx+0x1135/0x1834 [scsi_transport_iscsi]\n ? netlink_lookup+0x12f/0x1b0\n ? netlink_deliver_tap+0x2c/0x200\n netlink_unicast+0x1ab/0x280\n netlink_sendmsg+0x257/0x4f0\n ? _copy_from_user+0x29/0x60\n sock_sendmsg+0x5f/0x70(CVE-2025-38700)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: do not BUG when INLINE_DATA_FL lacks system.data xattr\n\nA syzbot fuzzed image triggered a BUG_ON in ext4_update_inline_data()\nwhen an inode had the INLINE_DATA_FL flag set but was missing the\nsystem.data extended attribute.\n\nSince this can happen due to a maiciouly fuzzed file system, we\nshouldn\u0026apos;t BUG, but rather, report it as a corrupted file system.\n\nAdd similar replacements of BUG_ON with EXT4_ERROR_INODE() ii\next4_create_inline_data() and ext4_inline_data_truncate().(CVE-2025-38701)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nloop: Avoid updating block size under exclusive owner\n\nSyzbot came up with a reproducer where a loop device block size is\nchanged underneath a mounted filesystem. This causes a mismatch between\nthe block device block size and the block size stored in the superblock\ncausing confusion in various places such as fs/buffer.c. The particular\nissue triggered by syzbot was a warning in __getblk_slow() due to\nrequested buffer size not matching block device block size.\n\nFix the problem by getting exclusive hold of the loop device to change\nits block size. This fails if somebody (such as filesystem) has already\nan exclusive ownership of the block device and thus prevents modifying\nthe loop device under some exclusive owner which doesn\u0026apos;t expect it.(CVE-2025-38709)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/buffer: fix use-after-free when call bh_read() helper\n\nThere\u0026apos;s issue as follows:\nBUG: KASAN: stack-out-of-bounds in end_buffer_read_sync+0xe3/0x110\nRead of size 8 at addr ffffc9000168f7f8 by task swapper/3/0\nCPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.16.0-862.14.0.6.x86_64\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996)\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n dump_stack_lvl+0x55/0x70\n print_address_description.constprop.0+0x2c/0x390\n print_report+0xb4/0x270\n kasan_report+0xb8/0xf0\n end_buffer_read_sync+0xe3/0x110\n end_bio_bh_io_sync+0x56/0x80\n blk_update_request+0x30a/0x720\n scsi_end_request+0x51/0x2b0\n scsi_io_completion+0xe3/0x480\n ? scsi_device_unbusy+0x11e/0x160\n blk_complete_reqs+0x7b/0x90\n handle_softirqs+0xef/0x370\n irq_exit_rcu+0xa5/0xd0\n sysvec_apic_timer_interrupt+0x6e/0x90\n \u0026lt;/IRQ\u0026gt;\n\n Above issue happens when do ntfs3 filesystem mount, issue may happens\n as follows:\n mount IRQ\nntfs_fill_super\n read_cache_page\n do_read_cache_folio\n filemap_read_folio\n mpage_read_folio\n\t do_mpage_readpage\n\t ntfs_get_block_vbo\n\t bh_read\n\t submit_bh\n\t wait_on_buffer(bh);\n\t blk_complete_reqs\n\t\t\t\t scsi_io_completion\n\t\t\t\t scsi_end_request\n\t\t\t\t blk_update_request\n\t\t\t\t end_bio_bh_io_sync\n\t\t\t\t\t end_buffer_read_sync\n\t\t\t\t\t __end_buffer_read_notouch\n\t\t\t\t\t unlock_buffer\n\n wait_on_buffer(bh);--\u0026gt; return will return to caller\n\n\t\t\t\t\t put_bh\n\t\t\t\t\t --\u0026gt; trigger stack-out-of-bounds\nIn the mpage_read_folio() function, the stack variable \u0026apos;map_bh\u0026apos; is\npassed to ntfs_get_block_vbo(). Once unlock_buffer() unlocks and\nwait_on_buffer() returns to continue processing, the stack variable\nis likely to be reclaimed. Consequently, during the end_buffer_read_sync()\nprocess, calling put_bh() may result in stack overrun.\n\nIf the bh is not allocated on the stack, it belongs to a folio. Freeing\na buffer head which belongs to a folio is done by drop_buffers() which\nwill fail to free buffers which are still locked. So it is safe to call\nput_bh() before __end_buffer_read_notouch().(CVE-2025-39691)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsoc: qcom: mdt_loader: Ensure we don\u0026apos;t read past the ELF header\n\nWhen the MDT loader is used in remoteproc, the ELF header is sanitized\nbeforehand, but that\u0026apos;s not necessary the case for other clients.\n\nValidate the size of the firmware buffer to ensure that we don\u0026apos;t read\npast the end as we iterate over the header. e_phentsize and e_shentsize\nare validated as well, to ensure that the assumptions about step size in\nthe traversal are valid.(CVE-2025-39787)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblock: avoid possible overflow for chunk_sectors check in blk_stack_limits()\n\nIn blk_stack_limits(), we check that the t-\u0026gt;chunk_sectors value is a\nmultiple of the t-\u0026gt;physical_block_size value.\n\nHowever, by finding the chunk_sectors value in bytes, we may overflow\nthe unsigned int which holds chunk_sectors, so change the check to be\nbased on sectors.(CVE-2025-39795)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npcmcia: Add error handling for add_interval() in do_validate_mem()\n\nIn the do_validate_mem(), the call to add_interval() does not\nhandle errors. If kmalloc() fails in add_interval(), it could\nresult in a null pointer being inserted into the linked list,\nleading to illegal memory access when sub_interval() is called\nnext.\n\nThis patch adds an error handling for the add_interval(). If\nadd_interval() returns an error, the function will return early\nwith the error code.(CVE-2025-39920)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: qcom: bam_dma: Fix DT error handling for num-channels/ees\n\nWhen we don\u0026apos;t have a clock specified in the device tree, we have no way to\nensure the BAM is on. This is often the case for remotely-controlled or\nremotely-powered BAM instances. In this case, we need to read num-channels\nfrom the DT to have all the necessary information to complete probing.\n\nHowever, at the moment invalid device trees without clock and without\nnum-channels still continue probing, because the error handling is missing\nreturn statements. The driver will then later try to read the number of\nchannels from the registers. This is unsafe, because it relies on boot\nfirmware and lucky timing to succeed. Unfortunately, the lack of proper\nerror handling here has been abused for several Qualcomm SoCs upstream,\ncausing early boot crashes in several situations [1, 2].\n\nAvoid these early crashes by erroring out when any of the required DT\nproperties are missing. Note that this will break some of the existing DTs\nupstream (mainly BAM instances related to the crypto engine). However,\nclearly these DTs have never been tested properly, since the error in the\nkernel log was just ignored. It\u0026apos;s safer to disable the crypto engine for\nthese broken DTBs.\n\n[1]: https://lore.kernel.org/r/(CVE-2025-39923)\n\nIn the Linux kernel i40e driver, there is a security vulnerability: the driver lacks boundary checks for the maximum number of virtual function (VF) filters. An attacker could potentially exploit this vulnerability to request filter counts beyond the boundaries, leading to potential security issues.(CVE-2025-39968)\n\nIn the Linux kernel, the following vulnerability has been resolved: i40e: fix idx validation in config queues msg. Ensure idx is within range of active/initialized TCs when iterating over vf-\u0026gt;ch[idx] in i40e_vc_config_queues_msg().(CVE-2025-39971)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/mce: use is_copy_from_user() to determine copy-from-user context\n\nPatch series \u0026quot;mm/hwpoison: Fix regressions in memory failure handling\u0026quot;,\nv4.\n\n## 1. What am I trying to do:\n\nThis patchset resolves two critical regressions related to memory failure\nhandling that have appeared in the upstream kernel since version 5.17, as\ncompared to 5.10 LTS.\n\n - copyin case: poison found in user page while kernel copying from user space\n - instr case: poison found while instruction fetching in user space\n\n## 2. What is the expected outcome and why\n\n- For copyin case:\n\nKernel can recover from poison found where kernel is doing get_user() or\ncopy_from_user() if those places get an error return and the kernel return\n-EFAULT to the process instead of crashing. More specifily, MCE handler\nchecks the fixup handler type to decide whether an in kernel #MC can be\nrecovered. When EX_TYPE_UACCESS is found, the PC jumps to recovery code\nspecified in _ASM_EXTABLE_FAULT() and return a -EFAULT to user space.\n\n- For instr case:\n\nIf a poison found while instruction fetching in user space, full recovery\nis possible. User process takes #PF, Linux allocates a new page and fills\nby reading from storage.\n\n\n## 3. What actually happens and why\n\n- For copyin case: kernel panic since v5.17\n\nCommit 4c132d1d844a (\u0026quot;x86/futex: Remove .fixup usage\u0026quot;) introduced a new\nextable fixup type, EX_TYPE_EFAULT_REG, and later patches updated the\nextable fixup type for copy-from-user operations, changing it from\nEX_TYPE_UACCESS to EX_TYPE_EFAULT_REG. It breaks previous EX_TYPE_UACCESS\nhandling when posion found in get_user() or copy_from_user().\n\n- For instr case: user process is killed by a SIGBUS signal due to #CMCI\n and #MCE race\n\nWhen an uncorrected memory error is consumed there is a race between the\nCMCI from the memory controller reporting an uncorrected error with a UCNA\nsignature, and the core reporting and SRAR signature machine check when\nthe data is about to be consumed.\n\n### Background: why *UN*corrected errors tied to *C*MCI in Intel platform [1]\n\nPrior to Icelake memory controllers reported patrol scrub events that\ndetected a previously unseen uncorrected error in memory by signaling a\nbroadcast machine check with an SRAO (Software Recoverable Action\nOptional) signature in the machine check bank. This was overkill because\nit\u0026apos;s not an urgent problem that no core is on the verge of consuming that\nbad data. It\u0026apos;s also found that multi SRAO UCE may cause nested MCE\ninterrupts and finally become an IERR.\n\nHence, Intel downgrades the machine check bank signature of patrol scrub\nfrom SRAO to UCNA (Uncorrected, No Action required), and signal changed to\n#CMCI. Just to add to the confusion, Linux does take an action (in\nuc_decode_notifier()) to try to offline the page despite the UC*NA*\nsignature name.\n\n### Background: why #CMCI and #MCE race when poison is consuming in\n Intel platform [1]\n\nHaving decided that CMCI/UCNA is the best action for patrol scrub errors,\nthe memory controller uses it for reads too. But the memory controller is\nexecuting asynchronously from the core, and can\u0026apos;t tell the difference\nbetween a \u0026quot;real\u0026quot; read and a speculative read. So it will do CMCI/UCNA if\nan error is found in any read.\n\nThus:\n\n1) Core is clever and thinks address A is needed soon, issues a\n speculative read.\n\n2) Core finds it is going to use address A soon after sending the read\n request\n\n3) The CMCI from the memory controller is in a race with MCE from the\n core that will soon try to retire the load from address A.\n\nQuite often (because speculation has got better) the CMCI from the memory\ncontroller is delivered before the core is committed to the instruction\nreading address A, so the interrupt is taken, and Linux offlines the page\n(marking it as poison).\n\n\n## Why user process is killed for instr case\n\nCommit 046545a661af (\u0026quot;mm/hwpoison: fix error page recovered but reported\n\u0026quot;not\n---truncated---(CVE-2025-39989)",
"id": "OESA-2025-2532",
"modified": "2026-08-06T11:09:37Z",
"published": "2025-10-24T11:09:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2532"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21801"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37792"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37914"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37931"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38313"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38333"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38414"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38615"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38700"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38701"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38709"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39691"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39787"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39795"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39920"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39923"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39968"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39971"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39989"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2025-21801",
"CVE-2025-37792",
"CVE-2025-37914",
"CVE-2025-37931",
"CVE-2025-38313",
"CVE-2025-38333",
"CVE-2025-38414",
"CVE-2025-38615",
"CVE-2025-38700",
"CVE-2025-38701",
"CVE-2025-38709",
"CVE-2025-39691",
"CVE-2025-39787",
"CVE-2025-39795",
"CVE-2025-39920",
"CVE-2025-39923",
"CVE-2025-39968",
"CVE-2025-39971",
"CVE-2025-39989"
]
}
OESA-2025-2536 (CVE-2025-21801)
Vulnerability from osv_openeuler – Published: 2025-10-24 11:09 – Updated: 2026-08-06 11:09 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
net: ravb: Fix missing rtnl lock in suspend/resume path
Fix the suspend/resume path by ensuring the rtnl lock is held where required. Calls to ravb_open, ravb_close and wol operations must be performed under the rtnl lock to prevent conflicts with ongoing ndo operations.
Without this fix, the following warning is triggered: [ 39.032969] ============================= [ 39.032983] WARNING: suspicious RCU usage [ 39.033019] ----------------------------- [ 39.033033] drivers/net/phy/phy_device.c:2004 suspicious rcu_dereference_protected() usage! ... [ 39.033597] stack backtrace: [ 39.033613] CPU: 0 UID: 0 PID: 174 Comm: python3 Not tainted 6.13.0-rc7-next-20250116-arm64-renesas-00002-g35245dfdc62c #7 [ 39.033623] Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) [ 39.033628] Call trace: [ 39.033633] show_stack+0x14/0x1c (C) [ 39.033652] dump_stack_lvl+0xb4/0xc4 [ 39.033664] dump_stack+0x14/0x1c [ 39.033671] lockdep_rcu_suspicious+0x16c/0x22c [ 39.033682] phy_detach+0x160/0x190 [ 39.033694] phy_disconnect+0x40/0x54 [ 39.033703] ravb_close+0x6c/0x1cc [ 39.033714] ravb_suspend+0x48/0x120 [ 39.033721] dpm_run_callback+0x4c/0x14c [ 39.033731] device_suspend+0x11c/0x4dc [ 39.033740] dpm_suspend+0xdc/0x214 [ 39.033748] dpm_suspend_start+0x48/0x60 [ 39.033758] suspend_devices_and_enter+0x124/0x574 [ 39.033769] pm_suspend+0x1ac/0x274 [ 39.033778] state_store+0x88/0x124 [ 39.033788] kobj_attr_store+0x14/0x24 [ 39.033798] sysfs_kf_write+0x48/0x6c [ 39.033808] kernfs_fop_write_iter+0x118/0x1a8 [ 39.033817] vfs_write+0x27c/0x378 [ 39.033825] ksys_write+0x64/0xf4 [ 39.033833] __arm64_sys_write+0x18/0x20 [ 39.033841] invoke_syscall+0x44/0x104 [ 39.033852] el0_svc_common.constprop.0+0xb4/0xd4 [ 39.033862] do_el0_svc+0x18/0x20 [ 39.033870] el0_svc+0x3c/0xf0 [ 39.033880] el0t_64_sync_handler+0xc0/0xc4 [ 39.033888] el0t_64_sync+0x154/0x158 [ 39.041274] ravb 11c30000.ethernet eth0: Link is Down(CVE-2025-21801)
In the Linux kernel, the following vulnerability has been resolved:
usb: renesas_usbhs: Flush the notify_hotplug_work
When performing continuous unbind/bind operations on the USB drivers available on the Renesas RZ/G2L SoC, a kernel crash with the message "Unable to handle kernel NULL pointer dereference at virtual address" may occur. This issue points to the usbhsc_notify_hotplug() function.
Flush the delayed work to avoid its execution when driver resources are unavailable.(CVE-2025-21917)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btrtl: Prevent potential NULL dereference
The btrtl_initialize() function checks that rtl_load_file() either had an error or it loaded a zero length file. However, if it loaded a zero length file then the error code is not set correctly. It results in an error pointer vs NULL bug, followed by a NULL pointer dereference. This was detected by Smatch:
drivers/bluetooth/btrtl.c:592 btrtl_initialize() warn: passing zero to 'ERR_PTR'(CVE-2025-37792)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: ets: Fix double list add in class with netem as child qdisc
As described in Gerrard's report 1, there are use cases where a netem child qdisc will make the parent qdisc's enqueue callback reentrant. In the case of ets, there won't be a UAF, but the code will add the same classifier to the list twice, which will cause memory corruption.
In addition to checking for qlen being zero, this patch checks whether the class was already added to the active_list (cl_is_active) before doing the addition to cater for the reentrant case.
1 https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/(CVE-2025-37914)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: adjust subpage bit start based on sectorsize
When running machines with 64k page size and a 16k nodesize we started seeing tree log corruption in production. This turned out to be because we were not writing out dirty blocks sometimes, so this in fact affects all metadata writes.
When writing out a subpage EB we scan the subpage bitmap for a dirty range. If the range isn't dirty we do
bit_start++;
to move onto the next bit. The problem is the bitmap is based on the number of sectors that an EB has. So in this case, we have a 64k pagesize, 16k nodesize, but a 4k sectorsize. This means our bitmap is 4 bits for every node. With a 64k page size we end up with 4 nodes per page.
To make this easier this is how everything looks
[0 16k 32k 48k ] logical address [0 4 8 12 ] radix tree offset [ 64k page ] folio [ 16k eb ][ 16k eb ][ 16k eb ][ 16k eb ] extent buffers [ | | | | | | | | | | | | | | | | ] bitmap
Now we use all of our addressing based on fs_info->sectorsize_bits, so as you can see the above our 16k eb->start turns into radix entry 4.
When we find a dirty range for our eb, we correctly do bit_start += sectors_per_node, because if we start at bit 0, the next bit for the next eb is 4, to correspond to eb->start 16k.
However if our range is clean, we will do bit_start++, which will now put us offset from our radix tree entries.
In our case, assume that the first time we check the bitmap the block is not dirty, we increment bit_start so now it == 1, and then we loop around and check again. This time it is dirty, and we go to find that start using the following equation
start = folio_start + bit_start * fs_info->sectorsize;
so in the case above, eb->start 0 is now dirty, and we calculate start as
0 + 1 * fs_info->sectorsize = 4096
4096 >> 12 = 1
Now we're looking up the radix tree for 1, and we won't find an eb. What's worse is now we're using bit_start == 1, so we do bit_start += sectors_per_node, which is now 5. If that eb is dirty we will run into the same thing, we will look at an offset that is not populated in the radix tree, and now we're skipping the writeout of dirty extent buffers.
The best fix for this is to not use sectorsize_bits to address nodes, but that's a larger change. Since this is a fs corruption problem fix it simply by always using sectors_per_node to increment the start bit.(CVE-2025-37931)
In the Linux kernel, the following vulnerability has been resolved:
bus: fsl-mc: fix double-free on mc_dev
The blamed commit tried to simplify how the deallocations are done but, in the process, introduced a double-free on the mc_dev variable.
In case the MC device is a DPRC, a new mc_bus is allocated and the mc_dev variable is just a reference to one of its fields. In this circumstance, on the error path only the mc_bus should be freed.
This commit introduces back the following checkpatch warning which is a false-positive.
WARNING: kfree(NULL) is safe and this check is probably not required + if (mc_bus) + kfree(mc_bus);(CVE-2025-38313)
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to bail out in get_new_segment()
------------[ cut here ]------------ WARNING: CPU: 3 PID: 579 at fs/f2fs/segment.c:2832 new_curseg+0x5e8/0x6dc pc : new_curseg+0x5e8/0x6dc Call trace: new_curseg+0x5e8/0x6dc f2fs_allocate_data_block+0xa54/0xe28 do_write_page+0x6c/0x194 f2fs_do_write_node_page+0x38/0x78 __write_node_page+0x248/0x6d4 f2fs_sync_node_pages+0x524/0x72c f2fs_write_checkpoint+0x4bc/0x9b0 __checkpoint_and_complete_reqs+0x80/0x244 issue_checkpoint_thread+0x8c/0xec kthread+0x114/0x1bc ret_from_fork+0x10/0x20
get_new_segment() detects inconsistent status in between free_segmap and free_secmap, let's record such error into super block, and bail out get_new_segment() instead of continue using the segment.(CVE-2025-38333)
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: fix GCC_GCC_PCIE_HOT_RST definition for WCN7850
GCC_GCC_PCIE_HOT_RST is wrongly defined for WCN7850, causing kernel crash on some specific platforms.
Since this register is divergent for WCN7850 and QCN9274, move it to register table to allow different definitions. Then correct the register address for WCN7850 to fix this issue.
Note IPQ5332 is not affected as it is not PCIe based device.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3(CVE-2025-38414)
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: cancle set bad inode after removing name fails
The reproducer uses a file0 on a ntfs3 file system with a corrupted i_link. When renaming, the file0's inode is marked as a bad inode because the file name cannot be deleted.
The underlying bug is that make_bad_inode() is called on a live inode. In some cases it's "icache lookup finds a normal inode, d_splice_alias() is called to attach it to dentry, while another thread decides to call make_bad_inode() on it - that would evict it from icache, but we'd already found it there earlier". In some it's outright "we have an inode attached to dentry - that's how we got it in the first place; let's call make_bad_inode() on it just for shits and giggles".(CVE-2025-38615)
In the Linux kernel, the following vulnerability has been resolved:
scsi: libiscsi: Initialize iscsi_conn->dd_data only if memory is allocated
In case of an ib_fast_reg_mr allocation failure during iSER setup, the machine hits a panic because iscsi_conn->dd_data is initialized unconditionally, even when no memory is allocated (dd_size == 0). This leads invalid pointer dereference during connection teardown.
Fix by setting iscsi_conn->dd_data only if memory is actually allocated.
Panic trace:
iser: iser_create_fastreg_desc: Failed to allocate ib_fast_reg_mr err=-12 iser: iser_alloc_rx_descriptors: failed allocating rx descriptors / data buffers BUG: unable to handle page fault for address: fffffffffffffff8 RIP: 0010:swake_up_locked.part.5+0xa/0x40 Call Trace: complete+0x31/0x40 iscsi_iser_conn_stop+0x88/0xb0 [ib_iser] iscsi_stop_conn+0x66/0xc0 [scsi_transport_iscsi] iscsi_if_stop_conn+0x14a/0x150 [scsi_transport_iscsi] iscsi_if_rx+0x1135/0x1834 [scsi_transport_iscsi] ? netlink_lookup+0x12f/0x1b0 ? netlink_deliver_tap+0x2c/0x200 netlink_unicast+0x1ab/0x280 netlink_sendmsg+0x257/0x4f0 ? _copy_from_user+0x29/0x60 sock_sendmsg+0x5f/0x70(CVE-2025-38700)
In the Linux kernel, the following vulnerability has been resolved:
ext4: do not BUG when INLINE_DATA_FL lacks system.data xattr
A syzbot fuzzed image triggered a BUG_ON in ext4_update_inline_data() when an inode had the INLINE_DATA_FL flag set but was missing the system.data extended attribute.
Since this can happen due to a maiciouly fuzzed file system, we shouldn't BUG, but rather, report it as a corrupted file system.
Add similar replacements of BUG_ON with EXT4_ERROR_INODE() ii ext4_create_inline_data() and ext4_inline_data_truncate().(CVE-2025-38701)
In the Linux kernel, the following vulnerability has been resolved:
loop: Avoid updating block size under exclusive owner
Syzbot came up with a reproducer where a loop device block size is changed underneath a mounted filesystem. This causes a mismatch between the block device block size and the block size stored in the superblock causing confusion in various places such as fs/buffer.c. The particular issue triggered by syzbot was a warning in __getblk_slow() due to requested buffer size not matching block device block size.
Fix the problem by getting exclusive hold of the loop device to change its block size. This fails if somebody (such as filesystem) has already an exclusive ownership of the block device and thus prevents modifying the loop device under some exclusive owner which doesn't expect it.(CVE-2025-38709)
In the Linux kernel, the following vulnerability has been resolved:
fs/buffer: fix use-after-free when call bh_read() helper
There's issue as follows: BUG: KASAN: stack-out-of-bounds in end_buffer_read_sync+0xe3/0x110 Read of size 8 at addr ffffc9000168f7f8 by task swapper/3/0 CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.16.0-862.14.0.6.x86_64 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <IRQ> dump_stack_lvl+0x55/0x70 print_address_description.constprop.0+0x2c/0x390 print_report+0xb4/0x270 kasan_report+0xb8/0xf0 end_buffer_read_sync+0xe3/0x110 end_bio_bh_io_sync+0x56/0x80 blk_update_request+0x30a/0x720 scsi_end_request+0x51/0x2b0 scsi_io_completion+0xe3/0x480 ? scsi_device_unbusy+0x11e/0x160 blk_complete_reqs+0x7b/0x90 handle_softirqs+0xef/0x370 irq_exit_rcu+0xa5/0xd0 sysvec_apic_timer_interrupt+0x6e/0x90 </IRQ>
Above issue happens when do ntfs3 filesystem mount, issue may happens as follows: mount IRQ ntfs_fill_super read_cache_page do_read_cache_folio filemap_read_folio mpage_read_folio do_mpage_readpage ntfs_get_block_vbo bh_read submit_bh wait_on_buffer(bh); blk_complete_reqs scsi_io_completion scsi_end_request blk_update_request end_bio_bh_io_sync end_buffer_read_sync __end_buffer_read_notouch unlock_buffer
wait_on_buffer(bh);--> return will return to caller
put_bh
--> trigger stack-out-of-bounds
In the mpage_read_folio() function, the stack variable 'map_bh' is passed to ntfs_get_block_vbo(). Once unlock_buffer() unlocks and wait_on_buffer() returns to continue processing, the stack variable is likely to be reclaimed. Consequently, during the end_buffer_read_sync() process, calling put_bh() may result in stack overrun.
If the bh is not allocated on the stack, it belongs to a folio. Freeing a buffer head which belongs to a folio is done by drop_buffers() which will fail to free buffers which are still locked. So it is safe to call put_bh() before __end_buffer_read_notouch().(CVE-2025-39691)
In the Linux kernel, the following vulnerability has been resolved:
soc: qcom: mdt_loader: Ensure we don't read past the ELF header
When the MDT loader is used in remoteproc, the ELF header is sanitized beforehand, but that's not necessary the case for other clients.
Validate the size of the firmware buffer to ensure that we don't read past the end as we iterate over the header. e_phentsize and e_shentsize are validated as well, to ensure that the assumptions about step size in the traversal are valid.(CVE-2025-39787)
In the Linux kernel, the following vulnerability has been resolved:
block: avoid possible overflow for chunk_sectors check in blk_stack_limits()
In blk_stack_limits(), we check that the t->chunk_sectors value is a multiple of the t->physical_block_size value.
However, by finding the chunk_sectors value in bytes, we may overflow the unsigned int which holds chunk_sectors, so change the check to be based on sectors.(CVE-2025-39795)
In the Linux kernel, the following vulnerability has been resolved:
pcmcia: Add error handling for add_interval() in do_validate_mem()
In the do_validate_mem(), the call to add_interval() does not handle errors. If kmalloc() fails in add_interval(), it could result in a null pointer being inserted into the linked list, leading to illegal memory access when sub_interval() is called next.
This patch adds an error handling for the add_interval(). If add_interval() returns an error, the function will return early with the error code.(CVE-2025-39920)
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: qcom: bam_dma: Fix DT error handling for num-channels/ees
When we don't have a clock specified in the device tree, we have no way to ensure the BAM is on. This is often the case for remotely-controlled or remotely-powered BAM instances. In this case, we need to read num-channels from the DT to have all the necessary information to complete probing.
However, at the moment invalid device trees without clock and without num-channels still continue probing, because the error handling is missing return statements. The driver will then later try to read the number of channels from the registers. This is unsafe, because it relies on boot firmware and lucky timing to succeed. Unfortunately, the lack of proper error handling here has been abused for several Qualcomm SoCs upstream, causing early boot crashes in several situations [1, 2].
Avoid these early crashes by erroring out when any of the required DT properties are missing. Note that this will break some of the existing DTs upstream (mainly BAM instances related to the crypto engine). However, clearly these DTs have never been tested properly, since the error in the kernel log was just ignored. It's safer to disable the crypto engine for these broken DTBs.
In the Linux kernel i40e driver, there is a security vulnerability: the driver lacks boundary checks for the maximum number of virtual function (VF) filters. An attacker could potentially exploit this vulnerability to request filter counts beyond the boundaries, leading to potential security issues.(CVE-2025-39968)
In the Linux kernel, the following vulnerability has been resolved: i40e: fix idx validation in config queues msg. Ensure idx is within range of active/initialized TCs when iterating over vf->ch[idx] in i40e_vc_config_queues_msg().(CVE-2025-39971)
In the Linux kernel, the following vulnerability has been resolved:
x86/mce: use is_copy_from_user() to determine copy-from-user context
Patch series "mm/hwpoison: Fix regressions in memory failure handling", v4.
1. What am I trying to do:
This patchset resolves two critical regressions related to memory failure handling that have appeared in the upstream kernel since version 5.17, as compared to 5.10 LTS.
- copyin case: poison found in user page while kernel copying from user space
- instr case: poison found while instruction fetching in user space
2. What is the expected outcome and why
- For copyin case:
Kernel can recover from poison found where kernel is doing get_user() or copy_from_user() if those places get an error return and the kernel return -EFAULT to the process instead of crashing. More specifily, MCE handler checks the fixup handler type to decide whether an in kernel #MC can be recovered. When EX_TYPE_UACCESS is found, the PC jumps to recovery code specified in _ASM_EXTABLE_FAULT() and return a -EFAULT to user space.
- For instr case:
If a poison found while instruction fetching in user space, full recovery is possible. User process takes #PF, Linux allocates a new page and fills by reading from storage.
3. What actually happens and why
- For copyin case: kernel panic since v5.17
Commit 4c132d1d844a ("x86/futex: Remove .fixup usage") introduced a new extable fixup type, EX_TYPE_EFAULT_REG, and later patches updated the extable fixup type for copy-from-user operations, changing it from EX_TYPE_UACCESS to EX_TYPE_EFAULT_REG. It breaks previous EX_TYPE_UACCESS handling when posion found in get_user() or copy_from_user().
- For instr case: user process is killed by a SIGBUS signal due to #CMCI and #MCE race
When an uncorrected memory error is consumed there is a race between the CMCI from the memory controller reporting an uncorrected error with a UCNA signature, and the core reporting and SRAR signature machine check when the data is about to be consumed.
Background: why UNcorrected errors tied to CMCI in Intel platform 1
Prior to Icelake memory controllers reported patrol scrub events that detected a previously unseen uncorrected error in memory by signaling a broadcast machine check with an SRAO (Software Recoverable Action Optional) signature in the machine check bank. This was overkill because it's not an urgent problem that no core is on the verge of consuming that bad data. It's also found that multi SRAO UCE may cause nested MCE interrupts and finally become an IERR.
Hence, Intel downgrades the machine check bank signature of patrol scrub from SRAO to UCNA (Uncorrected, No Action required), and signal changed to
CMCI. Just to add to the confusion, Linux does take an action (in
uc_decode_notifier()) to try to offline the page despite the UCNA signature name.
Background: why #CMCI and #MCE race when poison is consuming in
Intel platform [1]
Having decided that CMCI/UCNA is the best action for patrol scrub errors, the memory controller uses it for reads too. But the memory controller is executing asynchronously from the core, and can't tell the difference between a "real" read and a speculative read. So it will do CMCI/UCNA if an error is found in any read.
Thus:
1) Core is clever and thinks address A is needed soon, issues a speculative read.
2) Core finds it is going to use address A soon after sending the read request
3) The CMCI from the memory controller is in a race with MCE from the core that will soon try to retire the load from address A.
Quite often (because speculation has got better) the CMCI from the memory controller is delivered before the core is committed to the instruction reading address A, so the interrupt is taken, and Linux offlines the page (marking it as poison).
Why user process is killed for instr case
Commit 046545a661af ("mm/hwpoison: fix error page recovered but reported "not ---truncated---(CVE-2025-39989)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-113.0.0.105.oe2403.aarch64.rpm",
"bpftool-debuginfo-6.6.0-113.0.0.105.oe2403.aarch64.rpm",
"kernel-6.6.0-113.0.0.105.oe2403.aarch64.rpm",
"kernel-debuginfo-6.6.0-113.0.0.105.oe2403.aarch64.rpm",
"kernel-debugsource-6.6.0-113.0.0.105.oe2403.aarch64.rpm",
"kernel-devel-6.6.0-113.0.0.105.oe2403.aarch64.rpm",
"kernel-headers-6.6.0-113.0.0.105.oe2403.aarch64.rpm",
"kernel-source-6.6.0-113.0.0.105.oe2403.aarch64.rpm",
"kernel-tools-6.6.0-113.0.0.105.oe2403.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-113.0.0.105.oe2403.aarch64.rpm",
"kernel-tools-devel-6.6.0-113.0.0.105.oe2403.aarch64.rpm",
"perf-6.6.0-113.0.0.105.oe2403.aarch64.rpm",
"perf-debuginfo-6.6.0-113.0.0.105.oe2403.aarch64.rpm",
"python3-perf-6.6.0-113.0.0.105.oe2403.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-113.0.0.105.oe2403.aarch64.rpm"
],
"src": [
"kernel-6.6.0-113.0.0.105.oe2403.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-113.0.0.105.oe2403.x86_64.rpm",
"bpftool-debuginfo-6.6.0-113.0.0.105.oe2403.x86_64.rpm",
"kernel-6.6.0-113.0.0.105.oe2403.x86_64.rpm",
"kernel-debuginfo-6.6.0-113.0.0.105.oe2403.x86_64.rpm",
"kernel-debugsource-6.6.0-113.0.0.105.oe2403.x86_64.rpm",
"kernel-devel-6.6.0-113.0.0.105.oe2403.x86_64.rpm",
"kernel-headers-6.6.0-113.0.0.105.oe2403.x86_64.rpm",
"kernel-source-6.6.0-113.0.0.105.oe2403.x86_64.rpm",
"kernel-tools-6.6.0-113.0.0.105.oe2403.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-113.0.0.105.oe2403.x86_64.rpm",
"kernel-tools-devel-6.6.0-113.0.0.105.oe2403.x86_64.rpm",
"perf-6.6.0-113.0.0.105.oe2403.x86_64.rpm",
"perf-debuginfo-6.6.0-113.0.0.105.oe2403.x86_64.rpm",
"python3-perf-6.6.0-113.0.0.105.oe2403.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-113.0.0.105.oe2403.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-113.0.0.105.oe2403"
}
],
"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: 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\nusb: renesas_usbhs: Flush the notify_hotplug_work\n\nWhen performing continuous unbind/bind operations on the USB drivers\navailable on the Renesas RZ/G2L SoC, a kernel crash with the message\n\u0026quot;Unable to handle kernel NULL pointer dereference at virtual address\u0026quot;\nmay occur. This issue points to the usbhsc_notify_hotplug() function.\n\nFlush the delayed work to avoid its execution when driver resources are\nunavailable.(CVE-2025-21917)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: btrtl: Prevent potential NULL dereference\n\nThe btrtl_initialize() function checks that rtl_load_file() either\nhad an error or it loaded a zero length file. However, if it loaded\na zero length file then the error code is not set correctly. It\nresults in an error pointer vs NULL bug, followed by a NULL pointer\ndereference. This was detected by Smatch:\n\ndrivers/bluetooth/btrtl.c:592 btrtl_initialize() warn: passing zero to \u0026apos;ERR_PTR\u0026apos;(CVE-2025-37792)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: ets: Fix double list add in class with netem as child qdisc\n\nAs described in Gerrard\u0026apos;s report [1], there are use cases where a netem\nchild qdisc will make the parent qdisc\u0026apos;s enqueue callback reentrant.\nIn the case of ets, there won\u0026apos;t be a UAF, but the code will add the same\nclassifier to the list twice, which will cause memory corruption.\n\nIn addition to checking for qlen being zero, this patch checks whether\nthe class was already added to the active_list (cl_is_active) before\ndoing the addition to cater for the reentrant case.\n\n[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/(CVE-2025-37914)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: adjust subpage bit start based on sectorsize\n\nWhen running machines with 64k page size and a 16k nodesize we started\nseeing tree log corruption in production. This turned out to be because\nwe were not writing out dirty blocks sometimes, so this in fact affects\nall metadata writes.\n\nWhen writing out a subpage EB we scan the subpage bitmap for a dirty\nrange. If the range isn\u0026apos;t dirty we do\n\n\tbit_start++;\n\nto move onto the next bit. The problem is the bitmap is based on the\nnumber of sectors that an EB has. So in this case, we have a 64k\npagesize, 16k nodesize, but a 4k sectorsize. This means our bitmap is 4\nbits for every node. With a 64k page size we end up with 4 nodes per\npage.\n\nTo make this easier this is how everything looks\n\n[0 16k 32k 48k ] logical address\n[0 4 8 12 ] radix tree offset\n[ 64k page ] folio\n[ 16k eb ][ 16k eb ][ 16k eb ][ 16k eb ] extent buffers\n[ | | | | | | | | | | | | | | | | ] bitmap\n\nNow we use all of our addressing based on fs_info-\u0026gt;sectorsize_bits, so\nas you can see the above our 16k eb-\u0026gt;start turns into radix entry 4.\n\nWhen we find a dirty range for our eb, we correctly do bit_start +=\nsectors_per_node, because if we start at bit 0, the next bit for the\nnext eb is 4, to correspond to eb-\u0026gt;start 16k.\n\nHowever if our range is clean, we will do bit_start++, which will now\nput us offset from our radix tree entries.\n\nIn our case, assume that the first time we check the bitmap the block is\nnot dirty, we increment bit_start so now it == 1, and then we loop\naround and check again. This time it is dirty, and we go to find that\nstart using the following equation\n\n\tstart = folio_start + bit_start * fs_info-\u0026gt;sectorsize;\n\nso in the case above, eb-\u0026gt;start 0 is now dirty, and we calculate start\nas\n\n\t0 + 1 * fs_info-\u0026gt;sectorsize = 4096\n\t4096 \u0026gt;\u0026gt; 12 = 1\n\nNow we\u0026apos;re looking up the radix tree for 1, and we won\u0026apos;t find an eb.\nWhat\u0026apos;s worse is now we\u0026apos;re using bit_start == 1, so we do bit_start +=\nsectors_per_node, which is now 5. If that eb is dirty we will run into\nthe same thing, we will look at an offset that is not populated in the\nradix tree, and now we\u0026apos;re skipping the writeout of dirty extent buffers.\n\nThe best fix for this is to not use sectorsize_bits to address nodes,\nbut that\u0026apos;s a larger change. Since this is a fs corruption problem fix\nit simply by always using sectors_per_node to increment the start bit.(CVE-2025-37931)\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\nf2fs: fix to bail out in get_new_segment()\n\n------------[ cut here ]------------\nWARNING: CPU: 3 PID: 579 at fs/f2fs/segment.c:2832 new_curseg+0x5e8/0x6dc\npc : new_curseg+0x5e8/0x6dc\nCall trace:\n new_curseg+0x5e8/0x6dc\n f2fs_allocate_data_block+0xa54/0xe28\n do_write_page+0x6c/0x194\n f2fs_do_write_node_page+0x38/0x78\n __write_node_page+0x248/0x6d4\n f2fs_sync_node_pages+0x524/0x72c\n f2fs_write_checkpoint+0x4bc/0x9b0\n __checkpoint_and_complete_reqs+0x80/0x244\n issue_checkpoint_thread+0x8c/0xec\n kthread+0x114/0x1bc\n ret_from_fork+0x10/0x20\n\nget_new_segment() detects inconsistent status in between free_segmap\nand free_secmap, let\u0026apos;s record such error into super block, and bail\nout get_new_segment() instead of continue using the segment.(CVE-2025-38333)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath12k: fix GCC_GCC_PCIE_HOT_RST definition for WCN7850\n\nGCC_GCC_PCIE_HOT_RST is wrongly defined for WCN7850, causing kernel crash\non some specific platforms.\n\nSince this register is divergent for WCN7850 and QCN9274, move it to\nregister table to allow different definitions. Then correct the register\naddress for WCN7850 to fix this issue.\n\nNote IPQ5332 is not affected as it is not PCIe based device.\n\nTested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3(CVE-2025-38414)\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\nscsi: libiscsi: Initialize iscsi_conn-\u0026gt;dd_data only if memory is allocated\n\nIn case of an ib_fast_reg_mr allocation failure during iSER setup, the\nmachine hits a panic because iscsi_conn-\u0026gt;dd_data is initialized\nunconditionally, even when no memory is allocated (dd_size == 0). This\nleads invalid pointer dereference during connection teardown.\n\nFix by setting iscsi_conn-\u0026gt;dd_data only if memory is actually allocated.\n\nPanic trace:\n------------\n iser: iser_create_fastreg_desc: Failed to allocate ib_fast_reg_mr err=-12\n iser: iser_alloc_rx_descriptors: failed allocating rx descriptors / data buffers\n BUG: unable to handle page fault for address: fffffffffffffff8\n RIP: 0010:swake_up_locked.part.5+0xa/0x40\n Call Trace:\n complete+0x31/0x40\n iscsi_iser_conn_stop+0x88/0xb0 [ib_iser]\n iscsi_stop_conn+0x66/0xc0 [scsi_transport_iscsi]\n iscsi_if_stop_conn+0x14a/0x150 [scsi_transport_iscsi]\n iscsi_if_rx+0x1135/0x1834 [scsi_transport_iscsi]\n ? netlink_lookup+0x12f/0x1b0\n ? netlink_deliver_tap+0x2c/0x200\n netlink_unicast+0x1ab/0x280\n netlink_sendmsg+0x257/0x4f0\n ? _copy_from_user+0x29/0x60\n sock_sendmsg+0x5f/0x70(CVE-2025-38700)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: do not BUG when INLINE_DATA_FL lacks system.data xattr\n\nA syzbot fuzzed image triggered a BUG_ON in ext4_update_inline_data()\nwhen an inode had the INLINE_DATA_FL flag set but was missing the\nsystem.data extended attribute.\n\nSince this can happen due to a maiciouly fuzzed file system, we\nshouldn\u0026apos;t BUG, but rather, report it as a corrupted file system.\n\nAdd similar replacements of BUG_ON with EXT4_ERROR_INODE() ii\next4_create_inline_data() and ext4_inline_data_truncate().(CVE-2025-38701)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nloop: Avoid updating block size under exclusive owner\n\nSyzbot came up with a reproducer where a loop device block size is\nchanged underneath a mounted filesystem. This causes a mismatch between\nthe block device block size and the block size stored in the superblock\ncausing confusion in various places such as fs/buffer.c. The particular\nissue triggered by syzbot was a warning in __getblk_slow() due to\nrequested buffer size not matching block device block size.\n\nFix the problem by getting exclusive hold of the loop device to change\nits block size. This fails if somebody (such as filesystem) has already\nan exclusive ownership of the block device and thus prevents modifying\nthe loop device under some exclusive owner which doesn\u0026apos;t expect it.(CVE-2025-38709)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/buffer: fix use-after-free when call bh_read() helper\n\nThere\u0026apos;s issue as follows:\nBUG: KASAN: stack-out-of-bounds in end_buffer_read_sync+0xe3/0x110\nRead of size 8 at addr ffffc9000168f7f8 by task swapper/3/0\nCPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.16.0-862.14.0.6.x86_64\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996)\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n dump_stack_lvl+0x55/0x70\n print_address_description.constprop.0+0x2c/0x390\n print_report+0xb4/0x270\n kasan_report+0xb8/0xf0\n end_buffer_read_sync+0xe3/0x110\n end_bio_bh_io_sync+0x56/0x80\n blk_update_request+0x30a/0x720\n scsi_end_request+0x51/0x2b0\n scsi_io_completion+0xe3/0x480\n ? scsi_device_unbusy+0x11e/0x160\n blk_complete_reqs+0x7b/0x90\n handle_softirqs+0xef/0x370\n irq_exit_rcu+0xa5/0xd0\n sysvec_apic_timer_interrupt+0x6e/0x90\n \u0026lt;/IRQ\u0026gt;\n\n Above issue happens when do ntfs3 filesystem mount, issue may happens\n as follows:\n mount IRQ\nntfs_fill_super\n read_cache_page\n do_read_cache_folio\n filemap_read_folio\n mpage_read_folio\n\t do_mpage_readpage\n\t ntfs_get_block_vbo\n\t bh_read\n\t submit_bh\n\t wait_on_buffer(bh);\n\t blk_complete_reqs\n\t\t\t\t scsi_io_completion\n\t\t\t\t scsi_end_request\n\t\t\t\t blk_update_request\n\t\t\t\t end_bio_bh_io_sync\n\t\t\t\t\t end_buffer_read_sync\n\t\t\t\t\t __end_buffer_read_notouch\n\t\t\t\t\t unlock_buffer\n\n wait_on_buffer(bh);--\u0026gt; return will return to caller\n\n\t\t\t\t\t put_bh\n\t\t\t\t\t --\u0026gt; trigger stack-out-of-bounds\nIn the mpage_read_folio() function, the stack variable \u0026apos;map_bh\u0026apos; is\npassed to ntfs_get_block_vbo(). Once unlock_buffer() unlocks and\nwait_on_buffer() returns to continue processing, the stack variable\nis likely to be reclaimed. Consequently, during the end_buffer_read_sync()\nprocess, calling put_bh() may result in stack overrun.\n\nIf the bh is not allocated on the stack, it belongs to a folio. Freeing\na buffer head which belongs to a folio is done by drop_buffers() which\nwill fail to free buffers which are still locked. So it is safe to call\nput_bh() before __end_buffer_read_notouch().(CVE-2025-39691)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsoc: qcom: mdt_loader: Ensure we don\u0026apos;t read past the ELF header\n\nWhen the MDT loader is used in remoteproc, the ELF header is sanitized\nbeforehand, but that\u0026apos;s not necessary the case for other clients.\n\nValidate the size of the firmware buffer to ensure that we don\u0026apos;t read\npast the end as we iterate over the header. e_phentsize and e_shentsize\nare validated as well, to ensure that the assumptions about step size in\nthe traversal are valid.(CVE-2025-39787)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblock: avoid possible overflow for chunk_sectors check in blk_stack_limits()\n\nIn blk_stack_limits(), we check that the t-\u0026gt;chunk_sectors value is a\nmultiple of the t-\u0026gt;physical_block_size value.\n\nHowever, by finding the chunk_sectors value in bytes, we may overflow\nthe unsigned int which holds chunk_sectors, so change the check to be\nbased on sectors.(CVE-2025-39795)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npcmcia: Add error handling for add_interval() in do_validate_mem()\n\nIn the do_validate_mem(), the call to add_interval() does not\nhandle errors. If kmalloc() fails in add_interval(), it could\nresult in a null pointer being inserted into the linked list,\nleading to illegal memory access when sub_interval() is called\nnext.\n\nThis patch adds an error handling for the add_interval(). If\nadd_interval() returns an error, the function will return early\nwith the error code.(CVE-2025-39920)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: qcom: bam_dma: Fix DT error handling for num-channels/ees\n\nWhen we don\u0026apos;t have a clock specified in the device tree, we have no way to\nensure the BAM is on. This is often the case for remotely-controlled or\nremotely-powered BAM instances. In this case, we need to read num-channels\nfrom the DT to have all the necessary information to complete probing.\n\nHowever, at the moment invalid device trees without clock and without\nnum-channels still continue probing, because the error handling is missing\nreturn statements. The driver will then later try to read the number of\nchannels from the registers. This is unsafe, because it relies on boot\nfirmware and lucky timing to succeed. Unfortunately, the lack of proper\nerror handling here has been abused for several Qualcomm SoCs upstream,\ncausing early boot crashes in several situations [1, 2].\n\nAvoid these early crashes by erroring out when any of the required DT\nproperties are missing. Note that this will break some of the existing DTs\nupstream (mainly BAM instances related to the crypto engine). However,\nclearly these DTs have never been tested properly, since the error in the\nkernel log was just ignored. It\u0026apos;s safer to disable the crypto engine for\nthese broken DTBs.\n\n[1]: https://lore.kernel.org/r/(CVE-2025-39923)\n\nIn the Linux kernel i40e driver, there is a security vulnerability: the driver lacks boundary checks for the maximum number of virtual function (VF) filters. An attacker could potentially exploit this vulnerability to request filter counts beyond the boundaries, leading to potential security issues.(CVE-2025-39968)\n\nIn the Linux kernel, the following vulnerability has been resolved: i40e: fix idx validation in config queues msg. Ensure idx is within range of active/initialized TCs when iterating over vf-\u0026gt;ch[idx] in i40e_vc_config_queues_msg().(CVE-2025-39971)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/mce: use is_copy_from_user() to determine copy-from-user context\n\nPatch series \u0026quot;mm/hwpoison: Fix regressions in memory failure handling\u0026quot;,\nv4.\n\n## 1. What am I trying to do:\n\nThis patchset resolves two critical regressions related to memory failure\nhandling that have appeared in the upstream kernel since version 5.17, as\ncompared to 5.10 LTS.\n\n - copyin case: poison found in user page while kernel copying from user space\n - instr case: poison found while instruction fetching in user space\n\n## 2. What is the expected outcome and why\n\n- For copyin case:\n\nKernel can recover from poison found where kernel is doing get_user() or\ncopy_from_user() if those places get an error return and the kernel return\n-EFAULT to the process instead of crashing. More specifily, MCE handler\nchecks the fixup handler type to decide whether an in kernel #MC can be\nrecovered. When EX_TYPE_UACCESS is found, the PC jumps to recovery code\nspecified in _ASM_EXTABLE_FAULT() and return a -EFAULT to user space.\n\n- For instr case:\n\nIf a poison found while instruction fetching in user space, full recovery\nis possible. User process takes #PF, Linux allocates a new page and fills\nby reading from storage.\n\n\n## 3. What actually happens and why\n\n- For copyin case: kernel panic since v5.17\n\nCommit 4c132d1d844a (\u0026quot;x86/futex: Remove .fixup usage\u0026quot;) introduced a new\nextable fixup type, EX_TYPE_EFAULT_REG, and later patches updated the\nextable fixup type for copy-from-user operations, changing it from\nEX_TYPE_UACCESS to EX_TYPE_EFAULT_REG. It breaks previous EX_TYPE_UACCESS\nhandling when posion found in get_user() or copy_from_user().\n\n- For instr case: user process is killed by a SIGBUS signal due to #CMCI\n and #MCE race\n\nWhen an uncorrected memory error is consumed there is a race between the\nCMCI from the memory controller reporting an uncorrected error with a UCNA\nsignature, and the core reporting and SRAR signature machine check when\nthe data is about to be consumed.\n\n### Background: why *UN*corrected errors tied to *C*MCI in Intel platform [1]\n\nPrior to Icelake memory controllers reported patrol scrub events that\ndetected a previously unseen uncorrected error in memory by signaling a\nbroadcast machine check with an SRAO (Software Recoverable Action\nOptional) signature in the machine check bank. This was overkill because\nit\u0026apos;s not an urgent problem that no core is on the verge of consuming that\nbad data. It\u0026apos;s also found that multi SRAO UCE may cause nested MCE\ninterrupts and finally become an IERR.\n\nHence, Intel downgrades the machine check bank signature of patrol scrub\nfrom SRAO to UCNA (Uncorrected, No Action required), and signal changed to\n#CMCI. Just to add to the confusion, Linux does take an action (in\nuc_decode_notifier()) to try to offline the page despite the UC*NA*\nsignature name.\n\n### Background: why #CMCI and #MCE race when poison is consuming in\n Intel platform [1]\n\nHaving decided that CMCI/UCNA is the best action for patrol scrub errors,\nthe memory controller uses it for reads too. But the memory controller is\nexecuting asynchronously from the core, and can\u0026apos;t tell the difference\nbetween a \u0026quot;real\u0026quot; read and a speculative read. So it will do CMCI/UCNA if\nan error is found in any read.\n\nThus:\n\n1) Core is clever and thinks address A is needed soon, issues a\n speculative read.\n\n2) Core finds it is going to use address A soon after sending the read\n request\n\n3) The CMCI from the memory controller is in a race with MCE from the\n core that will soon try to retire the load from address A.\n\nQuite often (because speculation has got better) the CMCI from the memory\ncontroller is delivered before the core is committed to the instruction\nreading address A, so the interrupt is taken, and Linux offlines the page\n(marking it as poison).\n\n\n## Why user process is killed for instr case\n\nCommit 046545a661af (\u0026quot;mm/hwpoison: fix error page recovered but reported\n\u0026quot;not\n---truncated---(CVE-2025-39989)",
"id": "OESA-2025-2536",
"modified": "2026-08-06T11:09:37Z",
"published": "2025-10-24T11:09:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2536"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21801"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21917"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37792"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37914"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37931"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38313"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38333"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38414"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38615"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38700"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38701"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38709"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39691"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39787"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39795"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39920"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39923"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39968"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39971"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39989"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2025-21801",
"CVE-2025-21917",
"CVE-2025-37792",
"CVE-2025-37914",
"CVE-2025-37931",
"CVE-2025-38313",
"CVE-2025-38333",
"CVE-2025-38414",
"CVE-2025-38615",
"CVE-2025-38700",
"CVE-2025-38701",
"CVE-2025-38709",
"CVE-2025-39691",
"CVE-2025-39787",
"CVE-2025-39795",
"CVE-2025-39920",
"CVE-2025-39923",
"CVE-2025-39968",
"CVE-2025-39971",
"CVE-2025-39989"
]
}
OESA-2025-2537 (CVE-2025-21801)
Vulnerability from osv_openeuler – Published: 2025-10-24 11:09 – Updated: 2026-08-06 11:09 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
net: ravb: Fix missing rtnl lock in suspend/resume path
Fix the suspend/resume path by ensuring the rtnl lock is held where required. Calls to ravb_open, ravb_close and wol operations must be performed under the rtnl lock to prevent conflicts with ongoing ndo operations.
Without this fix, the following warning is triggered: [ 39.032969] ============================= [ 39.032983] WARNING: suspicious RCU usage [ 39.033019] ----------------------------- [ 39.033033] drivers/net/phy/phy_device.c:2004 suspicious rcu_dereference_protected() usage! ... [ 39.033597] stack backtrace: [ 39.033613] CPU: 0 UID: 0 PID: 174 Comm: python3 Not tainted 6.13.0-rc7-next-20250116-arm64-renesas-00002-g35245dfdc62c #7 [ 39.033623] Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) [ 39.033628] Call trace: [ 39.033633] show_stack+0x14/0x1c (C) [ 39.033652] dump_stack_lvl+0xb4/0xc4 [ 39.033664] dump_stack+0x14/0x1c [ 39.033671] lockdep_rcu_suspicious+0x16c/0x22c [ 39.033682] phy_detach+0x160/0x190 [ 39.033694] phy_disconnect+0x40/0x54 [ 39.033703] ravb_close+0x6c/0x1cc [ 39.033714] ravb_suspend+0x48/0x120 [ 39.033721] dpm_run_callback+0x4c/0x14c [ 39.033731] device_suspend+0x11c/0x4dc [ 39.033740] dpm_suspend+0xdc/0x214 [ 39.033748] dpm_suspend_start+0x48/0x60 [ 39.033758] suspend_devices_and_enter+0x124/0x574 [ 39.033769] pm_suspend+0x1ac/0x274 [ 39.033778] state_store+0x88/0x124 [ 39.033788] kobj_attr_store+0x14/0x24 [ 39.033798] sysfs_kf_write+0x48/0x6c [ 39.033808] kernfs_fop_write_iter+0x118/0x1a8 [ 39.033817] vfs_write+0x27c/0x378 [ 39.033825] ksys_write+0x64/0xf4 [ 39.033833] __arm64_sys_write+0x18/0x20 [ 39.033841] invoke_syscall+0x44/0x104 [ 39.033852] el0_svc_common.constprop.0+0xb4/0xd4 [ 39.033862] do_el0_svc+0x18/0x20 [ 39.033870] el0_svc+0x3c/0xf0 [ 39.033880] el0t_64_sync_handler+0xc0/0xc4 [ 39.033888] el0t_64_sync+0x154/0x158 [ 39.041274] ravb 11c30000.ethernet eth0: Link is Down(CVE-2025-21801)
In the Linux kernel, the following vulnerability has been resolved:
usb: renesas_usbhs: Flush the notify_hotplug_work
When performing continuous unbind/bind operations on the USB drivers available on the Renesas RZ/G2L SoC, a kernel crash with the message "Unable to handle kernel NULL pointer dereference at virtual address" may occur. This issue points to the usbhsc_notify_hotplug() function.
Flush the delayed work to avoid its execution when driver resources are unavailable.(CVE-2025-21917)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btrtl: Prevent potential NULL dereference
The btrtl_initialize() function checks that rtl_load_file() either had an error or it loaded a zero length file. However, if it loaded a zero length file then the error code is not set correctly. It results in an error pointer vs NULL bug, followed by a NULL pointer dereference. This was detected by Smatch:
drivers/bluetooth/btrtl.c:592 btrtl_initialize() warn: passing zero to 'ERR_PTR'(CVE-2025-37792)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: ets: Fix double list add in class with netem as child qdisc
As described in Gerrard's report 1, there are use cases where a netem child qdisc will make the parent qdisc's enqueue callback reentrant. In the case of ets, there won't be a UAF, but the code will add the same classifier to the list twice, which will cause memory corruption.
In addition to checking for qlen being zero, this patch checks whether the class was already added to the active_list (cl_is_active) before doing the addition to cater for the reentrant case.
1 https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/(CVE-2025-37914)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: adjust subpage bit start based on sectorsize
When running machines with 64k page size and a 16k nodesize we started seeing tree log corruption in production. This turned out to be because we were not writing out dirty blocks sometimes, so this in fact affects all metadata writes.
When writing out a subpage EB we scan the subpage bitmap for a dirty range. If the range isn't dirty we do
bit_start++;
to move onto the next bit. The problem is the bitmap is based on the number of sectors that an EB has. So in this case, we have a 64k pagesize, 16k nodesize, but a 4k sectorsize. This means our bitmap is 4 bits for every node. With a 64k page size we end up with 4 nodes per page.
To make this easier this is how everything looks
[0 16k 32k 48k ] logical address [0 4 8 12 ] radix tree offset [ 64k page ] folio [ 16k eb ][ 16k eb ][ 16k eb ][ 16k eb ] extent buffers [ | | | | | | | | | | | | | | | | ] bitmap
Now we use all of our addressing based on fs_info->sectorsize_bits, so as you can see the above our 16k eb->start turns into radix entry 4.
When we find a dirty range for our eb, we correctly do bit_start += sectors_per_node, because if we start at bit 0, the next bit for the next eb is 4, to correspond to eb->start 16k.
However if our range is clean, we will do bit_start++, which will now put us offset from our radix tree entries.
In our case, assume that the first time we check the bitmap the block is not dirty, we increment bit_start so now it == 1, and then we loop around and check again. This time it is dirty, and we go to find that start using the following equation
start = folio_start + bit_start * fs_info->sectorsize;
so in the case above, eb->start 0 is now dirty, and we calculate start as
0 + 1 * fs_info->sectorsize = 4096
4096 >> 12 = 1
Now we're looking up the radix tree for 1, and we won't find an eb. What's worse is now we're using bit_start == 1, so we do bit_start += sectors_per_node, which is now 5. If that eb is dirty we will run into the same thing, we will look at an offset that is not populated in the radix tree, and now we're skipping the writeout of dirty extent buffers.
The best fix for this is to not use sectorsize_bits to address nodes, but that's a larger change. Since this is a fs corruption problem fix it simply by always using sectors_per_node to increment the start bit.(CVE-2025-37931)
In the Linux kernel, the following vulnerability has been resolved:
bus: fsl-mc: fix double-free on mc_dev
The blamed commit tried to simplify how the deallocations are done but, in the process, introduced a double-free on the mc_dev variable.
In case the MC device is a DPRC, a new mc_bus is allocated and the mc_dev variable is just a reference to one of its fields. In this circumstance, on the error path only the mc_bus should be freed.
This commit introduces back the following checkpatch warning which is a false-positive.
WARNING: kfree(NULL) is safe and this check is probably not required + if (mc_bus) + kfree(mc_bus);(CVE-2025-38313)
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to bail out in get_new_segment()
------------[ cut here ]------------ WARNING: CPU: 3 PID: 579 at fs/f2fs/segment.c:2832 new_curseg+0x5e8/0x6dc pc : new_curseg+0x5e8/0x6dc Call trace: new_curseg+0x5e8/0x6dc f2fs_allocate_data_block+0xa54/0xe28 do_write_page+0x6c/0x194 f2fs_do_write_node_page+0x38/0x78 __write_node_page+0x248/0x6d4 f2fs_sync_node_pages+0x524/0x72c f2fs_write_checkpoint+0x4bc/0x9b0 __checkpoint_and_complete_reqs+0x80/0x244 issue_checkpoint_thread+0x8c/0xec kthread+0x114/0x1bc ret_from_fork+0x10/0x20
get_new_segment() detects inconsistent status in between free_segmap and free_secmap, let's record such error into super block, and bail out get_new_segment() instead of continue using the segment.(CVE-2025-38333)
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: fix GCC_GCC_PCIE_HOT_RST definition for WCN7850
GCC_GCC_PCIE_HOT_RST is wrongly defined for WCN7850, causing kernel crash on some specific platforms.
Since this register is divergent for WCN7850 and QCN9274, move it to register table to allow different definitions. Then correct the register address for WCN7850 to fix this issue.
Note IPQ5332 is not affected as it is not PCIe based device.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3(CVE-2025-38414)
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: cancle set bad inode after removing name fails
The reproducer uses a file0 on a ntfs3 file system with a corrupted i_link. When renaming, the file0's inode is marked as a bad inode because the file name cannot be deleted.
The underlying bug is that make_bad_inode() is called on a live inode. In some cases it's "icache lookup finds a normal inode, d_splice_alias() is called to attach it to dentry, while another thread decides to call make_bad_inode() on it - that would evict it from icache, but we'd already found it there earlier". In some it's outright "we have an inode attached to dentry - that's how we got it in the first place; let's call make_bad_inode() on it just for shits and giggles".(CVE-2025-38615)
In the Linux kernel, the following vulnerability has been resolved:
scsi: libiscsi: Initialize iscsi_conn->dd_data only if memory is allocated
In case of an ib_fast_reg_mr allocation failure during iSER setup, the machine hits a panic because iscsi_conn->dd_data is initialized unconditionally, even when no memory is allocated (dd_size == 0). This leads invalid pointer dereference during connection teardown.
Fix by setting iscsi_conn->dd_data only if memory is actually allocated.
Panic trace:
iser: iser_create_fastreg_desc: Failed to allocate ib_fast_reg_mr err=-12 iser: iser_alloc_rx_descriptors: failed allocating rx descriptors / data buffers BUG: unable to handle page fault for address: fffffffffffffff8 RIP: 0010:swake_up_locked.part.5+0xa/0x40 Call Trace: complete+0x31/0x40 iscsi_iser_conn_stop+0x88/0xb0 [ib_iser] iscsi_stop_conn+0x66/0xc0 [scsi_transport_iscsi] iscsi_if_stop_conn+0x14a/0x150 [scsi_transport_iscsi] iscsi_if_rx+0x1135/0x1834 [scsi_transport_iscsi] ? netlink_lookup+0x12f/0x1b0 ? netlink_deliver_tap+0x2c/0x200 netlink_unicast+0x1ab/0x280 netlink_sendmsg+0x257/0x4f0 ? _copy_from_user+0x29/0x60 sock_sendmsg+0x5f/0x70(CVE-2025-38700)
In the Linux kernel, the following vulnerability has been resolved:
ext4: do not BUG when INLINE_DATA_FL lacks system.data xattr
A syzbot fuzzed image triggered a BUG_ON in ext4_update_inline_data() when an inode had the INLINE_DATA_FL flag set but was missing the system.data extended attribute.
Since this can happen due to a maiciouly fuzzed file system, we shouldn't BUG, but rather, report it as a corrupted file system.
Add similar replacements of BUG_ON with EXT4_ERROR_INODE() ii ext4_create_inline_data() and ext4_inline_data_truncate().(CVE-2025-38701)
In the Linux kernel, the following vulnerability has been resolved:
loop: Avoid updating block size under exclusive owner
Syzbot came up with a reproducer where a loop device block size is changed underneath a mounted filesystem. This causes a mismatch between the block device block size and the block size stored in the superblock causing confusion in various places such as fs/buffer.c. The particular issue triggered by syzbot was a warning in __getblk_slow() due to requested buffer size not matching block device block size.
Fix the problem by getting exclusive hold of the loop device to change its block size. This fails if somebody (such as filesystem) has already an exclusive ownership of the block device and thus prevents modifying the loop device under some exclusive owner which doesn't expect it.(CVE-2025-38709)
In the Linux kernel, the following vulnerability has been resolved:
fs/buffer: fix use-after-free when call bh_read() helper
There's issue as follows: BUG: KASAN: stack-out-of-bounds in end_buffer_read_sync+0xe3/0x110 Read of size 8 at addr ffffc9000168f7f8 by task swapper/3/0 CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.16.0-862.14.0.6.x86_64 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <IRQ> dump_stack_lvl+0x55/0x70 print_address_description.constprop.0+0x2c/0x390 print_report+0xb4/0x270 kasan_report+0xb8/0xf0 end_buffer_read_sync+0xe3/0x110 end_bio_bh_io_sync+0x56/0x80 blk_update_request+0x30a/0x720 scsi_end_request+0x51/0x2b0 scsi_io_completion+0xe3/0x480 ? scsi_device_unbusy+0x11e/0x160 blk_complete_reqs+0x7b/0x90 handle_softirqs+0xef/0x370 irq_exit_rcu+0xa5/0xd0 sysvec_apic_timer_interrupt+0x6e/0x90 </IRQ>
Above issue happens when do ntfs3 filesystem mount, issue may happens as follows: mount IRQ ntfs_fill_super read_cache_page do_read_cache_folio filemap_read_folio mpage_read_folio do_mpage_readpage ntfs_get_block_vbo bh_read submit_bh wait_on_buffer(bh); blk_complete_reqs scsi_io_completion scsi_end_request blk_update_request end_bio_bh_io_sync end_buffer_read_sync __end_buffer_read_notouch unlock_buffer
wait_on_buffer(bh);--> return will return to caller
put_bh
--> trigger stack-out-of-bounds
In the mpage_read_folio() function, the stack variable 'map_bh' is passed to ntfs_get_block_vbo(). Once unlock_buffer() unlocks and wait_on_buffer() returns to continue processing, the stack variable is likely to be reclaimed. Consequently, during the end_buffer_read_sync() process, calling put_bh() may result in stack overrun.
If the bh is not allocated on the stack, it belongs to a folio. Freeing a buffer head which belongs to a folio is done by drop_buffers() which will fail to free buffers which are still locked. So it is safe to call put_bh() before __end_buffer_read_notouch().(CVE-2025-39691)
In the Linux kernel, the following vulnerability has been resolved:
soc: qcom: mdt_loader: Ensure we don't read past the ELF header
When the MDT loader is used in remoteproc, the ELF header is sanitized beforehand, but that's not necessary the case for other clients.
Validate the size of the firmware buffer to ensure that we don't read past the end as we iterate over the header. e_phentsize and e_shentsize are validated as well, to ensure that the assumptions about step size in the traversal are valid.(CVE-2025-39787)
In the Linux kernel, the following vulnerability has been resolved:
block: avoid possible overflow for chunk_sectors check in blk_stack_limits()
In blk_stack_limits(), we check that the t->chunk_sectors value is a multiple of the t->physical_block_size value.
However, by finding the chunk_sectors value in bytes, we may overflow the unsigned int which holds chunk_sectors, so change the check to be based on sectors.(CVE-2025-39795)
In the Linux kernel, the following vulnerability has been resolved:
pcmcia: Add error handling for add_interval() in do_validate_mem()
In the do_validate_mem(), the call to add_interval() does not handle errors. If kmalloc() fails in add_interval(), it could result in a null pointer being inserted into the linked list, leading to illegal memory access when sub_interval() is called next.
This patch adds an error handling for the add_interval(). If add_interval() returns an error, the function will return early with the error code.(CVE-2025-39920)
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: qcom: bam_dma: Fix DT error handling for num-channels/ees
When we don't have a clock specified in the device tree, we have no way to ensure the BAM is on. This is often the case for remotely-controlled or remotely-powered BAM instances. In this case, we need to read num-channels from the DT to have all the necessary information to complete probing.
However, at the moment invalid device trees without clock and without num-channels still continue probing, because the error handling is missing return statements. The driver will then later try to read the number of channels from the registers. This is unsafe, because it relies on boot firmware and lucky timing to succeed. Unfortunately, the lack of proper error handling here has been abused for several Qualcomm SoCs upstream, causing early boot crashes in several situations [1, 2].
Avoid these early crashes by erroring out when any of the required DT properties are missing. Note that this will break some of the existing DTs upstream (mainly BAM instances related to the crypto engine). However, clearly these DTs have never been tested properly, since the error in the kernel log was just ignored. It's safer to disable the crypto engine for these broken DTBs.
In the Linux kernel i40e driver, there is a security vulnerability: the driver lacks boundary checks for the maximum number of virtual function (VF) filters. An attacker could potentially exploit this vulnerability to request filter counts beyond the boundaries, leading to potential security issues.(CVE-2025-39968)
In the Linux kernel, the following vulnerability has been resolved: i40e: fix idx validation in config queues msg. Ensure idx is within range of active/initialized TCs when iterating over vf->ch[idx] in i40e_vc_config_queues_msg().(CVE-2025-39971)
In the Linux kernel, the following vulnerability has been resolved:
x86/mce: use is_copy_from_user() to determine copy-from-user context
Patch series "mm/hwpoison: Fix regressions in memory failure handling", v4.
1. What am I trying to do:
This patchset resolves two critical regressions related to memory failure handling that have appeared in the upstream kernel since version 5.17, as compared to 5.10 LTS.
- copyin case: poison found in user page while kernel copying from user space
- instr case: poison found while instruction fetching in user space
2. What is the expected outcome and why
- For copyin case:
Kernel can recover from poison found where kernel is doing get_user() or copy_from_user() if those places get an error return and the kernel return -EFAULT to the process instead of crashing. More specifily, MCE handler checks the fixup handler type to decide whether an in kernel #MC can be recovered. When EX_TYPE_UACCESS is found, the PC jumps to recovery code specified in _ASM_EXTABLE_FAULT() and return a -EFAULT to user space.
- For instr case:
If a poison found while instruction fetching in user space, full recovery is possible. User process takes #PF, Linux allocates a new page and fills by reading from storage.
3. What actually happens and why
- For copyin case: kernel panic since v5.17
Commit 4c132d1d844a ("x86/futex: Remove .fixup usage") introduced a new extable fixup type, EX_TYPE_EFAULT_REG, and later patches updated the extable fixup type for copy-from-user operations, changing it from EX_TYPE_UACCESS to EX_TYPE_EFAULT_REG. It breaks previous EX_TYPE_UACCESS handling when posion found in get_user() or copy_from_user().
- For instr case: user process is killed by a SIGBUS signal due to #CMCI and #MCE race
When an uncorrected memory error is consumed there is a race between the CMCI from the memory controller reporting an uncorrected error with a UCNA signature, and the core reporting and SRAR signature machine check when the data is about to be consumed.
Background: why UNcorrected errors tied to CMCI in Intel platform 1
Prior to Icelake memory controllers reported patrol scrub events that detected a previously unseen uncorrected error in memory by signaling a broadcast machine check with an SRAO (Software Recoverable Action Optional) signature in the machine check bank. This was overkill because it's not an urgent problem that no core is on the verge of consuming that bad data. It's also found that multi SRAO UCE may cause nested MCE interrupts and finally become an IERR.
Hence, Intel downgrades the machine check bank signature of patrol scrub from SRAO to UCNA (Uncorrected, No Action required), and signal changed to
CMCI. Just to add to the confusion, Linux does take an action (in
uc_decode_notifier()) to try to offline the page despite the UCNA signature name.
Background: why #CMCI and #MCE race when poison is consuming in
Intel platform [1]
Having decided that CMCI/UCNA is the best action for patrol scrub errors, the memory controller uses it for reads too. But the memory controller is executing asynchronously from the core, and can't tell the difference between a "real" read and a speculative read. So it will do CMCI/UCNA if an error is found in any read.
Thus:
1) Core is clever and thinks address A is needed soon, issues a speculative read.
2) Core finds it is going to use address A soon after sending the read request
3) The CMCI from the memory controller is in a race with MCE from the core that will soon try to retire the load from address A.
Quite often (because speculation has got better) the CMCI from the memory controller is delivered before the core is committed to the instruction reading address A, so the interrupt is taken, and Linux offlines the page (marking it as poison).
Why user process is killed for instr case
Commit 046545a661af ("mm/hwpoison: fix error page recovered but reported "not ---truncated---(CVE-2025-39989)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-113.0.0.117.oe2403sp1.aarch64.rpm",
"bpftool-debuginfo-6.6.0-113.0.0.117.oe2403sp1.aarch64.rpm",
"kernel-6.6.0-113.0.0.117.oe2403sp1.aarch64.rpm",
"kernel-debuginfo-6.6.0-113.0.0.117.oe2403sp1.aarch64.rpm",
"kernel-debugsource-6.6.0-113.0.0.117.oe2403sp1.aarch64.rpm",
"kernel-devel-6.6.0-113.0.0.117.oe2403sp1.aarch64.rpm",
"kernel-headers-6.6.0-113.0.0.117.oe2403sp1.aarch64.rpm",
"kernel-source-6.6.0-113.0.0.117.oe2403sp1.aarch64.rpm",
"kernel-tools-6.6.0-113.0.0.117.oe2403sp1.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-113.0.0.117.oe2403sp1.aarch64.rpm",
"kernel-tools-devel-6.6.0-113.0.0.117.oe2403sp1.aarch64.rpm",
"perf-6.6.0-113.0.0.117.oe2403sp1.aarch64.rpm",
"perf-debuginfo-6.6.0-113.0.0.117.oe2403sp1.aarch64.rpm",
"python3-perf-6.6.0-113.0.0.117.oe2403sp1.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-113.0.0.117.oe2403sp1.aarch64.rpm"
],
"src": [
"kernel-6.6.0-113.0.0.117.oe2403sp1.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-113.0.0.117.oe2403sp1.x86_64.rpm",
"bpftool-debuginfo-6.6.0-113.0.0.117.oe2403sp1.x86_64.rpm",
"kernel-6.6.0-113.0.0.117.oe2403sp1.x86_64.rpm",
"kernel-debuginfo-6.6.0-113.0.0.117.oe2403sp1.x86_64.rpm",
"kernel-debugsource-6.6.0-113.0.0.117.oe2403sp1.x86_64.rpm",
"kernel-devel-6.6.0-113.0.0.117.oe2403sp1.x86_64.rpm",
"kernel-headers-6.6.0-113.0.0.117.oe2403sp1.x86_64.rpm",
"kernel-source-6.6.0-113.0.0.117.oe2403sp1.x86_64.rpm",
"kernel-tools-6.6.0-113.0.0.117.oe2403sp1.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-113.0.0.117.oe2403sp1.x86_64.rpm",
"kernel-tools-devel-6.6.0-113.0.0.117.oe2403sp1.x86_64.rpm",
"perf-6.6.0-113.0.0.117.oe2403sp1.x86_64.rpm",
"perf-debuginfo-6.6.0-113.0.0.117.oe2403sp1.x86_64.rpm",
"python3-perf-6.6.0-113.0.0.117.oe2403sp1.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-113.0.0.117.oe2403sp1.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS-SP1",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP1"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-113.0.0.117.oe2403sp1"
}
],
"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: 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\nusb: renesas_usbhs: Flush the notify_hotplug_work\n\nWhen performing continuous unbind/bind operations on the USB drivers\navailable on the Renesas RZ/G2L SoC, a kernel crash with the message\n\u0026quot;Unable to handle kernel NULL pointer dereference at virtual address\u0026quot;\nmay occur. This issue points to the usbhsc_notify_hotplug() function.\n\nFlush the delayed work to avoid its execution when driver resources are\nunavailable.(CVE-2025-21917)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: btrtl: Prevent potential NULL dereference\n\nThe btrtl_initialize() function checks that rtl_load_file() either\nhad an error or it loaded a zero length file. However, if it loaded\na zero length file then the error code is not set correctly. It\nresults in an error pointer vs NULL bug, followed by a NULL pointer\ndereference. This was detected by Smatch:\n\ndrivers/bluetooth/btrtl.c:592 btrtl_initialize() warn: passing zero to \u0026apos;ERR_PTR\u0026apos;(CVE-2025-37792)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: ets: Fix double list add in class with netem as child qdisc\n\nAs described in Gerrard\u0026apos;s report [1], there are use cases where a netem\nchild qdisc will make the parent qdisc\u0026apos;s enqueue callback reentrant.\nIn the case of ets, there won\u0026apos;t be a UAF, but the code will add the same\nclassifier to the list twice, which will cause memory corruption.\n\nIn addition to checking for qlen being zero, this patch checks whether\nthe class was already added to the active_list (cl_is_active) before\ndoing the addition to cater for the reentrant case.\n\n[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/(CVE-2025-37914)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: adjust subpage bit start based on sectorsize\n\nWhen running machines with 64k page size and a 16k nodesize we started\nseeing tree log corruption in production. This turned out to be because\nwe were not writing out dirty blocks sometimes, so this in fact affects\nall metadata writes.\n\nWhen writing out a subpage EB we scan the subpage bitmap for a dirty\nrange. If the range isn\u0026apos;t dirty we do\n\n\tbit_start++;\n\nto move onto the next bit. The problem is the bitmap is based on the\nnumber of sectors that an EB has. So in this case, we have a 64k\npagesize, 16k nodesize, but a 4k sectorsize. This means our bitmap is 4\nbits for every node. With a 64k page size we end up with 4 nodes per\npage.\n\nTo make this easier this is how everything looks\n\n[0 16k 32k 48k ] logical address\n[0 4 8 12 ] radix tree offset\n[ 64k page ] folio\n[ 16k eb ][ 16k eb ][ 16k eb ][ 16k eb ] extent buffers\n[ | | | | | | | | | | | | | | | | ] bitmap\n\nNow we use all of our addressing based on fs_info-\u0026gt;sectorsize_bits, so\nas you can see the above our 16k eb-\u0026gt;start turns into radix entry 4.\n\nWhen we find a dirty range for our eb, we correctly do bit_start +=\nsectors_per_node, because if we start at bit 0, the next bit for the\nnext eb is 4, to correspond to eb-\u0026gt;start 16k.\n\nHowever if our range is clean, we will do bit_start++, which will now\nput us offset from our radix tree entries.\n\nIn our case, assume that the first time we check the bitmap the block is\nnot dirty, we increment bit_start so now it == 1, and then we loop\naround and check again. This time it is dirty, and we go to find that\nstart using the following equation\n\n\tstart = folio_start + bit_start * fs_info-\u0026gt;sectorsize;\n\nso in the case above, eb-\u0026gt;start 0 is now dirty, and we calculate start\nas\n\n\t0 + 1 * fs_info-\u0026gt;sectorsize = 4096\n\t4096 \u0026gt;\u0026gt; 12 = 1\n\nNow we\u0026apos;re looking up the radix tree for 1, and we won\u0026apos;t find an eb.\nWhat\u0026apos;s worse is now we\u0026apos;re using bit_start == 1, so we do bit_start +=\nsectors_per_node, which is now 5. If that eb is dirty we will run into\nthe same thing, we will look at an offset that is not populated in the\nradix tree, and now we\u0026apos;re skipping the writeout of dirty extent buffers.\n\nThe best fix for this is to not use sectorsize_bits to address nodes,\nbut that\u0026apos;s a larger change. Since this is a fs corruption problem fix\nit simply by always using sectors_per_node to increment the start bit.(CVE-2025-37931)\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\nf2fs: fix to bail out in get_new_segment()\n\n------------[ cut here ]------------\nWARNING: CPU: 3 PID: 579 at fs/f2fs/segment.c:2832 new_curseg+0x5e8/0x6dc\npc : new_curseg+0x5e8/0x6dc\nCall trace:\n new_curseg+0x5e8/0x6dc\n f2fs_allocate_data_block+0xa54/0xe28\n do_write_page+0x6c/0x194\n f2fs_do_write_node_page+0x38/0x78\n __write_node_page+0x248/0x6d4\n f2fs_sync_node_pages+0x524/0x72c\n f2fs_write_checkpoint+0x4bc/0x9b0\n __checkpoint_and_complete_reqs+0x80/0x244\n issue_checkpoint_thread+0x8c/0xec\n kthread+0x114/0x1bc\n ret_from_fork+0x10/0x20\n\nget_new_segment() detects inconsistent status in between free_segmap\nand free_secmap, let\u0026apos;s record such error into super block, and bail\nout get_new_segment() instead of continue using the segment.(CVE-2025-38333)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath12k: fix GCC_GCC_PCIE_HOT_RST definition for WCN7850\n\nGCC_GCC_PCIE_HOT_RST is wrongly defined for WCN7850, causing kernel crash\non some specific platforms.\n\nSince this register is divergent for WCN7850 and QCN9274, move it to\nregister table to allow different definitions. Then correct the register\naddress for WCN7850 to fix this issue.\n\nNote IPQ5332 is not affected as it is not PCIe based device.\n\nTested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3(CVE-2025-38414)\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\nscsi: libiscsi: Initialize iscsi_conn-\u0026gt;dd_data only if memory is allocated\n\nIn case of an ib_fast_reg_mr allocation failure during iSER setup, the\nmachine hits a panic because iscsi_conn-\u0026gt;dd_data is initialized\nunconditionally, even when no memory is allocated (dd_size == 0). This\nleads invalid pointer dereference during connection teardown.\n\nFix by setting iscsi_conn-\u0026gt;dd_data only if memory is actually allocated.\n\nPanic trace:\n------------\n iser: iser_create_fastreg_desc: Failed to allocate ib_fast_reg_mr err=-12\n iser: iser_alloc_rx_descriptors: failed allocating rx descriptors / data buffers\n BUG: unable to handle page fault for address: fffffffffffffff8\n RIP: 0010:swake_up_locked.part.5+0xa/0x40\n Call Trace:\n complete+0x31/0x40\n iscsi_iser_conn_stop+0x88/0xb0 [ib_iser]\n iscsi_stop_conn+0x66/0xc0 [scsi_transport_iscsi]\n iscsi_if_stop_conn+0x14a/0x150 [scsi_transport_iscsi]\n iscsi_if_rx+0x1135/0x1834 [scsi_transport_iscsi]\n ? netlink_lookup+0x12f/0x1b0\n ? netlink_deliver_tap+0x2c/0x200\n netlink_unicast+0x1ab/0x280\n netlink_sendmsg+0x257/0x4f0\n ? _copy_from_user+0x29/0x60\n sock_sendmsg+0x5f/0x70(CVE-2025-38700)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: do not BUG when INLINE_DATA_FL lacks system.data xattr\n\nA syzbot fuzzed image triggered a BUG_ON in ext4_update_inline_data()\nwhen an inode had the INLINE_DATA_FL flag set but was missing the\nsystem.data extended attribute.\n\nSince this can happen due to a maiciouly fuzzed file system, we\nshouldn\u0026apos;t BUG, but rather, report it as a corrupted file system.\n\nAdd similar replacements of BUG_ON with EXT4_ERROR_INODE() ii\next4_create_inline_data() and ext4_inline_data_truncate().(CVE-2025-38701)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nloop: Avoid updating block size under exclusive owner\n\nSyzbot came up with a reproducer where a loop device block size is\nchanged underneath a mounted filesystem. This causes a mismatch between\nthe block device block size and the block size stored in the superblock\ncausing confusion in various places such as fs/buffer.c. The particular\nissue triggered by syzbot was a warning in __getblk_slow() due to\nrequested buffer size not matching block device block size.\n\nFix the problem by getting exclusive hold of the loop device to change\nits block size. This fails if somebody (such as filesystem) has already\nan exclusive ownership of the block device and thus prevents modifying\nthe loop device under some exclusive owner which doesn\u0026apos;t expect it.(CVE-2025-38709)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/buffer: fix use-after-free when call bh_read() helper\n\nThere\u0026apos;s issue as follows:\nBUG: KASAN: stack-out-of-bounds in end_buffer_read_sync+0xe3/0x110\nRead of size 8 at addr ffffc9000168f7f8 by task swapper/3/0\nCPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.16.0-862.14.0.6.x86_64\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996)\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n dump_stack_lvl+0x55/0x70\n print_address_description.constprop.0+0x2c/0x390\n print_report+0xb4/0x270\n kasan_report+0xb8/0xf0\n end_buffer_read_sync+0xe3/0x110\n end_bio_bh_io_sync+0x56/0x80\n blk_update_request+0x30a/0x720\n scsi_end_request+0x51/0x2b0\n scsi_io_completion+0xe3/0x480\n ? scsi_device_unbusy+0x11e/0x160\n blk_complete_reqs+0x7b/0x90\n handle_softirqs+0xef/0x370\n irq_exit_rcu+0xa5/0xd0\n sysvec_apic_timer_interrupt+0x6e/0x90\n \u0026lt;/IRQ\u0026gt;\n\n Above issue happens when do ntfs3 filesystem mount, issue may happens\n as follows:\n mount IRQ\nntfs_fill_super\n read_cache_page\n do_read_cache_folio\n filemap_read_folio\n mpage_read_folio\n\t do_mpage_readpage\n\t ntfs_get_block_vbo\n\t bh_read\n\t submit_bh\n\t wait_on_buffer(bh);\n\t blk_complete_reqs\n\t\t\t\t scsi_io_completion\n\t\t\t\t scsi_end_request\n\t\t\t\t blk_update_request\n\t\t\t\t end_bio_bh_io_sync\n\t\t\t\t\t end_buffer_read_sync\n\t\t\t\t\t __end_buffer_read_notouch\n\t\t\t\t\t unlock_buffer\n\n wait_on_buffer(bh);--\u0026gt; return will return to caller\n\n\t\t\t\t\t put_bh\n\t\t\t\t\t --\u0026gt; trigger stack-out-of-bounds\nIn the mpage_read_folio() function, the stack variable \u0026apos;map_bh\u0026apos; is\npassed to ntfs_get_block_vbo(). Once unlock_buffer() unlocks and\nwait_on_buffer() returns to continue processing, the stack variable\nis likely to be reclaimed. Consequently, during the end_buffer_read_sync()\nprocess, calling put_bh() may result in stack overrun.\n\nIf the bh is not allocated on the stack, it belongs to a folio. Freeing\na buffer head which belongs to a folio is done by drop_buffers() which\nwill fail to free buffers which are still locked. So it is safe to call\nput_bh() before __end_buffer_read_notouch().(CVE-2025-39691)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsoc: qcom: mdt_loader: Ensure we don\u0026apos;t read past the ELF header\n\nWhen the MDT loader is used in remoteproc, the ELF header is sanitized\nbeforehand, but that\u0026apos;s not necessary the case for other clients.\n\nValidate the size of the firmware buffer to ensure that we don\u0026apos;t read\npast the end as we iterate over the header. e_phentsize and e_shentsize\nare validated as well, to ensure that the assumptions about step size in\nthe traversal are valid.(CVE-2025-39787)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblock: avoid possible overflow for chunk_sectors check in blk_stack_limits()\n\nIn blk_stack_limits(), we check that the t-\u0026gt;chunk_sectors value is a\nmultiple of the t-\u0026gt;physical_block_size value.\n\nHowever, by finding the chunk_sectors value in bytes, we may overflow\nthe unsigned int which holds chunk_sectors, so change the check to be\nbased on sectors.(CVE-2025-39795)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npcmcia: Add error handling for add_interval() in do_validate_mem()\n\nIn the do_validate_mem(), the call to add_interval() does not\nhandle errors. If kmalloc() fails in add_interval(), it could\nresult in a null pointer being inserted into the linked list,\nleading to illegal memory access when sub_interval() is called\nnext.\n\nThis patch adds an error handling for the add_interval(). If\nadd_interval() returns an error, the function will return early\nwith the error code.(CVE-2025-39920)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: qcom: bam_dma: Fix DT error handling for num-channels/ees\n\nWhen we don\u0026apos;t have a clock specified in the device tree, we have no way to\nensure the BAM is on. This is often the case for remotely-controlled or\nremotely-powered BAM instances. In this case, we need to read num-channels\nfrom the DT to have all the necessary information to complete probing.\n\nHowever, at the moment invalid device trees without clock and without\nnum-channels still continue probing, because the error handling is missing\nreturn statements. The driver will then later try to read the number of\nchannels from the registers. This is unsafe, because it relies on boot\nfirmware and lucky timing to succeed. Unfortunately, the lack of proper\nerror handling here has been abused for several Qualcomm SoCs upstream,\ncausing early boot crashes in several situations [1, 2].\n\nAvoid these early crashes by erroring out when any of the required DT\nproperties are missing. Note that this will break some of the existing DTs\nupstream (mainly BAM instances related to the crypto engine). However,\nclearly these DTs have never been tested properly, since the error in the\nkernel log was just ignored. It\u0026apos;s safer to disable the crypto engine for\nthese broken DTBs.\n\n[1]: https://lore.kernel.org/r/(CVE-2025-39923)\n\nIn the Linux kernel i40e driver, there is a security vulnerability: the driver lacks boundary checks for the maximum number of virtual function (VF) filters. An attacker could potentially exploit this vulnerability to request filter counts beyond the boundaries, leading to potential security issues.(CVE-2025-39968)\n\nIn the Linux kernel, the following vulnerability has been resolved: i40e: fix idx validation in config queues msg. Ensure idx is within range of active/initialized TCs when iterating over vf-\u0026gt;ch[idx] in i40e_vc_config_queues_msg().(CVE-2025-39971)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/mce: use is_copy_from_user() to determine copy-from-user context\n\nPatch series \u0026quot;mm/hwpoison: Fix regressions in memory failure handling\u0026quot;,\nv4.\n\n## 1. What am I trying to do:\n\nThis patchset resolves two critical regressions related to memory failure\nhandling that have appeared in the upstream kernel since version 5.17, as\ncompared to 5.10 LTS.\n\n - copyin case: poison found in user page while kernel copying from user space\n - instr case: poison found while instruction fetching in user space\n\n## 2. What is the expected outcome and why\n\n- For copyin case:\n\nKernel can recover from poison found where kernel is doing get_user() or\ncopy_from_user() if those places get an error return and the kernel return\n-EFAULT to the process instead of crashing. More specifily, MCE handler\nchecks the fixup handler type to decide whether an in kernel #MC can be\nrecovered. When EX_TYPE_UACCESS is found, the PC jumps to recovery code\nspecified in _ASM_EXTABLE_FAULT() and return a -EFAULT to user space.\n\n- For instr case:\n\nIf a poison found while instruction fetching in user space, full recovery\nis possible. User process takes #PF, Linux allocates a new page and fills\nby reading from storage.\n\n\n## 3. What actually happens and why\n\n- For copyin case: kernel panic since v5.17\n\nCommit 4c132d1d844a (\u0026quot;x86/futex: Remove .fixup usage\u0026quot;) introduced a new\nextable fixup type, EX_TYPE_EFAULT_REG, and later patches updated the\nextable fixup type for copy-from-user operations, changing it from\nEX_TYPE_UACCESS to EX_TYPE_EFAULT_REG. It breaks previous EX_TYPE_UACCESS\nhandling when posion found in get_user() or copy_from_user().\n\n- For instr case: user process is killed by a SIGBUS signal due to #CMCI\n and #MCE race\n\nWhen an uncorrected memory error is consumed there is a race between the\nCMCI from the memory controller reporting an uncorrected error with a UCNA\nsignature, and the core reporting and SRAR signature machine check when\nthe data is about to be consumed.\n\n### Background: why *UN*corrected errors tied to *C*MCI in Intel platform [1]\n\nPrior to Icelake memory controllers reported patrol scrub events that\ndetected a previously unseen uncorrected error in memory by signaling a\nbroadcast machine check with an SRAO (Software Recoverable Action\nOptional) signature in the machine check bank. This was overkill because\nit\u0026apos;s not an urgent problem that no core is on the verge of consuming that\nbad data. It\u0026apos;s also found that multi SRAO UCE may cause nested MCE\ninterrupts and finally become an IERR.\n\nHence, Intel downgrades the machine check bank signature of patrol scrub\nfrom SRAO to UCNA (Uncorrected, No Action required), and signal changed to\n#CMCI. Just to add to the confusion, Linux does take an action (in\nuc_decode_notifier()) to try to offline the page despite the UC*NA*\nsignature name.\n\n### Background: why #CMCI and #MCE race when poison is consuming in\n Intel platform [1]\n\nHaving decided that CMCI/UCNA is the best action for patrol scrub errors,\nthe memory controller uses it for reads too. But the memory controller is\nexecuting asynchronously from the core, and can\u0026apos;t tell the difference\nbetween a \u0026quot;real\u0026quot; read and a speculative read. So it will do CMCI/UCNA if\nan error is found in any read.\n\nThus:\n\n1) Core is clever and thinks address A is needed soon, issues a\n speculative read.\n\n2) Core finds it is going to use address A soon after sending the read\n request\n\n3) The CMCI from the memory controller is in a race with MCE from the\n core that will soon try to retire the load from address A.\n\nQuite often (because speculation has got better) the CMCI from the memory\ncontroller is delivered before the core is committed to the instruction\nreading address A, so the interrupt is taken, and Linux offlines the page\n(marking it as poison).\n\n\n## Why user process is killed for instr case\n\nCommit 046545a661af (\u0026quot;mm/hwpoison: fix error page recovered but reported\n\u0026quot;not\n---truncated---(CVE-2025-39989)",
"id": "OESA-2025-2537",
"modified": "2026-08-06T11:09:37Z",
"published": "2025-10-24T11:09:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2537"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21801"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21917"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37792"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37914"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37931"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38313"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38333"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38414"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38615"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38700"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38701"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38709"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39691"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39787"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39795"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39920"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39923"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39968"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39971"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39989"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2025-21801",
"CVE-2025-21917",
"CVE-2025-37792",
"CVE-2025-37914",
"CVE-2025-37931",
"CVE-2025-38313",
"CVE-2025-38333",
"CVE-2025-38414",
"CVE-2025-38615",
"CVE-2025-38700",
"CVE-2025-38701",
"CVE-2025-38709",
"CVE-2025-39691",
"CVE-2025-39787",
"CVE-2025-39795",
"CVE-2025-39920",
"CVE-2025-39923",
"CVE-2025-39968",
"CVE-2025-39971",
"CVE-2025-39989"
]
}
OESA-2026-1275 (CVE-2022-49157)
Vulnerability from osv_openeuler – Published: 2026-01-30 11:10 – Updated: 2026-08-06 11:10 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix premature hw access after PCI error
After a recoverable PCI error has been detected and recovered, qla driver needs to check to see if the error condition still persist and/or wait for the OS to give the resume signal.
Sep 8 22:26:03 localhost kernel: WARNING: CPU: 9 PID: 124606 at qla_tmpl.c:440 qla27xx_fwdt_entry_t266+0x55/0x60 [qla2xxx] Sep 8 22:26:03 localhost kernel: RIP: 0010:qla27xx_fwdt_entry_t266+0x55/0x60 [qla2xxx] Sep 8 22:26:03 localhost kernel: Call Trace: Sep 8 22:26:03 localhost kernel: ? qla27xx_walk_template+0xb1/0x1b0 [qla2xxx] Sep 8 22:26:03 localhost kernel: ? qla27xx_execute_fwdt_template+0x12a/0x160 [qla2xxx] Sep 8 22:26:03 localhost kernel: ? qla27xx_fwdump+0xa0/0x1c0 [qla2xxx] Sep 8 22:26:03 localhost kernel: ? qla2xxx_pci_mmio_enabled+0xfb/0x120 [qla2xxx] Sep 8 22:26:03 localhost kernel: ? report_mmio_enabled+0x44/0x80 Sep 8 22:26:03 localhost kernel: ? report_slot_reset+0x80/0x80 Sep 8 22:26:03 localhost kernel: ? pci_walk_bus+0x70/0x90 Sep 8 22:26:03 localhost kernel: ? aer_dev_correctable_show+0xc0/0xc0 Sep 8 22:26:03 localhost kernel: ? pcie_do_recovery+0x1bb/0x240 Sep 8 22:26:03 localhost kernel: ? aer_recover_work_func+0xaa/0xd0 Sep 8 22:26:03 localhost kernel: ? process_one_work+0x1a7/0x360 .. Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-8041:22: detected PCI disconnect. Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-107ff:22: qla27xx_fwdt_entry_t262: dump ram MB failed. Area 5h start 198013h end 198013h Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-107ff:22: Unable to capture FW dump Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-1015:22: cmd=0x0, waited 5221 msecs Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-680d:22: mmio enabled returning. Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-d04c:22: MBX Command timeout for cmd 0, iocontrol=ffffffff jiffies=10140f2e5 mb[0-3]=0xffff 0xffff 0xffff 0xffff
In the Linux kernel, the following vulnerability has been resolved:
md/raid0, raid10: Don't set discard sectors for request queue
It should use disk_stack_limits to get a proper max_discard_sectors rather than setting a value by stack drivers.
And there is a bug. If all member disks are rotational devices, raid0/raid10 set max_discard_sectors. So the member devices are not ssd/nvme, but raid0/raid10 export the wrong value. It reports warning messages in function __blkdev_issue_discard when mkfs.xfs like this:
[ 4616.022599] ------------[ cut here ]------------ [ 4616.027779] WARNING: CPU: 4 PID: 99634 at block/blk-lib.c:50 __blkdev_issue_discard+0x16a/0x1a0 [ 4616.140663] RIP: 0010:__blkdev_issue_discard+0x16a/0x1a0 [ 4616.146601] Code: 24 4c 89 20 31 c0 e9 fe fe ff ff c1 e8 09 8d 48 ff 4c 89 f0 4c 09 e8 48 85 c1 0f 84 55 ff ff ff b8 ea ff ff ff e9 df fe ff ff <0f> 0b 48 8d 74 24 08 e8 ea d6 00 00 48 c7 c6 20 1e 89 ab 48 c7 c7 [ 4616.167567] RSP: 0018:ffffaab88cbffca8 EFLAGS: 00010246 [ 4616.173406] RAX: ffff9ba1f9e44678 RBX: 0000000000000000 RCX: ffff9ba1c9792080 [ 4616.181376] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9ba1c9792080 [ 4616.189345] RBP: 0000000000000cc0 R08: ffffaab88cbffd10 R09: 0000000000000000 [ 4616.197317] R10: 0000000000000012 R11: 0000000000000000 R12: 0000000000000000 [ 4616.205288] R13: 0000000000400000 R14: 0000000000000cc0 R15: ffff9ba1c9792080 [ 4616.213259] FS: 00007f9a5534e980(0000) GS:ffff9ba1b7c80000(0000) knlGS:0000000000000000 [ 4616.222298] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4616.228719] CR2: 000055a390a4c518 CR3: 0000000123e40006 CR4: 00000000001706e0 [ 4616.236689] Call Trace: [ 4616.239428] blkdev_issue_discard+0x52/0xb0 [ 4616.244108] blkdev_common_ioctl+0x43c/0xa00 [ 4616.248883] blkdev_ioctl+0x116/0x280 [ 4616.252977] __x64_sys_ioctl+0x8a/0xc0 [ 4616.257163] do_syscall_64+0x5c/0x90 [ 4616.261164] ? handle_mm_fault+0xc5/0x2a0 [ 4616.265652] ? do_user_addr_fault+0x1d8/0x690 [ 4616.270527] ? do_syscall_64+0x69/0x90 [ 4616.274717] ? exc_page_fault+0x62/0x150 [ 4616.279097] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 4616.284748] RIP: 0033:0x7f9a55398c6b(CVE-2022-50583)
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Validate index root when initialize NTFS security
This enhances the sanity check for $SDH and $SII while initializing NTFS security, guarantees these index root are legit.
[ 162.459513] BUG: KASAN: use-after-free in hdr_find_e.isra.0+0x10c/0x320 [ 162.460176] Read of size 2 at addr ffff8880037bca99 by task mount/243 [ 162.460851] [ 162.461252] CPU: 0 PID: 243 Comm: mount Not tainted 6.0.0-rc7 #42 [ 162.461744] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 162.462609] Call Trace: [ 162.462954] <TASK> [ 162.463276] dump_stack_lvl+0x49/0x63 [ 162.463822] print_report.cold+0xf5/0x689 [ 162.464608] ? unwind_get_return_address+0x3a/0x60 [ 162.465766] ? hdr_find_e.isra.0+0x10c/0x320 [ 162.466975] kasan_report+0xa7/0x130 [ 162.467506] ? _raw_spin_lock_irq+0xc0/0xf0 [ 162.467998] ? hdr_find_e.isra.0+0x10c/0x320 [ 162.468536] __asan_load2+0x68/0x90 [ 162.468923] hdr_find_e.isra.0+0x10c/0x320 [ 162.469282] ? cmp_uints+0xe0/0xe0 [ 162.469557] ? cmp_sdh+0x90/0x90 [ 162.469864] ? ni_find_attr+0x214/0x300 [ 162.470217] ? ni_load_mi+0x80/0x80 [ 162.470479] ? entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 162.470931] ? ntfs_bread_run+0x190/0x190 [ 162.471307] ? indx_get_root+0xe4/0x190 [ 162.471556] ? indx_get_root+0x140/0x190 [ 162.471833] ? indx_init+0x1e0/0x1e0 [ 162.472069] ? fnd_clear+0x115/0x140 [ 162.472363] ? _raw_spin_lock_irqsave+0x100/0x100 [ 162.472731] indx_find+0x184/0x470 [ 162.473461] ? sysvec_apic_timer_interrupt+0x57/0xc0 [ 162.474429] ? indx_find_buffer+0x2d0/0x2d0 [ 162.474704] ? do_syscall_64+0x3b/0x90 [ 162.474962] dir_search_u+0x196/0x2f0 [ 162.475381] ? ntfs_nls_to_utf16+0x450/0x450 [ 162.475661] ? ntfs_security_init+0x3d6/0x440 [ 162.475906] ? is_sd_valid+0x180/0x180 [ 162.476191] ntfs_extend_init+0x13f/0x2c0 [ 162.476496] ? ntfs_fix_post_read+0x130/0x130 [ 162.476861] ? iput.part.0+0x286/0x320 [ 162.477325] ntfs_fill_super+0x11e0/0x1b50 [ 162.477709] ? put_ntfs+0x1d0/0x1d0 [ 162.477970] ? vsprintf+0x20/0x20 [ 162.478258] ? set_blocksize+0x95/0x150 [ 162.478538] get_tree_bdev+0x232/0x370 [ 162.478789] ? put_ntfs+0x1d0/0x1d0 [ 162.479038] ntfs_fs_get_tree+0x15/0x20 [ 162.479374] vfs_get_tree+0x4c/0x130 [ 162.479729] path_mount+0x654/0xfe0 [ 162.480124] ? putname+0x80/0xa0 [ 162.480484] ? finish_automount+0x2e0/0x2e0 [ 162.480894] ? putname+0x80/0xa0 [ 162.481467] ? kmem_cache_free+0x1c4/0x440 [ 162.482280] ? putname+0x80/0xa0 [ 162.482714] do_mount+0xd6/0xf0 [ 162.483264] ? path_mount+0xfe0/0xfe0 [ 162.484782] ? __kasan_check_write+0x14/0x20 [ 162.485593] __x64_sys_mount+0xca/0x110 [ 162.486024] do_syscall_64+0x3b/0x90 [ 162.486543] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 162.487141] RIP: 0033:0x7f9d374e948a [ 162.488324] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008 [ 162.489728] RSP: 002b:00007ffe30e73d18 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5 [ 162.490971] RAX: ffffffffffffffda RBX: 0000561cdb43a060 RCX: 00007f9d374e948a [ 162.491669] RDX: 0000561cdb43a260 RSI: 0000561cdb43a2e0 RDI: 0000561cdb442af0 [ 162.492050] RBP: 0000000000000000 R08: 0000561cdb43a280 R09: 0000000000000020 [ 162.492459] R10: 00000000c0ed0000 R11: 0000000000000206 R12: 0000561cdb442af0 [ 162.493183] R13: 0000561cdb43a260 R14: 0000000000000000 R15: 00000000ffffffff [ 162.493644] </TASK> [ 162.493908] [ 162.494214] The buggy address belongs to the physical page: [ 162.494761] page:000000003e38a3d5 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x37bc [ 162.496064] flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) [ 162.497278] raw: 000fffffc0000000 ffffea00000df1c8 ffffea00000df008 0000000000000000 [ 162.498928] raw: 0000000000000000 0000000000240000 0 ---truncated---(CVE-2022-50737)
In the Linux kernel, the following vulnerability has been resolved:
NFSD: Avoid calling OPDESC() with ops->opnum == OP_ILLEGAL
OPDESC() simply indexes into nfsd4_ops[] by the op's operation number, without range checking that value. It assumes callers are careful to avoid calling it with an out-of-bounds opnum value.
nfsd4_decode_compound() is not so careful, and can invoke OPDESC() with opnum set to OP_ILLEGAL, which is 10044 -- well beyond the end of nfsd4_ops[].(CVE-2023-53680)
In the Linux kernel, the following vulnerability has been resolved:
cifs: fix session state check in reconnect to avoid use-after-free issue
Don't collect exiting session in smb2_reconnect_server(), because it will be released soon.
Note that the exiting session will stay in server->smb_ses_list until it complete the cifs_free_ipc() and logoff() and then delete itself from the list.(CVE-2023-53794)
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau/kms/nv50-: init hpd_irq_lock for PIOR DP
Fixes OOPS on boards with ANX9805 DP encoders.(CVE-2023-54263)
In the Linux kernel, the following vulnerability has been resolved:
jfs: add sanity check for agwidth in dbMount
The width in dmapctl of the AG is zero, it trigger a divide error when calculating the control page level in dbAllocAG.
To avoid this issue, add a check for agwidth in dbAllocAG.(CVE-2025-37740)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: Prevent division by zero
The user can set any speed value. If speed is greater than UINT_MAX/8, division by zero is possible.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37768)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: Fix use-after-free in cifs_fill_dirent
There is a race condition in the readdir concurrency process, which may access the rsp buffer after it has been released, triggering the following KASAN warning.
================================================================== BUG: KASAN: slab-use-after-free in cifs_fill_dirent+0xb03/0xb60 [cifs] Read of size 4 at addr ffff8880099b819c by task a.out/342975
CPU: 2 UID: 0 PID: 342975 Comm: a.out Not tainted 6.15.0-rc6+ #240 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x53/0x70 print_report+0xce/0x640 kasan_report+0xb8/0xf0 cifs_fill_dirent+0xb03/0xb60 [cifs] cifs_readdir+0x12cb/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f996f64b9f9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0d f7 c3 0c 00 f7 d8 64 89 8 RSP: 002b:00007f996f53de78 EFLAGS: 00000207 ORIG_RAX: 000000000000004e RAX: ffffffffffffffda RBX: 00007f996f53ecdc RCX: 00007f996f64b9f9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007f996f53dea0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000207 R12: ffffffffffffff88 R13: 0000000000000000 R14: 00007ffc8cd9a500 R15: 00007f996f51e000 </TASK>
Allocated by task 408: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x6e/0x70 kmem_cache_alloc_noprof+0x117/0x3d0 mempool_alloc_noprof+0xf2/0x2c0 cifs_buf_get+0x36/0x80 [cifs] allocate_buffers+0x1d2/0x330 [cifs] cifs_demultiplex_thread+0x22b/0x2690 [cifs] kthread+0x394/0x720 ret_from_fork+0x34/0x70 ret_from_fork_asm+0x1a/0x30
Freed by task 342979: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x37/0x50 kmem_cache_free+0x2b8/0x500 cifs_buf_release+0x3c/0x70 [cifs] cifs_readdir+0x1c97/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents64+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e
The buggy address belongs to the object at ffff8880099b8000 which belongs to the cache cifs_request of size 16588 The buggy address is located 412 bytes inside of freed 16588-byte region [ffff8880099b8000, ffff8880099bc0cc)
The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x99b8 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 anon flags: 0x80000000000040(head|node=0|zone=1) page_type: f5(slab) raw: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 raw: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 head: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000003 ffffea0000266e01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008 page dumped because: kasan: bad access detected
Memory state around the buggy address: ffff8880099b8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8880099b8180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880099b8200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================
POC is available in the link [1].
The problem triggering process is as follows:
Process 1 Process 2
---truncated---(CVE-2025-38051)
In the Linux kernel, the following vulnerability has been resolved:
VMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify
During our test, it is found that a warning can be trigger in try_grab_folio as follow:
------------[ cut here ]------------ WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130 Modules linked in: CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef) RIP: 0010:try_grab_folio+0x106/0x130 Call Trace: <TASK> follow_huge_pmd+0x240/0x8e0 follow_pmd_mask.constprop.0.isra.0+0x40b/0x5c0 follow_pud_mask.constprop.0.isra.0+0x14a/0x170 follow_page_mask+0x1c2/0x1f0 __get_user_pages+0x176/0x950 __gup_longterm_locked+0x15b/0x1060 ? gup_fast+0x120/0x1f0 gup_fast_fallback+0x17e/0x230 get_user_pages_fast+0x5f/0x80 vmci_host_unlocked_ioctl+0x21c/0xf80 RIP: 0033:0x54d2cd ---[ end trace 0000000000000000 ]---
Digging into the source, context->notify_page may init by get_user_pages_fast and can be seen in vmci_ctx_unset_notify which will try to put_page. However get_user_pages_fast is not finished here and lead to following try_grab_folio warning. The race condition is shown as follow:
cpu0 cpu1 vmci_host_do_set_notify vmci_host_setup_notify get_user_pages_fast(uva, 1, FOLL_WRITE, &context->notify_page); lockless_pages_from_mm gup_pgd_range gup_huge_pmd // update &context->notify_page vmci_host_do_set_notify vmci_ctx_unset_notify notify_page = context->notify_page; if (notify_page) put_page(notify_page); // page is freed __gup_longterm_locked __get_user_pages follow_trans_huge_pmd try_grab_folio // warn here
To slove this, use local variable page to make notify_page can be seen after finish get_user_pages_fast.(CVE-2025-38102)
In the Linux kernel, the following vulnerability has been resolved:
HID: usbhid: Eliminate recurrent out-of-bounds bug in usbhid_parse()
Update struct hid_descriptor to better reflect the mandatory and optional parts of the HID Descriptor as per USB HID 1.11 specification. Note: the kernel currently does not parse any optional HID class descriptors, only the mandatory report descriptor.
Update all references to member element desc[0] to rpt_desc.
Add test to verify bLength and bNumDescriptors values are valid.
Replace the for loop with direct access to the mandatory HID class descriptor member for the report descriptor. This eliminates the possibility of getting an out-of-bounds fault.
Add a warning message if the HID descriptor contains any unsupported optional HID class descriptors.(CVE-2025-38103)
In the Linux kernel, the following vulnerability has been resolved:
net/mdiobus: Fix potential out-of-bounds read/write access
When using publicly available tools like 'mdio-tools' to read/write data from/to network interface and its PHY via mdiobus, there is no verification of parameters passed to the ioctl and it accepts any mdio address. Currently there is support for 32 addresses in kernel via PHY_MAX_ADDR define, but it is possible to pass higher value than that via ioctl. While read/write operation should generally fail in this case, mdiobus provides stats array, where wrong address may allow out-of-bounds read/write.
Fix that by adding address verification before read/write operation. While this excludes this access from any statistics, it improves security of read/write operation.(CVE-2025-38111)
In the Linux kernel, the following vulnerability has been resolved:
software node: Correct a OOB check in software_node_get_reference_args()
software_node_get_reference_args() wants to get @index-th element, so the property value requires at least '(index + 1) * sizeof(*ref)' bytes but that can not be guaranteed by current OOB check, and may cause OOB for malformed property.
Fix by using as OOB check '((index + 1) * sizeof(*ref) > prop->length)'.(CVE-2025-38342)
In the Linux kernel, the following vulnerability has been resolved:
jfs: upper bound check of tree index in dbAllocAG
When computing the tree index in dbAllocAG, we never check if we are out of bounds realative to the size of the stree. This could happen in a scenario where the filesystem metadata are corrupted.(CVE-2025-38697)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: fix null pointer access
Writing a string without delimiters (' ', '\n', '\0') to the under gpu_od/fan_ctrl sysfs or pp_power_profile_mode for the CUSTOM profile will result in a null pointer dereference.(CVE-2025-38705)
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: don't use BUG_ON() in hfsplus_create_attributes_file()
When the volume header contains erroneous values that do not reflect the actual state of the filesystem, hfsplus_fill_super() assumes that the attributes file is not yet created, which later results in hitting BUG_ON() when hfsplus_create_attributes_file() is called. Replace this BUG_ON() with -EIO error with a message to suggest running fsck tool.(CVE-2025-38712)
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()
The hfsplus_readdir() method is capable to crash by calling hfsplus_uni2asc():
[ 667.121659][ T9805] ================================================================== [ 667.122651][ T9805] BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0x902/0xa10 [ 667.123627][ T9805] Read of size 2 at addr ffff88802592f40c by task repro/9805 [ 667.124578][ T9805] [ 667.124876][ T9805] CPU: 3 UID: 0 PID: 9805 Comm: repro Not tainted 6.16.0-rc3 #1 PREEMPT(full) [ 667.124886][ T9805] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 667.124890][ T9805] Call Trace: [ 667.124893][ T9805] <TASK> [ 667.124896][ T9805] dump_stack_lvl+0x10e/0x1f0 [ 667.124911][ T9805] print_report+0xd0/0x660 [ 667.124920][ T9805] ? __virt_addr_valid+0x81/0x610 [ 667.124928][ T9805] ? __phys_addr+0xe8/0x180 [ 667.124934][ T9805] ? hfsplus_uni2asc+0x902/0xa10 [ 667.124942][ T9805] kasan_report+0xc6/0x100 [ 667.124950][ T9805] ? hfsplus_uni2asc+0x902/0xa10 [ 667.124959][ T9805] hfsplus_uni2asc+0x902/0xa10 [ 667.124966][ T9805] ? hfsplus_bnode_read+0x14b/0x360 [ 667.124974][ T9805] hfsplus_readdir+0x845/0xfc0 [ 667.124984][ T9805] ? __pfx_hfsplus_readdir+0x10/0x10 [ 667.124994][ T9805] ? stack_trace_save+0x8e/0xc0 [ 667.125008][ T9805] ? iterate_dir+0x18b/0xb20 [ 667.125015][ T9805] ? trace_lock_acquire+0x85/0xd0 [ 667.125022][ T9805] ? lock_acquire+0x30/0x80 [ 667.125029][ T9805] ? iterate_dir+0x18b/0xb20 [ 667.125037][ T9805] ? down_read_killable+0x1ed/0x4c0 [ 667.125044][ T9805] ? putname+0x154/0x1a0 [ 667.125051][ T9805] ? __pfx_down_read_killable+0x10/0x10 [ 667.125058][ T9805] ? apparmor_file_permission+0x239/0x3e0 [ 667.125069][ T9805] iterate_dir+0x296/0xb20 [ 667.125076][ T9805] __x64_sys_getdents64+0x13c/0x2c0 [ 667.125084][ T9805] ? __pfxx64sys_getdents64+0x10/0x10 [ 667.125091][ T9805] ? x64_sys_openat+0x141/0x200 [ 667.125126][ T9805] ? __pfx_filldir64+0x10/0x10 [ 667.125134][ T9805] ? do_user_addr_fault+0x7fe/0x12f0 [ 667.125143][ T9805] do_syscall_64+0xc9/0x480 [ 667.125151][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 667.125158][ T9805] RIP: 0033:0x7fa8753b2fc9 [ 667.125164][ T9805] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 48 [ 667.125172][ T9805] RSP: 002b:00007ffe96f8e0f8 EFLAGS: 00000217 ORIG_RAX: 00000000000000d9 [ 667.125181][ T9805] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa8753b2fc9 [ 667.125185][ T9805] RDX: 0000000000000400 RSI: 00002000000063c0 RDI: 0000000000000004 [ 667.125190][ T9805] RBP: 00007ffe96f8e110 R08: 00007ffe96f8e110 R09: 00007ffe96f8e110 [ 667.125195][ T9805] R10: 0000000000000000 R11: 0000000000000217 R12: 0000556b1e3b4260 [ 667.125199][ T9805] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 667.125207][ T9805] </TASK> [ 667.125210][ T9805] [ 667.145632][ T9805] Allocated by task 9805: [ 667.145991][ T9805] kasan_save_stack+0x20/0x40 [ 667.146352][ T9805] kasan_save_track+0x14/0x30 [ 667.146717][ T9805] __kasan_kmalloc+0xaa/0xb0 [ 667.147065][ T9805] __kmalloc_noprof+0x205/0x550 [ 667.147448][ T9805] hfsplus_find_init+0x95/0x1f0 [ 667.147813][ T9805] hfsplus_readdir+0x220/0xfc0 [ 667.148174][ T9805] iterate_dir+0x296/0xb20 [ 667.148549][ T9805] __x64_sys_getdents64+0x13c/0x2c0 [ 667.148937][ T9805] do_syscall_64+0xc9/0x480 [ 667.149291][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 667.149809][ T9805] [ 667.150030][ T9805] The buggy address belongs to the object at ffff88802592f000 [ 667.150030][ T9805] which belongs to the cache kmalloc-2k of size 2048 [ 667.151282][ T9805] The buggy address is located 0 bytes to the right of [ 667.151282][ T9805] allocated 1036-byte region [ffff88802592f000, ffff88802592f40c) [ 667.1 ---truncated---(CVE-2025-38713)
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: fix slab-out-of-bounds in hfsplus_bnode_read()
The hfsplus_bnode_read() method can trigger the issue:
[ 174.852007][ T9784] ================================================================== [ 174.852709][ T9784] BUG: KASAN: slab-out-of-bounds in hfsplus_bnode_read+0x2f4/0x360 [ 174.853412][ T9784] Read of size 8 at addr ffff88810b5fc6c0 by task repro/9784 [ 174.854059][ T9784] [ 174.854272][ T9784] CPU: 1 UID: 0 PID: 9784 Comm: repro Not tainted 6.16.0-rc3 #7 PREEMPT(full) [ 174.854281][ T9784] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 174.854286][ T9784] Call Trace: [ 174.854289][ T9784] <TASK> [ 174.854292][ T9784] dump_stack_lvl+0x10e/0x1f0 [ 174.854305][ T9784] print_report+0xd0/0x660 [ 174.854315][ T9784] ? __virt_addr_valid+0x81/0x610 [ 174.854323][ T9784] ? __phys_addr+0xe8/0x180 [ 174.854330][ T9784] ? hfsplus_bnode_read+0x2f4/0x360 [ 174.854337][ T9784] kasan_report+0xc6/0x100 [ 174.854346][ T9784] ? hfsplus_bnode_read+0x2f4/0x360 [ 174.854354][ T9784] hfsplus_bnode_read+0x2f4/0x360 [ 174.854362][ T9784] hfsplus_bnode_dump+0x2ec/0x380 [ 174.854370][ T9784] ? __pfx_hfsplus_bnode_dump+0x10/0x10 [ 174.854377][ T9784] ? hfsplus_bnode_write_u16+0x83/0xb0 [ 174.854385][ T9784] ? srcu_gp_start+0xd0/0x310 [ 174.854393][ T9784] ? __mark_inode_dirty+0x29e/0xe40 [ 174.854402][ T9784] hfsplus_brec_remove+0x3d2/0x4e0 [ 174.854411][ T9784] __hfsplus_delete_attr+0x290/0x3a0 [ 174.854419][ T9784] ? __pfx_hfs_find_1st_rec_by_cnid+0x10/0x10 [ 174.854427][ T9784] ? __pfxhfsplusdelete_attr+0x10/0x10 [ 174.854436][ T9784] ? asan_memset+0x23/0x50 [ 174.854450][ T9784] hfsplus_delete_all_attrs+0x262/0x320 [ 174.854459][ T9784] ? __pfx_hfsplus_delete_all_attrs+0x10/0x10 [ 174.854469][ T9784] ? rcu_is_watching+0x12/0xc0 [ 174.854476][ T9784] ? __mark_inode_dirty+0x29e/0xe40 [ 174.854483][ T9784] hfsplus_delete_cat+0x845/0xde0 [ 174.854493][ T9784] ? __pfx_hfsplus_delete_cat+0x10/0x10 [ 174.854507][ T9784] hfsplus_unlink+0x1ca/0x7c0 [ 174.854516][ T9784] ? __pfx_hfsplus_unlink+0x10/0x10 [ 174.854525][ T9784] ? down_write+0x148/0x200 [ 174.854532][ T9784] ? __pfx_down_write+0x10/0x10 [ 174.854540][ T9784] vfs_unlink+0x2fe/0x9b0 [ 174.854549][ T9784] do_unlinkat+0x490/0x670 [ 174.854557][ T9784] ? __pfx_do_unlinkat+0x10/0x10 [ 174.854565][ T9784] ? __might_fault+0xbc/0x130 [ 174.854576][ T9784] ? getname_flags.part.0+0x1c5/0x550 [ 174.854584][ T9784] __x64_sys_unlink+0xc5/0x110 [ 174.854592][ T9784] do_syscall_64+0xc9/0x480 [ 174.854600][ T9784] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 174.854608][ T9784] RIP: 0033:0x7f6fdf4c3167 [ 174.854614][ T9784] Code: f0 ff ff 73 01 c3 48 8b 0d 26 0d 0e 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 08 [ 174.854622][ T9784] RSP: 002b:00007ffcb948bca8 EFLAGS: 00000206 ORIG_RAX: 0000000000000057 [ 174.854630][ T9784] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f6fdf4c3167 [ 174.854636][ T9784] RDX: 00007ffcb948bcc0 RSI: 00007ffcb948bcc0 RDI: 00007ffcb948bd50 [ 174.854641][ T9784] RBP: 00007ffcb948cd90 R08: 0000000000000001 R09: 00007ffcb948bb40 [ 174.854645][ T9784] R10: 00007f6fdf564fc0 R11: 0000000000000206 R12: 0000561e1bc9c2d0 [ 174.854650][ T9784] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 174.854658][ T9784] </TASK> [ 174.854661][ T9784] [ 174.879281][ T9784] Allocated by task 9784: [ 174.879664][ T9784] kasan_save_stack+0x20/0x40 [ 174.880082][ T9784] kasan_save_track+0x14/0x30 [ 174.880500][ T9784] __kasan_kmalloc+0xaa/0xb0 [ 174.880908][ T9784] __kmalloc_noprof+0x205/0x550 [ 174.881337][ T9784] __hfs_bnode_create+0x107/0x890 [ 174.881779][ T9784] hfsplus_bnode_find+0x2d0/0xd10 [ 174.882222][ T9784] hfsplus_brec_find+0x2b0/0x520 [ 174.882659][ T9784] hfsplus_delete_all_attrs+0x23b/0x3 ---truncated---(CVE-2025-38714)
In the Linux kernel, the following vulnerability has been resolved:
fs/buffer: fix use-after-free when call bh_read() helper
There's issue as follows: BUG: KASAN: stack-out-of-bounds in end_buffer_read_sync+0xe3/0x110 Read of size 8 at addr ffffc9000168f7f8 by task swapper/3/0 CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.16.0-862.14.0.6.x86_64 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <IRQ> dump_stack_lvl+0x55/0x70 print_address_description.constprop.0+0x2c/0x390 print_report+0xb4/0x270 kasan_report+0xb8/0xf0 end_buffer_read_sync+0xe3/0x110 end_bio_bh_io_sync+0x56/0x80 blk_update_request+0x30a/0x720 scsi_end_request+0x51/0x2b0 scsi_io_completion+0xe3/0x480 ? scsi_device_unbusy+0x11e/0x160 blk_complete_reqs+0x7b/0x90 handle_softirqs+0xef/0x370 irq_exit_rcu+0xa5/0xd0 sysvec_apic_timer_interrupt+0x6e/0x90 </IRQ>
Above issue happens when do ntfs3 filesystem mount, issue may happens as follows: mount IRQ ntfs_fill_super read_cache_page do_read_cache_folio filemap_read_folio mpage_read_folio do_mpage_readpage ntfs_get_block_vbo bh_read submit_bh wait_on_buffer(bh); blk_complete_reqs scsi_io_completion scsi_end_request blk_update_request end_bio_bh_io_sync end_buffer_read_sync __end_buffer_read_notouch unlock_buffer
wait_on_buffer(bh);--> return will return to caller
put_bh
--> trigger stack-out-of-bounds
In the mpage_read_folio() function, the stack variable 'map_bh' is passed to ntfs_get_block_vbo(). Once unlock_buffer() unlocks and wait_on_buffer() returns to continue processing, the stack variable is likely to be reclaimed. Consequently, during the end_buffer_read_sync() process, calling put_bh() may result in stack overrun.
If the bh is not allocated on the stack, it belongs to a folio. Freeing a buffer head which belongs to a folio is done by drop_buffers() which will fail to free buffers which are still locked. So it is safe to call put_bh() before __end_buffer_read_notouch().(CVE-2025-39691)
In the Linux kernel, the following vulnerability has been resolved:
mm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup()
A soft lockup warning was observed on a relative small system x86-64 system with 16 GB of memory when running a debug kernel with kmemleak enabled.
watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134]
The test system was running a workload with hot unplug happening in parallel. Then kemleak decided to disable itself due to its inability to allocate more kmemleak objects. The debug kernel has its CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000.
The soft lockup happened in kmemleak_do_cleanup() when the existing kmemleak objects were being removed and deleted one-by-one in a loop via a workqueue. In this particular case, there are at least 40,000 objects that need to be processed and given the slowness of a debug kernel and the fact that a raw_spinlock has to be acquired and released in __delete_object(), it could take a while to properly handle all these objects.
As kmemleak has been disabled in this case, the object removal and deletion process can be further optimized as locking isn't really needed. However, it is probably not worth the effort to optimize for such an edge case that should rarely happen. So the simple solution is to call cond_resched() at periodic interval in the iteration loop to avoid soft lockup.(CVE-2025-39737)
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: use array_index_nospec with indices that come from guest
min and dest_id are guest-controlled indices. Using array_index_nospec() after the bounds checks clamps these values to mitigate speculative execution side-channels.(CVE-2025-39823)
In the Linux kernel, the following vulnerability has been resolved:
batman-adv: fix OOB read/write in network-coding decode
batadv_nc_skb_decode_packet() trusts coded_len and checks only against skb->len. XOR starts at sizeof(struct batadv_unicast_packet), reducing payload headroom, and the source skb length is not verified, allowing an out-of-bounds read and a small out-of-bounds write.
Validate that coded_len fits within the payload area of both destination and source sk_buffs before XORing.(CVE-2025-39839)
In the Linux kernel, the following vulnerability has been resolved:
um: virtio_uml: Fix use-after-free after put_device in probe
When register_virtio_device() fails in virtio_uml_probe(), the code sets vu_dev->registered = 1 even though the device was not successfully registered. This can lead to use-after-free or other issues.(CVE-2025-39951)
In the Linux kernel, the following vulnerability has been resolved:
i40e: add max boundary check for VF filters
There is no check for max filters that VF can request. Add it.(CVE-2025-39968)
In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: Fix Use-after-free in validation
Nodes stored in the validation duplicates hashtable come from an arena allocator that is cleared at the end of vmw_execbuf_process. All nodes are expected to be cleared in vmw_validation_drop_ht but this node escaped because its resource was destroyed prematurely.(CVE-2025-40111)
In the Linux kernel, the following vulnerability has been resolved:
pid: Add a judgment for ns null in pid_nr_ns
__task_pid_nr_ns ns = task_active_pid_ns(current); pid_nr_ns(rcu_dereference(*task_pid_ptr(task, type)), ns); if (pid && ns->level <= pid->level) {
Sometimes null is returned for task_active_pid_ns. Then it will trigger kernel panic in pid_nr_ns.
For example: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault Data abort info: ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=00000002175aa000 [0000000000000058] pgd=08000002175ab003, p4d=08000002175ab003, pud=08000002175ab003, pmd=08000002175be003, pte=0000000000000000 pstate: 834000c5 (Nzcv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : __task_pid_nr_ns+0x74/0xd0 lr : __task_pid_nr_ns+0x24/0xd0 sp : ffffffc08001bd10 x29: ffffffc08001bd10 x28: ffffffd4422b2000 x27: 0000000000000001 x26: ffffffd442821168 x25: ffffffd442821000 x24: 00000f89492eab31 x23: 00000000000000c0 x22: ffffff806f5693c0 x21: ffffff806f5693c0 x20: 0000000000000001 x19: 0000000000000000 x18: 0000000000000000 x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 00000000023a1adc x14: 0000000000000003 x13: 00000000007ef6d8 x12: 001167c391c78800 x11: 00ffffffffffffff x10: 0000000000000000 x9 : 0000000000000001 x8 : ffffff80816fa3c0 x7 : 0000000000000000 x6 : 49534d702d535449 x5 : ffffffc080c4c2c0 x4 : ffffffd43ee128c8 x3 : ffffffd43ee124dc x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffffff806f5693c0 Call trace: __task_pid_nr_ns+0x74/0xd0 ... __handle_irq_event_percpu+0xd4/0x284 handle_irq_event+0x48/0xb0 handle_fasteoi_irq+0x160/0x2d8 generic_handle_domain_irq+0x44/0x60 gic_handle_irq+0x4c/0x114 call_on_irq_stack+0x3c/0x74 do_interrupt_handler+0x4c/0x84 el1_interrupt+0x34/0x58 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x68/0x6c account_kernel_stack+0x60/0x144 exit_task_stack_account+0x1c/0x80 do_exit+0x7e4/0xaf8 ... get_signal+0x7bc/0x8d8 do_notify_resume+0x128/0x828 el0_svc+0x6c/0x70 el0t_64_sync_handler+0x68/0xbc el0t_64_sync+0x1a8/0x1ac Code: 35fffe54 911a02a8 f9400108 b4000128 (b9405a69) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt(CVE-2025-40178)
In the Linux kernel, the following vulnerability has been resolved:
scsi: sg: Do not sleep in atomic context
sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.(CVE-2025-40259)
In the Linux kernel, the following vulnerability has been resolved:
scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()
If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it.
Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: <TASK> configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...(CVE-2025-68229)
In the Linux kernel, the following vulnerability has been resolved:
regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex
regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to:
1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers.
Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex.(CVE-2025-68354)
A use-after-free vulnerability exists in the mlxsw spectrum multicast route component of Linux Kernel. The vulnerability occurs when updating multicast route statistics, where an instance of list entry deletion during route replace was missed from mutex protection, potentially leading to use-after-free.(CVE-2025-68800)
A reference counting management vulnerability exists in the mlxsw: spectrum_router driver component of the Linux kernel. The driver stores a pointer to a neighbour object without properly holding a reference to it. A reference is only taken when the neighbour is used by a nexthop. This inconsistent reference counting scheme can lead to a situation where, under specific conditions (e.g., during network device event handling), the driver attempts to access a neighbour object that has already been freed, triggering a use-after-free error. An attacker could potentially exploit this vulnerability to cause a kernel crash, thereby affecting system availability.(CVE-2025-68801)
An off-by-one vulnerability exists in the Intel Ethernet Virtual Function (iavf) driver of the Linux kernel. The flaw resides in the iavf_config_rss_reg() function. When configuring the Receive Side Scaling (RSS) hash key and lookup table, incorrect loop boundary conditions (using <= instead of <) lead to out-of-bounds reads from allocated memory and potential out-of-bounds writes to device registers. An attacker could potentially exploit this vulnerability to cause kernel information disclosure, system instability, or crashes.(CVE-2025-71087)
In the Linux kernel, a buffer overflow vulnerability exists in the e1000 network driver's e1000_tbi_should_accept() function. The function reads the last byte of the frame via 'data[length - 1]' to evaluate the TBI (Tunnel Bypass Identifier) workaround. If the descriptor-reported length is zero or larger than the actual RX buffer size, this read goes out of bounds and can hit unrelated slab objects. The issue is observed from the NAPI receive path (e1000_clean_rx_irq). The root cause is that the TBI check unconditionally dereferences the last byte without validating the reported length first. The fix rejects the frame early if the length is zero or exceeds adapter->rx_buffer_len, preserving the TBI workaround semantics for valid frames and preventing touching memory beyond the RX buffer.(CVE-2025-71093)
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timer
When advancing the target expiration for the guest's APIC timer in periodic mode, set the expiration to "now" if the target expiration is in the past (similar to what is done in update_target_expiration()). Blindly adding the period to the previous target expiration can result in KVM generating a practically unbounded number of hrtimer IRQs due to programming an expired timer over and over. In extreme scenarios, e.g. if userspace pauses/suspends a VM for an extended duration, this can even cause hard lockups in the host.
Currently, the bug only affects Intel CPUs when using the hypervisor timer (HV timer), a.k.a. the VMX preemption timer. Unlike the software timer, a.k.a. hrtimer, which KVM keeps running even on exits to userspace, the HV timer only runs while the guest is active. As a result, if the vCPU does not run for an extended duration, there will be a huge gap between the target expiration and the current time the vCPU resumes running. Because the target expiration is incremented by only one period on each timer expiration, this leads to a series of timer expirations occurring rapidly after the vCPU/VM resumes.
More critically, when the vCPU first triggers a periodic HV timer expiration after resuming, advancing the expiration by only one period will result in a target expiration in the past. As a result, the delta may be calculated as a negative value. When the delta is converted into an absolute value (tscdeadline is an unsigned u64), the resulting value can overflow what the HV timer is capable of programming. I.e. the large value will exceed the VMX Preemption Timer's maximum bit width of cpu_preemption_timer_multi + 32, and thus cause KVM to switch from the HV timer to the software timer (hrtimers).
After switching to the software timer, periodic timer expiration callbacks may be executed consecutively within a single clock interrupt handler, because hrtimers honors KVM's request for an expiration in the past and immediately re-invokes KVM's callback after reprogramming. And because the interrupt handler runs with IRQs disabled, restarting KVM's hrtimer over and over until the target expiration is advanced to "now" can result in a hard lockup.
E.g. the following hard lockup was triggered in the host when running a Windows VM (only relevant because it used the APIC timer in periodic mode) after resuming the VM from a long suspend (in the host).
NMI watchdog: Watchdog detected hard LOCKUP on cpu 45 ... RIP: 0010:advance_periodic_target_expiration+0x4d/0x80 [kvm] ... RSP: 0018:ff4f88f5d98d8ef0 EFLAGS: 00000046 RAX: fff0103f91be678e RBX: fff0103f91be678e RCX: 00843a7d9e127bcc RDX: 0000000000000002 RSI: 0052ca4003697505 RDI: ff440d5bfbdbd500 RBP: ff440d5956f99200 R08: ff2ff2a42deb6a84 R09: 000000000002a6c0 R10: 0122d794016332b3 R11: 0000000000000000 R12: ff440db1af39cfc0 R13: ff440db1af39cfc0 R14: ffffffffc0d4a560 R15: ff440db1af39d0f8 FS: 00007f04a6ffd700(0000) GS:ff440db1af380000(0000) knlGS:000000e38a3b8000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000d5651feff8 CR3: 000000684e038002 CR4: 0000000000773ee0 PKRU: 55555554 Call Trace: <IRQ> apic_timer_fn+0x31/0x50 [kvm] __hrtimer_run_queues+0x100/0x280 hrtimer_interrupt+0x100/0x210 ? ttwu_do_wakeup+0x19/0x160 smp_apic_timer_interrupt+0x6a/0x130 apic_timer_interrupt+0xf/0x20 </IRQ>
Moreover, if the suspend duration of the virtual machine is not long enough to trigger a hard lockup in this scenario, since commit 98c25ead5eda ("KVM: VMX: Move preemption timer <=> hrtimer dance to common x86"), KVM will continue using the software timer until the guest reprograms the APIC timer in some way. Since the periodic timer does not require frequent APIC timer register programming, the guest may continue to use the software timer in ---truncated---(CVE-2025-71104)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Do not register unsupported perf events
Synthetic events currently do not have a function to register perf events. This leads to calling the tracepoint register functions with a NULL function pointer which triggers:
------------[ cut here ]------------ WARNING: kernel/tracepoint.c:175 at tracepoint_add_func+0x357/0x370, CPU#2: perf/2272 Modules linked in: kvm_intel kvm irqbypass CPU: 2 UID: 0 PID: 2272 Comm: perf Not tainted 6.18.0-ftest-11964-ge022764176fc-dirty #323 PREEMPTLAZY Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:tracepoint_add_func+0x357/0x370 Code: 28 9c e8 4c 0b f5 ff eb 0f 4c 89 f7 48 c7 c6 80 4d 28 9c e8 ab 89 f4 ff 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc <0f> 0b 49 c7 c6 ea ff ff ff e9 ee fe ff ff 0f 0b e9 f9 fe ff ff 0f RSP: 0018:ffffabc0c44d3c40 EFLAGS: 00010246 RAX: 0000000000000001 RBX: ffff9380aa9e4060 RCX: 0000000000000000 RDX: 000000000000000a RSI: ffffffff9e1d4a98 RDI: ffff937fcf5fd6c8 RBP: 0000000000000001 R08: 0000000000000007 R09: ffff937fcf5fc780 R10: 0000000000000003 R11: ffffffff9c193910 R12: 000000000000000a R13: ffffffff9e1e5888 R14: 0000000000000000 R15: ffffabc0c44d3c78 FS: 00007f6202f5f340(0000) GS:ffff93819f00f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055d3162281a8 CR3: 0000000106a56003 CR4: 0000000000172ef0 Call Trace: <TASK> tracepoint_probe_register+0x5d/0x90 synth_event_reg+0x3c/0x60 perf_trace_event_init+0x204/0x340 perf_trace_init+0x85/0xd0 perf_tp_event_init+0x2e/0x50 perf_try_init_event+0x6f/0x230 ? perf_event_alloc+0x4bb/0xdc0 perf_event_alloc+0x65a/0xdc0 __se_sys_perf_event_open+0x290/0x9f0 do_syscall_64+0x93/0x7b0 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e ? trace_hardirqs_off+0x53/0xc0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Instead, have the code return -ENODEV, which doesn't warn and has perf error out with:
# perf record -e synthetic:futex_wait Error: The sys_perf_event_open() syscall returned with 19 (No such device) for event (synthetic:futex_wait). "dmesg | grep -i perf" may provide additional information.
Ideally perf should support synthetic events, but for now just fix the warning. The support can come later.(CVE-2025-71125)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm",
"bpftool-debuginfo-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm",
"kernel-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm",
"kernel-debuginfo-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm",
"kernel-debugsource-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm",
"kernel-devel-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm",
"kernel-headers-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm",
"kernel-source-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm",
"kernel-tools-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm",
"kernel-tools-devel-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm",
"perf-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm",
"perf-debuginfo-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm",
"python3-perf-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-299.0.0.202.oe2203sp4.aarch64.rpm"
],
"src": [
"kernel-5.10.0-299.0.0.202.oe2203sp4.src.rpm"
],
"x86_64": [
"bpftool-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm",
"bpftool-debuginfo-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm",
"kernel-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm",
"kernel-debuginfo-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm",
"kernel-debugsource-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm",
"kernel-devel-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm",
"kernel-headers-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm",
"kernel-source-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm",
"kernel-tools-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm",
"kernel-tools-devel-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm",
"perf-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm",
"perf-debuginfo-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm",
"python3-perf-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-299.0.0.202.oe2203sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-299.0.0.202.oe2203sp4"
}
],
"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\nscsi: qla2xxx: Fix premature hw access after PCI error\n\nAfter a recoverable PCI error has been detected and recovered, qla driver\nneeds to check to see if the error condition still persist and/or wait\nfor the OS to give the resume signal.\n\nSep 8 22:26:03 localhost kernel: WARNING: CPU: 9 PID: 124606 at qla_tmpl.c:440\nqla27xx_fwdt_entry_t266+0x55/0x60 [qla2xxx]\nSep 8 22:26:03 localhost kernel: RIP: 0010:qla27xx_fwdt_entry_t266+0x55/0x60\n[qla2xxx]\nSep 8 22:26:03 localhost kernel: Call Trace:\nSep 8 22:26:03 localhost kernel: ? qla27xx_walk_template+0xb1/0x1b0 [qla2xxx]\nSep 8 22:26:03 localhost kernel: ? qla27xx_execute_fwdt_template+0x12a/0x160\n[qla2xxx]\nSep 8 22:26:03 localhost kernel: ? qla27xx_fwdump+0xa0/0x1c0 [qla2xxx]\nSep 8 22:26:03 localhost kernel: ? qla2xxx_pci_mmio_enabled+0xfb/0x120\n[qla2xxx]\nSep 8 22:26:03 localhost kernel: ? report_mmio_enabled+0x44/0x80\nSep 8 22:26:03 localhost kernel: ? report_slot_reset+0x80/0x80\nSep 8 22:26:03 localhost kernel: ? pci_walk_bus+0x70/0x90\nSep 8 22:26:03 localhost kernel: ? aer_dev_correctable_show+0xc0/0xc0\nSep 8 22:26:03 localhost kernel: ? pcie_do_recovery+0x1bb/0x240\nSep 8 22:26:03 localhost kernel: ? aer_recover_work_func+0xaa/0xd0\nSep 8 22:26:03 localhost kernel: ? process_one_work+0x1a7/0x360\n..\nSep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-8041:22: detected PCI\ndisconnect.\nSep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-107ff:22:\nqla27xx_fwdt_entry_t262: dump ram MB failed. Area 5h start 198013h end 198013h\nSep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-107ff:22: Unable to\ncapture FW dump\nSep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-1015:22: cmd=0x0,\nwaited 5221 msecs\nSep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-680d:22: mmio\nenabled returning.\nSep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-d04c:22: MBX\nCommand timeout for cmd 0, iocontrol=ffffffff jiffies=10140f2e5\nmb[0-3]=[0xffff 0xffff 0xffff 0xffff](CVE-2022-49157)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid0, raid10: Don\u0026apos;t set discard sectors for request queue\n\nIt should use disk_stack_limits to get a proper max_discard_sectors\nrather than setting a value by stack drivers.\n\nAnd there is a bug. If all member disks are rotational devices,\nraid0/raid10 set max_discard_sectors. So the member devices are\nnot ssd/nvme, but raid0/raid10 export the wrong value. It reports\nwarning messages in function __blkdev_issue_discard when mkfs.xfs\nlike this:\n\n[ 4616.022599] ------------[ cut here ]------------\n[ 4616.027779] WARNING: CPU: 4 PID: 99634 at block/blk-lib.c:50 __blkdev_issue_discard+0x16a/0x1a0\n[ 4616.140663] RIP: 0010:__blkdev_issue_discard+0x16a/0x1a0\n[ 4616.146601] Code: 24 4c 89 20 31 c0 e9 fe fe ff ff c1 e8 09 8d 48 ff 4c 89 f0 4c 09 e8 48 85 c1 0f 84 55 ff ff ff b8 ea ff ff ff e9 df fe ff ff \u0026lt;0f\u0026gt; 0b 48 8d 74 24 08 e8 ea d6 00 00 48 c7 c6 20 1e 89 ab 48 c7 c7\n[ 4616.167567] RSP: 0018:ffffaab88cbffca8 EFLAGS: 00010246\n[ 4616.173406] RAX: ffff9ba1f9e44678 RBX: 0000000000000000 RCX: ffff9ba1c9792080\n[ 4616.181376] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9ba1c9792080\n[ 4616.189345] RBP: 0000000000000cc0 R08: ffffaab88cbffd10 R09: 0000000000000000\n[ 4616.197317] R10: 0000000000000012 R11: 0000000000000000 R12: 0000000000000000\n[ 4616.205288] R13: 0000000000400000 R14: 0000000000000cc0 R15: ffff9ba1c9792080\n[ 4616.213259] FS: 00007f9a5534e980(0000) GS:ffff9ba1b7c80000(0000) knlGS:0000000000000000\n[ 4616.222298] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 4616.228719] CR2: 000055a390a4c518 CR3: 0000000123e40006 CR4: 00000000001706e0\n[ 4616.236689] Call Trace:\n[ 4616.239428] blkdev_issue_discard+0x52/0xb0\n[ 4616.244108] blkdev_common_ioctl+0x43c/0xa00\n[ 4616.248883] blkdev_ioctl+0x116/0x280\n[ 4616.252977] __x64_sys_ioctl+0x8a/0xc0\n[ 4616.257163] do_syscall_64+0x5c/0x90\n[ 4616.261164] ? handle_mm_fault+0xc5/0x2a0\n[ 4616.265652] ? do_user_addr_fault+0x1d8/0x690\n[ 4616.270527] ? do_syscall_64+0x69/0x90\n[ 4616.274717] ? exc_page_fault+0x62/0x150\n[ 4616.279097] entry_SYSCALL_64_after_hwframe+0x63/0xcd\n[ 4616.284748] RIP: 0033:0x7f9a55398c6b(CVE-2022-50583)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Validate index root when initialize NTFS security\n\nThis enhances the sanity check for $SDH and $SII while initializing NTFS\nsecurity, guarantees these index root are legit.\n\n[ 162.459513] BUG: KASAN: use-after-free in hdr_find_e.isra.0+0x10c/0x320\n[ 162.460176] Read of size 2 at addr ffff8880037bca99 by task mount/243\n[ 162.460851]\n[ 162.461252] CPU: 0 PID: 243 Comm: mount Not tainted 6.0.0-rc7 #42\n[ 162.461744] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014\n[ 162.462609] Call Trace:\n[ 162.462954] \u0026lt;TASK\u0026gt;\n[ 162.463276] dump_stack_lvl+0x49/0x63\n[ 162.463822] print_report.cold+0xf5/0x689\n[ 162.464608] ? unwind_get_return_address+0x3a/0x60\n[ 162.465766] ? hdr_find_e.isra.0+0x10c/0x320\n[ 162.466975] kasan_report+0xa7/0x130\n[ 162.467506] ? _raw_spin_lock_irq+0xc0/0xf0\n[ 162.467998] ? hdr_find_e.isra.0+0x10c/0x320\n[ 162.468536] __asan_load2+0x68/0x90\n[ 162.468923] hdr_find_e.isra.0+0x10c/0x320\n[ 162.469282] ? cmp_uints+0xe0/0xe0\n[ 162.469557] ? cmp_sdh+0x90/0x90\n[ 162.469864] ? ni_find_attr+0x214/0x300\n[ 162.470217] ? ni_load_mi+0x80/0x80\n[ 162.470479] ? entry_SYSCALL_64_after_hwframe+0x63/0xcd\n[ 162.470931] ? ntfs_bread_run+0x190/0x190\n[ 162.471307] ? indx_get_root+0xe4/0x190\n[ 162.471556] ? indx_get_root+0x140/0x190\n[ 162.471833] ? indx_init+0x1e0/0x1e0\n[ 162.472069] ? fnd_clear+0x115/0x140\n[ 162.472363] ? _raw_spin_lock_irqsave+0x100/0x100\n[ 162.472731] indx_find+0x184/0x470\n[ 162.473461] ? sysvec_apic_timer_interrupt+0x57/0xc0\n[ 162.474429] ? indx_find_buffer+0x2d0/0x2d0\n[ 162.474704] ? do_syscall_64+0x3b/0x90\n[ 162.474962] dir_search_u+0x196/0x2f0\n[ 162.475381] ? ntfs_nls_to_utf16+0x450/0x450\n[ 162.475661] ? ntfs_security_init+0x3d6/0x440\n[ 162.475906] ? is_sd_valid+0x180/0x180\n[ 162.476191] ntfs_extend_init+0x13f/0x2c0\n[ 162.476496] ? ntfs_fix_post_read+0x130/0x130\n[ 162.476861] ? iput.part.0+0x286/0x320\n[ 162.477325] ntfs_fill_super+0x11e0/0x1b50\n[ 162.477709] ? put_ntfs+0x1d0/0x1d0\n[ 162.477970] ? vsprintf+0x20/0x20\n[ 162.478258] ? set_blocksize+0x95/0x150\n[ 162.478538] get_tree_bdev+0x232/0x370\n[ 162.478789] ? put_ntfs+0x1d0/0x1d0\n[ 162.479038] ntfs_fs_get_tree+0x15/0x20\n[ 162.479374] vfs_get_tree+0x4c/0x130\n[ 162.479729] path_mount+0x654/0xfe0\n[ 162.480124] ? putname+0x80/0xa0\n[ 162.480484] ? finish_automount+0x2e0/0x2e0\n[ 162.480894] ? putname+0x80/0xa0\n[ 162.481467] ? kmem_cache_free+0x1c4/0x440\n[ 162.482280] ? putname+0x80/0xa0\n[ 162.482714] do_mount+0xd6/0xf0\n[ 162.483264] ? path_mount+0xfe0/0xfe0\n[ 162.484782] ? __kasan_check_write+0x14/0x20\n[ 162.485593] __x64_sys_mount+0xca/0x110\n[ 162.486024] do_syscall_64+0x3b/0x90\n[ 162.486543] entry_SYSCALL_64_after_hwframe+0x63/0xcd\n[ 162.487141] RIP: 0033:0x7f9d374e948a\n[ 162.488324] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008\n[ 162.489728] RSP: 002b:00007ffe30e73d18 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5\n[ 162.490971] RAX: ffffffffffffffda RBX: 0000561cdb43a060 RCX: 00007f9d374e948a\n[ 162.491669] RDX: 0000561cdb43a260 RSI: 0000561cdb43a2e0 RDI: 0000561cdb442af0\n[ 162.492050] RBP: 0000000000000000 R08: 0000561cdb43a280 R09: 0000000000000020\n[ 162.492459] R10: 00000000c0ed0000 R11: 0000000000000206 R12: 0000561cdb442af0\n[ 162.493183] R13: 0000561cdb43a260 R14: 0000000000000000 R15: 00000000ffffffff\n[ 162.493644] \u0026lt;/TASK\u0026gt;\n[ 162.493908]\n[ 162.494214] The buggy address belongs to the physical page:\n[ 162.494761] page:000000003e38a3d5 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x37bc\n[ 162.496064] flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff)\n[ 162.497278] raw: 000fffffc0000000 ffffea00000df1c8 ffffea00000df008 0000000000000000\n[ 162.498928] raw: 0000000000000000 0000000000240000 0\n---truncated---(CVE-2022-50737)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: Avoid calling OPDESC() with ops-\u0026gt;opnum == OP_ILLEGAL\n\nOPDESC() simply indexes into nfsd4_ops[] by the op\u0026apos;s operation\nnumber, without range checking that value. It assumes callers are\ncareful to avoid calling it with an out-of-bounds opnum value.\n\nnfsd4_decode_compound() is not so careful, and can invoke OPDESC()\nwith opnum set to OP_ILLEGAL, which is 10044 -- well beyond the end\nof nfsd4_ops[].(CVE-2023-53680)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: fix session state check in reconnect to avoid use-after-free issue\n\nDon\u0026apos;t collect exiting session in smb2_reconnect_server(), because it\nwill be released soon.\n\nNote that the exiting session will stay in server-\u0026gt;smb_ses_list until\nit complete the cifs_free_ipc() and logoff() and then delete itself\nfrom the list.(CVE-2023-53794)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/nouveau/kms/nv50-: init hpd_irq_lock for PIOR DP\n\nFixes OOPS on boards with ANX9805 DP encoders.(CVE-2023-54263)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njfs: add sanity check for agwidth in dbMount\n\nThe width in dmapctl of the AG is zero, it trigger a divide error when\ncalculating the control page level in dbAllocAG.\n\nTo avoid this issue, add a check for agwidth in dbAllocAG.(CVE-2025-37740)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/pm: Prevent division by zero\n\nThe user can set any speed value.\nIf speed is greater than UINT_MAX/8, division by zero is possible.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37768)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: Fix use-after-free in cifs_fill_dirent\n\nThere is a race condition in the readdir concurrency process, which may\naccess the rsp buffer after it has been released, triggering the\nfollowing KASAN warning.\n\n ==================================================================\n BUG: KASAN: slab-use-after-free in cifs_fill_dirent+0xb03/0xb60 [cifs]\n Read of size 4 at addr ffff8880099b819c by task a.out/342975\n\n CPU: 2 UID: 0 PID: 342975 Comm: a.out Not tainted 6.15.0-rc6+ #240 PREEMPT(full)\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x53/0x70\n print_report+0xce/0x640\n kasan_report+0xb8/0xf0\n cifs_fill_dirent+0xb03/0xb60 [cifs]\n cifs_readdir+0x12cb/0x3190 [cifs]\n iterate_dir+0x1a1/0x520\n __x64_sys_getdents+0x134/0x220\n do_syscall_64+0x4b/0x110\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n RIP: 0033:0x7f996f64b9f9\n Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89\n f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01\n f0 ff ff 0d f7 c3 0c 00 f7 d8 64 89 8\n RSP: 002b:00007f996f53de78 EFLAGS: 00000207 ORIG_RAX: 000000000000004e\n RAX: ffffffffffffffda RBX: 00007f996f53ecdc RCX: 00007f996f64b9f9\n RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003\n RBP: 00007f996f53dea0 R08: 0000000000000000 R09: 0000000000000000\n R10: 0000000000000000 R11: 0000000000000207 R12: ffffffffffffff88\n R13: 0000000000000000 R14: 00007ffc8cd9a500 R15: 00007f996f51e000\n \u0026lt;/TASK\u0026gt;\n\n Allocated by task 408:\n kasan_save_stack+0x20/0x40\n kasan_save_track+0x14/0x30\n __kasan_slab_alloc+0x6e/0x70\n kmem_cache_alloc_noprof+0x117/0x3d0\n mempool_alloc_noprof+0xf2/0x2c0\n cifs_buf_get+0x36/0x80 [cifs]\n allocate_buffers+0x1d2/0x330 [cifs]\n cifs_demultiplex_thread+0x22b/0x2690 [cifs]\n kthread+0x394/0x720\n ret_from_fork+0x34/0x70\n ret_from_fork_asm+0x1a/0x30\n\n Freed by task 342979:\n kasan_save_stack+0x20/0x40\n kasan_save_track+0x14/0x30\n kasan_save_free_info+0x3b/0x60\n __kasan_slab_free+0x37/0x50\n kmem_cache_free+0x2b8/0x500\n cifs_buf_release+0x3c/0x70 [cifs]\n cifs_readdir+0x1c97/0x3190 [cifs]\n iterate_dir+0x1a1/0x520\n __x64_sys_getdents64+0x134/0x220\n do_syscall_64+0x4b/0x110\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n The buggy address belongs to the object at ffff8880099b8000\n which belongs to the cache cifs_request of size 16588\n The buggy address is located 412 bytes inside of\n freed 16588-byte region [ffff8880099b8000, ffff8880099bc0cc)\n\n The buggy address belongs to the physical page:\n page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x99b8\n head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0\n anon flags: 0x80000000000040(head|node=0|zone=1)\n page_type: f5(slab)\n raw: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001\n raw: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000\n head: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001\n head: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000\n head: 0080000000000003 ffffea0000266e01 00000000ffffffff 00000000ffffffff\n head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008\n page dumped because: kasan: bad access detected\n\n Memory state around the buggy address:\n ffff8880099b8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n ffff8880099b8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n \u0026gt;ffff8880099b8180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n ^\n ffff8880099b8200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n ffff8880099b8280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n ==================================================================\n\nPOC is available in the link [1].\n\nThe problem triggering process is as follows:\n\nProcess 1 Process 2\n-----------------------------------\n---truncated---(CVE-2025-38051)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nVMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify\n\nDuring our test, it is found that a warning can be trigger in try_grab_folio\nas follow:\n\n ------------[ cut here ]------------\n WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130\n Modules linked in:\n CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef)\n RIP: 0010:try_grab_folio+0x106/0x130\n Call Trace:\n \u0026lt;TASK\u0026gt;\n follow_huge_pmd+0x240/0x8e0\n follow_pmd_mask.constprop.0.isra.0+0x40b/0x5c0\n follow_pud_mask.constprop.0.isra.0+0x14a/0x170\n follow_page_mask+0x1c2/0x1f0\n __get_user_pages+0x176/0x950\n __gup_longterm_locked+0x15b/0x1060\n ? gup_fast+0x120/0x1f0\n gup_fast_fallback+0x17e/0x230\n get_user_pages_fast+0x5f/0x80\n vmci_host_unlocked_ioctl+0x21c/0xf80\n RIP: 0033:0x54d2cd\n ---[ end trace 0000000000000000 ]---\n\nDigging into the source, context-\u0026gt;notify_page may init by get_user_pages_fast\nand can be seen in vmci_ctx_unset_notify which will try to put_page. However\nget_user_pages_fast is not finished here and lead to following\ntry_grab_folio warning. The race condition is shown as follow:\n\ncpu0\t\t\tcpu1\nvmci_host_do_set_notify\nvmci_host_setup_notify\nget_user_pages_fast(uva, 1, FOLL_WRITE, \u0026amp;context-\u0026gt;notify_page);\nlockless_pages_from_mm\ngup_pgd_range\ngup_huge_pmd // update \u0026amp;context-\u0026gt;notify_page\n\t\t\tvmci_host_do_set_notify\n\t\t\tvmci_ctx_unset_notify\n\t\t\tnotify_page = context-\u0026gt;notify_page;\n\t\t\tif (notify_page)\n\t\t\tput_page(notify_page);\t// page is freed\n__gup_longterm_locked\n__get_user_pages\nfollow_trans_huge_pmd\ntry_grab_folio // warn here\n\nTo slove this, use local variable page to make notify_page can be seen\nafter finish get_user_pages_fast.(CVE-2025-38102)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: usbhid: Eliminate recurrent out-of-bounds bug in usbhid_parse()\n\nUpdate struct hid_descriptor to better reflect the mandatory and\noptional parts of the HID Descriptor as per USB HID 1.11 specification.\nNote: the kernel currently does not parse any optional HID class\ndescriptors, only the mandatory report descriptor.\n\nUpdate all references to member element desc[0] to rpt_desc.\n\nAdd test to verify bLength and bNumDescriptors values are valid.\n\nReplace the for loop with direct access to the mandatory HID class\ndescriptor member for the report descriptor. This eliminates the\npossibility of getting an out-of-bounds fault.\n\nAdd a warning message if the HID descriptor contains any unsupported\noptional HID class descriptors.(CVE-2025-38103)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mdiobus: Fix potential out-of-bounds read/write access\n\nWhen using publicly available tools like \u0026apos;mdio-tools\u0026apos; to read/write data\nfrom/to network interface and its PHY via mdiobus, there is no verification of\nparameters passed to the ioctl and it accepts any mdio address.\nCurrently there is support for 32 addresses in kernel via PHY_MAX_ADDR define,\nbut it is possible to pass higher value than that via ioctl.\nWhile read/write operation should generally fail in this case,\nmdiobus provides stats array, where wrong address may allow out-of-bounds\nread/write.\n\nFix that by adding address verification before read/write operation.\nWhile this excludes this access from any statistics, it improves security of\nread/write operation.(CVE-2025-38111)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsoftware node: Correct a OOB check in software_node_get_reference_args()\n\nsoftware_node_get_reference_args() wants to get @index-th element, so\nthe property value requires at least \u0026apos;(index + 1) * sizeof(*ref)\u0026apos; bytes\nbut that can not be guaranteed by current OOB check, and may cause OOB\nfor malformed property.\n\nFix by using as OOB check \u0026apos;((index + 1) * sizeof(*ref) \u0026gt; prop-\u0026gt;length)\u0026apos;.(CVE-2025-38342)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njfs: upper bound check of tree index in dbAllocAG\n\nWhen computing the tree index in dbAllocAG, we never check if we are\nout of bounds realative to the size of the stree.\nThis could happen in a scenario where the filesystem metadata are\ncorrupted.(CVE-2025-38697)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/pm: fix null pointer access\n\nWriting a string without delimiters (\u0026apos; \u0026apos;, \u0026apos;\\n\u0026apos;, \u0026apos;\\0\u0026apos;) to the under\ngpu_od/fan_ctrl sysfs or pp_power_profile_mode for the CUSTOM profile\nwill result in a null pointer dereference.(CVE-2025-38705)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: don\u0026apos;t use BUG_ON() in hfsplus_create_attributes_file()\n\nWhen the volume header contains erroneous values that do not reflect\nthe actual state of the filesystem, hfsplus_fill_super() assumes that\nthe attributes file is not yet created, which later results in hitting\nBUG_ON() when hfsplus_create_attributes_file() is called. Replace this\nBUG_ON() with -EIO error with a message to suggest running fsck tool.(CVE-2025-38712)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()\n\nThe hfsplus_readdir() method is capable to crash by calling\nhfsplus_uni2asc():\n\n[ 667.121659][ T9805] ==================================================================\n[ 667.122651][ T9805] BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0x902/0xa10\n[ 667.123627][ T9805] Read of size 2 at addr ffff88802592f40c by task repro/9805\n[ 667.124578][ T9805]\n[ 667.124876][ T9805] CPU: 3 UID: 0 PID: 9805 Comm: repro Not tainted 6.16.0-rc3 #1 PREEMPT(full)\n[ 667.124886][ T9805] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[ 667.124890][ T9805] Call Trace:\n[ 667.124893][ T9805] \u0026lt;TASK\u0026gt;\n[ 667.124896][ T9805] dump_stack_lvl+0x10e/0x1f0\n[ 667.124911][ T9805] print_report+0xd0/0x660\n[ 667.124920][ T9805] ? __virt_addr_valid+0x81/0x610\n[ 667.124928][ T9805] ? __phys_addr+0xe8/0x180\n[ 667.124934][ T9805] ? hfsplus_uni2asc+0x902/0xa10\n[ 667.124942][ T9805] kasan_report+0xc6/0x100\n[ 667.124950][ T9805] ? hfsplus_uni2asc+0x902/0xa10\n[ 667.124959][ T9805] hfsplus_uni2asc+0x902/0xa10\n[ 667.124966][ T9805] ? hfsplus_bnode_read+0x14b/0x360\n[ 667.124974][ T9805] hfsplus_readdir+0x845/0xfc0\n[ 667.124984][ T9805] ? __pfx_hfsplus_readdir+0x10/0x10\n[ 667.124994][ T9805] ? stack_trace_save+0x8e/0xc0\n[ 667.125008][ T9805] ? iterate_dir+0x18b/0xb20\n[ 667.125015][ T9805] ? trace_lock_acquire+0x85/0xd0\n[ 667.125022][ T9805] ? lock_acquire+0x30/0x80\n[ 667.125029][ T9805] ? iterate_dir+0x18b/0xb20\n[ 667.125037][ T9805] ? down_read_killable+0x1ed/0x4c0\n[ 667.125044][ T9805] ? putname+0x154/0x1a0\n[ 667.125051][ T9805] ? __pfx_down_read_killable+0x10/0x10\n[ 667.125058][ T9805] ? apparmor_file_permission+0x239/0x3e0\n[ 667.125069][ T9805] iterate_dir+0x296/0xb20\n[ 667.125076][ T9805] __x64_sys_getdents64+0x13c/0x2c0\n[ 667.125084][ T9805] ? __pfx___x64_sys_getdents64+0x10/0x10\n[ 667.125091][ T9805] ? __x64_sys_openat+0x141/0x200\n[ 667.125126][ T9805] ? __pfx_filldir64+0x10/0x10\n[ 667.125134][ T9805] ? do_user_addr_fault+0x7fe/0x12f0\n[ 667.125143][ T9805] do_syscall_64+0xc9/0x480\n[ 667.125151][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[ 667.125158][ T9805] RIP: 0033:0x7fa8753b2fc9\n[ 667.125164][ T9805] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 48\n[ 667.125172][ T9805] RSP: 002b:00007ffe96f8e0f8 EFLAGS: 00000217 ORIG_RAX: 00000000000000d9\n[ 667.125181][ T9805] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa8753b2fc9\n[ 667.125185][ T9805] RDX: 0000000000000400 RSI: 00002000000063c0 RDI: 0000000000000004\n[ 667.125190][ T9805] RBP: 00007ffe96f8e110 R08: 00007ffe96f8e110 R09: 00007ffe96f8e110\n[ 667.125195][ T9805] R10: 0000000000000000 R11: 0000000000000217 R12: 0000556b1e3b4260\n[ 667.125199][ T9805] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n[ 667.125207][ T9805] \u0026lt;/TASK\u0026gt;\n[ 667.125210][ T9805]\n[ 667.145632][ T9805] Allocated by task 9805:\n[ 667.145991][ T9805] kasan_save_stack+0x20/0x40\n[ 667.146352][ T9805] kasan_save_track+0x14/0x30\n[ 667.146717][ T9805] __kasan_kmalloc+0xaa/0xb0\n[ 667.147065][ T9805] __kmalloc_noprof+0x205/0x550\n[ 667.147448][ T9805] hfsplus_find_init+0x95/0x1f0\n[ 667.147813][ T9805] hfsplus_readdir+0x220/0xfc0\n[ 667.148174][ T9805] iterate_dir+0x296/0xb20\n[ 667.148549][ T9805] __x64_sys_getdents64+0x13c/0x2c0\n[ 667.148937][ T9805] do_syscall_64+0xc9/0x480\n[ 667.149291][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[ 667.149809][ T9805]\n[ 667.150030][ T9805] The buggy address belongs to the object at ffff88802592f000\n[ 667.150030][ T9805] which belongs to the cache kmalloc-2k of size 2048\n[ 667.151282][ T9805] The buggy address is located 0 bytes to the right of\n[ 667.151282][ T9805] allocated 1036-byte region [ffff88802592f000, ffff88802592f40c)\n[ 667.1\n---truncated---(CVE-2025-38713)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: fix slab-out-of-bounds in hfsplus_bnode_read()\n\nThe hfsplus_bnode_read() method can trigger the issue:\n\n[ 174.852007][ T9784] ==================================================================\n[ 174.852709][ T9784] BUG: KASAN: slab-out-of-bounds in hfsplus_bnode_read+0x2f4/0x360\n[ 174.853412][ T9784] Read of size 8 at addr ffff88810b5fc6c0 by task repro/9784\n[ 174.854059][ T9784]\n[ 174.854272][ T9784] CPU: 1 UID: 0 PID: 9784 Comm: repro Not tainted 6.16.0-rc3 #7 PREEMPT(full)\n[ 174.854281][ T9784] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[ 174.854286][ T9784] Call Trace:\n[ 174.854289][ T9784] \u0026lt;TASK\u0026gt;\n[ 174.854292][ T9784] dump_stack_lvl+0x10e/0x1f0\n[ 174.854305][ T9784] print_report+0xd0/0x660\n[ 174.854315][ T9784] ? __virt_addr_valid+0x81/0x610\n[ 174.854323][ T9784] ? __phys_addr+0xe8/0x180\n[ 174.854330][ T9784] ? hfsplus_bnode_read+0x2f4/0x360\n[ 174.854337][ T9784] kasan_report+0xc6/0x100\n[ 174.854346][ T9784] ? hfsplus_bnode_read+0x2f4/0x360\n[ 174.854354][ T9784] hfsplus_bnode_read+0x2f4/0x360\n[ 174.854362][ T9784] hfsplus_bnode_dump+0x2ec/0x380\n[ 174.854370][ T9784] ? __pfx_hfsplus_bnode_dump+0x10/0x10\n[ 174.854377][ T9784] ? hfsplus_bnode_write_u16+0x83/0xb0\n[ 174.854385][ T9784] ? srcu_gp_start+0xd0/0x310\n[ 174.854393][ T9784] ? __mark_inode_dirty+0x29e/0xe40\n[ 174.854402][ T9784] hfsplus_brec_remove+0x3d2/0x4e0\n[ 174.854411][ T9784] __hfsplus_delete_attr+0x290/0x3a0\n[ 174.854419][ T9784] ? __pfx_hfs_find_1st_rec_by_cnid+0x10/0x10\n[ 174.854427][ T9784] ? __pfx___hfsplus_delete_attr+0x10/0x10\n[ 174.854436][ T9784] ? __asan_memset+0x23/0x50\n[ 174.854450][ T9784] hfsplus_delete_all_attrs+0x262/0x320\n[ 174.854459][ T9784] ? __pfx_hfsplus_delete_all_attrs+0x10/0x10\n[ 174.854469][ T9784] ? rcu_is_watching+0x12/0xc0\n[ 174.854476][ T9784] ? __mark_inode_dirty+0x29e/0xe40\n[ 174.854483][ T9784] hfsplus_delete_cat+0x845/0xde0\n[ 174.854493][ T9784] ? __pfx_hfsplus_delete_cat+0x10/0x10\n[ 174.854507][ T9784] hfsplus_unlink+0x1ca/0x7c0\n[ 174.854516][ T9784] ? __pfx_hfsplus_unlink+0x10/0x10\n[ 174.854525][ T9784] ? down_write+0x148/0x200\n[ 174.854532][ T9784] ? __pfx_down_write+0x10/0x10\n[ 174.854540][ T9784] vfs_unlink+0x2fe/0x9b0\n[ 174.854549][ T9784] do_unlinkat+0x490/0x670\n[ 174.854557][ T9784] ? __pfx_do_unlinkat+0x10/0x10\n[ 174.854565][ T9784] ? __might_fault+0xbc/0x130\n[ 174.854576][ T9784] ? getname_flags.part.0+0x1c5/0x550\n[ 174.854584][ T9784] __x64_sys_unlink+0xc5/0x110\n[ 174.854592][ T9784] do_syscall_64+0xc9/0x480\n[ 174.854600][ T9784] entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[ 174.854608][ T9784] RIP: 0033:0x7f6fdf4c3167\n[ 174.854614][ T9784] Code: f0 ff ff 73 01 c3 48 8b 0d 26 0d 0e 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 08\n[ 174.854622][ T9784] RSP: 002b:00007ffcb948bca8 EFLAGS: 00000206 ORIG_RAX: 0000000000000057\n[ 174.854630][ T9784] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f6fdf4c3167\n[ 174.854636][ T9784] RDX: 00007ffcb948bcc0 RSI: 00007ffcb948bcc0 RDI: 00007ffcb948bd50\n[ 174.854641][ T9784] RBP: 00007ffcb948cd90 R08: 0000000000000001 R09: 00007ffcb948bb40\n[ 174.854645][ T9784] R10: 00007f6fdf564fc0 R11: 0000000000000206 R12: 0000561e1bc9c2d0\n[ 174.854650][ T9784] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n[ 174.854658][ T9784] \u0026lt;/TASK\u0026gt;\n[ 174.854661][ T9784]\n[ 174.879281][ T9784] Allocated by task 9784:\n[ 174.879664][ T9784] kasan_save_stack+0x20/0x40\n[ 174.880082][ T9784] kasan_save_track+0x14/0x30\n[ 174.880500][ T9784] __kasan_kmalloc+0xaa/0xb0\n[ 174.880908][ T9784] __kmalloc_noprof+0x205/0x550\n[ 174.881337][ T9784] __hfs_bnode_create+0x107/0x890\n[ 174.881779][ T9784] hfsplus_bnode_find+0x2d0/0xd10\n[ 174.882222][ T9784] hfsplus_brec_find+0x2b0/0x520\n[ 174.882659][ T9784] hfsplus_delete_all_attrs+0x23b/0x3\n---truncated---(CVE-2025-38714)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/buffer: fix use-after-free when call bh_read() helper\n\nThere\u0026apos;s issue as follows:\nBUG: KASAN: stack-out-of-bounds in end_buffer_read_sync+0xe3/0x110\nRead of size 8 at addr ffffc9000168f7f8 by task swapper/3/0\nCPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.16.0-862.14.0.6.x86_64\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996)\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n dump_stack_lvl+0x55/0x70\n print_address_description.constprop.0+0x2c/0x390\n print_report+0xb4/0x270\n kasan_report+0xb8/0xf0\n end_buffer_read_sync+0xe3/0x110\n end_bio_bh_io_sync+0x56/0x80\n blk_update_request+0x30a/0x720\n scsi_end_request+0x51/0x2b0\n scsi_io_completion+0xe3/0x480\n ? scsi_device_unbusy+0x11e/0x160\n blk_complete_reqs+0x7b/0x90\n handle_softirqs+0xef/0x370\n irq_exit_rcu+0xa5/0xd0\n sysvec_apic_timer_interrupt+0x6e/0x90\n \u0026lt;/IRQ\u0026gt;\n\n Above issue happens when do ntfs3 filesystem mount, issue may happens\n as follows:\n mount IRQ\nntfs_fill_super\n read_cache_page\n do_read_cache_folio\n filemap_read_folio\n mpage_read_folio\n\t do_mpage_readpage\n\t ntfs_get_block_vbo\n\t bh_read\n\t submit_bh\n\t wait_on_buffer(bh);\n\t blk_complete_reqs\n\t\t\t\t scsi_io_completion\n\t\t\t\t scsi_end_request\n\t\t\t\t blk_update_request\n\t\t\t\t end_bio_bh_io_sync\n\t\t\t\t\t end_buffer_read_sync\n\t\t\t\t\t __end_buffer_read_notouch\n\t\t\t\t\t unlock_buffer\n\n wait_on_buffer(bh);--\u0026gt; return will return to caller\n\n\t\t\t\t\t put_bh\n\t\t\t\t\t --\u0026gt; trigger stack-out-of-bounds\nIn the mpage_read_folio() function, the stack variable \u0026apos;map_bh\u0026apos; is\npassed to ntfs_get_block_vbo(). Once unlock_buffer() unlocks and\nwait_on_buffer() returns to continue processing, the stack variable\nis likely to be reclaimed. Consequently, during the end_buffer_read_sync()\nprocess, calling put_bh() may result in stack overrun.\n\nIf the bh is not allocated on the stack, it belongs to a folio. Freeing\na buffer head which belongs to a folio is done by drop_buffers() which\nwill fail to free buffers which are still locked. So it is safe to call\nput_bh() before __end_buffer_read_notouch().(CVE-2025-39691)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup()\n\nA soft lockup warning was observed on a relative small system x86-64\nsystem with 16 GB of memory when running a debug kernel with kmemleak\nenabled.\n\n watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134]\n\nThe test system was running a workload with hot unplug happening in\nparallel. Then kemleak decided to disable itself due to its inability to\nallocate more kmemleak objects. The debug kernel has its\nCONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000.\n\nThe soft lockup happened in kmemleak_do_cleanup() when the existing\nkmemleak objects were being removed and deleted one-by-one in a loop via a\nworkqueue. In this particular case, there are at least 40,000 objects\nthat need to be processed and given the slowness of a debug kernel and the\nfact that a raw_spinlock has to be acquired and released in\n__delete_object(), it could take a while to properly handle all these\nobjects.\n\nAs kmemleak has been disabled in this case, the object removal and\ndeletion process can be further optimized as locking isn\u0026apos;t really needed. \nHowever, it is probably not worth the effort to optimize for such an edge\ncase that should rarely happen. So the simple solution is to call\ncond_resched() at periodic interval in the iteration loop to avoid soft\nlockup.(CVE-2025-39737)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: use array_index_nospec with indices that come from guest\n\nmin and dest_id are guest-controlled indices. Using array_index_nospec()\nafter the bounds checks clamps these values to mitigate speculative execution\nside-channels.(CVE-2025-39823)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbatman-adv: fix OOB read/write in network-coding decode\n\nbatadv_nc_skb_decode_packet() trusts coded_len and checks only against\nskb-\u0026gt;len. XOR starts at sizeof(struct batadv_unicast_packet), reducing\npayload headroom, and the source skb length is not verified, allowing an\nout-of-bounds read and a small out-of-bounds write.\n\nValidate that coded_len fits within the payload area of both destination\nand source sk_buffs before XORing.(CVE-2025-39839)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\num: virtio_uml: Fix use-after-free after put_device in probe\n\nWhen register_virtio_device() fails in virtio_uml_probe(),\nthe code sets vu_dev-\u0026gt;registered = 1 even though\nthe device was not successfully registered.\nThis can lead to use-after-free or other issues.(CVE-2025-39951)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: add max boundary check for VF filters\n\nThere is no check for max filters that VF can request. Add it.(CVE-2025-39968)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vmwgfx: Fix Use-after-free in validation\n\nNodes stored in the validation duplicates hashtable come from an arena\nallocator that is cleared at the end of vmw_execbuf_process. All nodes\nare expected to be cleared in vmw_validation_drop_ht but this node escaped\nbecause its resource was destroyed prematurely.(CVE-2025-40111)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npid: Add a judgment for ns null in pid_nr_ns\n\n__task_pid_nr_ns\n ns = task_active_pid_ns(current);\n pid_nr_ns(rcu_dereference(*task_pid_ptr(task, type)), ns);\n if (pid \u0026amp;\u0026amp; ns-\u0026gt;level \u0026lt;= pid-\u0026gt;level) {\n\nSometimes null is returned for task_active_pid_ns. Then it will trigger kernel panic in pid_nr_ns.\n\nFor example:\n\tUnable to handle kernel NULL pointer dereference at virtual address 0000000000000058\n\tMem abort info:\n\tESR = 0x0000000096000007\n\tEC = 0x25: DABT (current EL), IL = 32 bits\n\tSET = 0, FnV = 0\n\tEA = 0, S1PTW = 0\n\tFSC = 0x07: level 3 translation fault\n\tData abort info:\n\tISV = 0, ISS = 0x00000007, ISS2 = 0x00000000\n\tCM = 0, WnR = 0, TnD = 0, TagAccess = 0\n\tGCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n\tuser pgtable: 4k pages, 39-bit VAs, pgdp=00000002175aa000\n\t[0000000000000058] pgd=08000002175ab003, p4d=08000002175ab003, pud=08000002175ab003, pmd=08000002175be003, pte=0000000000000000\n\tpstate: 834000c5 (Nzcv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--)\n\tpc : __task_pid_nr_ns+0x74/0xd0\n\tlr : __task_pid_nr_ns+0x24/0xd0\n\tsp : ffffffc08001bd10\n\tx29: ffffffc08001bd10 x28: ffffffd4422b2000 x27: 0000000000000001\n\tx26: ffffffd442821168 x25: ffffffd442821000 x24: 00000f89492eab31\n\tx23: 00000000000000c0 x22: ffffff806f5693c0 x21: ffffff806f5693c0\n\tx20: 0000000000000001 x19: 0000000000000000 x18: 0000000000000000\n\tx17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 00000000023a1adc\n\tx14: 0000000000000003 x13: 00000000007ef6d8 x12: 001167c391c78800\n\tx11: 00ffffffffffffff x10: 0000000000000000 x9 : 0000000000000001\n\tx8 : ffffff80816fa3c0 x7 : 0000000000000000 x6 : 49534d702d535449\n\tx5 : ffffffc080c4c2c0 x4 : ffffffd43ee128c8 x3 : ffffffd43ee124dc\n\tx2 : 0000000000000000 x1 : 0000000000000001 x0 : ffffff806f5693c0\n\tCall trace:\n\t__task_pid_nr_ns+0x74/0xd0\n\t...\n\t__handle_irq_event_percpu+0xd4/0x284\n\thandle_irq_event+0x48/0xb0\n\thandle_fasteoi_irq+0x160/0x2d8\n\tgeneric_handle_domain_irq+0x44/0x60\n\tgic_handle_irq+0x4c/0x114\n\tcall_on_irq_stack+0x3c/0x74\n\tdo_interrupt_handler+0x4c/0x84\n\tel1_interrupt+0x34/0x58\n\tel1h_64_irq_handler+0x18/0x24\n\tel1h_64_irq+0x68/0x6c\n\taccount_kernel_stack+0x60/0x144\n\texit_task_stack_account+0x1c/0x80\n\tdo_exit+0x7e4/0xaf8\n\t...\n\tget_signal+0x7bc/0x8d8\n\tdo_notify_resume+0x128/0x828\n\tel0_svc+0x6c/0x70\n\tel0t_64_sync_handler+0x68/0xbc\n\tel0t_64_sync+0x1a8/0x1ac\n\tCode: 35fffe54 911a02a8 f9400108 b4000128 (b9405a69)\n\t---[ end trace 0000000000000000 ]---\n\tKernel panic - not syncing: Oops: Fatal exception in interrupt(CVE-2025-40178)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: sg: Do not sleep in atomic context\n\nsg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may\nsleep. Hence, call sg_finish_rem_req() with interrupts enabled instead\nof disabled.(CVE-2025-40259)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()\n\nIf the allocation of tl_hba-\u0026gt;sh fails in tcm_loop_driver_probe() and we\nattempt to dereference it in tcm_loop_tpg_address_show() we will get a\nsegfault, see below for an example. So, check tl_hba-\u0026gt;sh before\ndereferencing it.\n\n Unable to allocate struct scsi_host\n BUG: kernel NULL pointer dereference, address: 0000000000000194\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: 0000 [#1] PREEMPT SMP NOPTI\n CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1\n Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024\n RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop]\n...\n Call Trace:\n \u0026lt;TASK\u0026gt;\n configfs_read_iter+0x12d/0x1d0 [configfs]\n vfs_read+0x1b5/0x300\n ksys_read+0x6f/0xf0\n...(CVE-2025-68229)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nregulator: core: Protect regulator_supply_alias_list with regulator_list_mutex\n\nregulator_supply_alias_list was accessed without any locking in\nregulator_supply_alias(), regulator_register_supply_alias(), and\nregulator_unregister_supply_alias(). Concurrent registration,\nunregistration and lookups can race, leading to:\n\n1 use-after-free if an alias entry is removed while being read,\n2 duplicate entries when two threads register the same alias,\n3 inconsistent alias mappings observed by consumers.\n\nProtect all traversals, insertions and deletions on\nregulator_supply_alias_list with the existing regulator_list_mutex.(CVE-2025-68354)\n\nA use-after-free vulnerability exists in the mlxsw spectrum multicast route component of Linux Kernel. The vulnerability occurs when updating multicast route statistics, where an instance of list entry deletion during route replace was missed from mutex protection, potentially leading to use-after-free.(CVE-2025-68800)\n\nA reference counting management vulnerability exists in the mlxsw: spectrum_router driver component of the Linux kernel. The driver stores a pointer to a neighbour object without properly holding a reference to it. A reference is only taken when the neighbour is used by a nexthop. This inconsistent reference counting scheme can lead to a situation where, under specific conditions (e.g., during network device event handling), the driver attempts to access a neighbour object that has already been freed, triggering a use-after-free error. An attacker could potentially exploit this vulnerability to cause a kernel crash, thereby affecting system availability.(CVE-2025-68801)\n\nAn off-by-one vulnerability exists in the Intel Ethernet Virtual Function (iavf) driver of the Linux kernel. The flaw resides in the `iavf_config_rss_reg()` function. When configuring the Receive Side Scaling (RSS) hash key and lookup table, incorrect loop boundary conditions (using `\u0026lt;=` instead of `\u0026lt;`) lead to out-of-bounds reads from allocated memory and potential out-of-bounds writes to device registers. An attacker could potentially exploit this vulnerability to cause kernel information disclosure, system instability, or crashes.(CVE-2025-71087)\n\nIn the Linux kernel, a buffer overflow vulnerability exists in the e1000 network driver\u0026apos;s e1000_tbi_should_accept() function. The function reads the last byte of the frame via \u0026apos;data[length - 1]\u0026apos; to evaluate the TBI (Tunnel Bypass Identifier) workaround. If the descriptor-reported length is zero or larger than the actual RX buffer size, this read goes out of bounds and can hit unrelated slab objects. The issue is observed from the NAPI receive path (e1000_clean_rx_irq). The root cause is that the TBI check unconditionally dereferences the last byte without validating the reported length first. The fix rejects the frame early if the length is zero or exceeds adapter-\u0026gt;rx_buffer_len, preserving the TBI workaround semantics for valid frames and preventing touching memory beyond the RX buffer.(CVE-2025-71093)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timer\n\nWhen advancing the target expiration for the guest\u0026apos;s APIC timer in periodic\nmode, set the expiration to \u0026quot;now\u0026quot; if the target expiration is in the past\n(similar to what is done in update_target_expiration()). Blindly adding\nthe period to the previous target expiration can result in KVM generating\na practically unbounded number of hrtimer IRQs due to programming an\nexpired timer over and over. In extreme scenarios, e.g. if userspace\npauses/suspends a VM for an extended duration, this can even cause hard\nlockups in the host.\n\nCurrently, the bug only affects Intel CPUs when using the hypervisor timer\n(HV timer), a.k.a. the VMX preemption timer. Unlike the software timer,\na.k.a. hrtimer, which KVM keeps running even on exits to userspace, the\nHV timer only runs while the guest is active. As a result, if the vCPU\ndoes not run for an extended duration, there will be a huge gap between\nthe target expiration and the current time the vCPU resumes running.\nBecause the target expiration is incremented by only one period on each\ntimer expiration, this leads to a series of timer expirations occurring\nrapidly after the vCPU/VM resumes.\n\nMore critically, when the vCPU first triggers a periodic HV timer\nexpiration after resuming, advancing the expiration by only one period\nwill result in a target expiration in the past. As a result, the delta\nmay be calculated as a negative value. When the delta is converted into\nan absolute value (tscdeadline is an unsigned u64), the resulting value\ncan overflow what the HV timer is capable of programming. I.e. the large\nvalue will exceed the VMX Preemption Timer\u0026apos;s maximum bit width of\ncpu_preemption_timer_multi + 32, and thus cause KVM to switch from the\nHV timer to the software timer (hrtimers).\n\nAfter switching to the software timer, periodic timer expiration callbacks\nmay be executed consecutively within a single clock interrupt handler,\nbecause hrtimers honors KVM\u0026apos;s request for an expiration in the past and\nimmediately re-invokes KVM\u0026apos;s callback after reprogramming. And because\nthe interrupt handler runs with IRQs disabled, restarting KVM\u0026apos;s hrtimer\nover and over until the target expiration is advanced to \u0026quot;now\u0026quot; can result\nin a hard lockup.\n\nE.g. the following hard lockup was triggered in the host when running a\nWindows VM (only relevant because it used the APIC timer in periodic mode)\nafter resuming the VM from a long suspend (in the host).\n\n NMI watchdog: Watchdog detected hard LOCKUP on cpu 45\n ...\n RIP: 0010:advance_periodic_target_expiration+0x4d/0x80 [kvm]\n ...\n RSP: 0018:ff4f88f5d98d8ef0 EFLAGS: 00000046\n RAX: fff0103f91be678e RBX: fff0103f91be678e RCX: 00843a7d9e127bcc\n RDX: 0000000000000002 RSI: 0052ca4003697505 RDI: ff440d5bfbdbd500\n RBP: ff440d5956f99200 R08: ff2ff2a42deb6a84 R09: 000000000002a6c0\n R10: 0122d794016332b3 R11: 0000000000000000 R12: ff440db1af39cfc0\n R13: ff440db1af39cfc0 R14: ffffffffc0d4a560 R15: ff440db1af39d0f8\n FS: 00007f04a6ffd700(0000) GS:ff440db1af380000(0000) knlGS:000000e38a3b8000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000000d5651feff8 CR3: 000000684e038002 CR4: 0000000000773ee0\n PKRU: 55555554\n Call Trace:\n \u0026lt;IRQ\u0026gt;\n apic_timer_fn+0x31/0x50 [kvm]\n __hrtimer_run_queues+0x100/0x280\n hrtimer_interrupt+0x100/0x210\n ? ttwu_do_wakeup+0x19/0x160\n smp_apic_timer_interrupt+0x6a/0x130\n apic_timer_interrupt+0xf/0x20\n \u0026lt;/IRQ\u0026gt;\n\nMoreover, if the suspend duration of the virtual machine is not long enough\nto trigger a hard lockup in this scenario, since commit 98c25ead5eda\n(\u0026quot;KVM: VMX: Move preemption timer \u0026lt;=\u0026gt; hrtimer dance to common x86\u0026quot;), KVM\nwill continue using the software timer until the guest reprograms the APIC\ntimer in some way. Since the periodic timer does not require frequent APIC\ntimer register programming, the guest may continue to use the software\ntimer in \n---truncated---(CVE-2025-71104)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Do not register unsupported perf events\n\nSynthetic events currently do not have a function to register perf events.\nThis leads to calling the tracepoint register functions with a NULL\nfunction pointer which triggers:\n\n ------------[ cut here ]------------\n WARNING: kernel/tracepoint.c:175 at tracepoint_add_func+0x357/0x370, CPU#2: perf/2272\n Modules linked in: kvm_intel kvm irqbypass\n CPU: 2 UID: 0 PID: 2272 Comm: perf Not tainted 6.18.0-ftest-11964-ge022764176fc-dirty #323 PREEMPTLAZY\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014\n RIP: 0010:tracepoint_add_func+0x357/0x370\n Code: 28 9c e8 4c 0b f5 ff eb 0f 4c 89 f7 48 c7 c6 80 4d 28 9c e8 ab 89 f4 ff 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc \u0026lt;0f\u0026gt; 0b 49 c7 c6 ea ff ff ff e9 ee fe ff ff 0f 0b e9 f9 fe ff ff 0f\n RSP: 0018:ffffabc0c44d3c40 EFLAGS: 00010246\n RAX: 0000000000000001 RBX: ffff9380aa9e4060 RCX: 0000000000000000\n RDX: 000000000000000a RSI: ffffffff9e1d4a98 RDI: ffff937fcf5fd6c8\n RBP: 0000000000000001 R08: 0000000000000007 R09: ffff937fcf5fc780\n R10: 0000000000000003 R11: ffffffff9c193910 R12: 000000000000000a\n R13: ffffffff9e1e5888 R14: 0000000000000000 R15: ffffabc0c44d3c78\n FS: 00007f6202f5f340(0000) GS:ffff93819f00f000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000055d3162281a8 CR3: 0000000106a56003 CR4: 0000000000172ef0\n Call Trace:\n \u0026lt;TASK\u0026gt;\n tracepoint_probe_register+0x5d/0x90\n synth_event_reg+0x3c/0x60\n perf_trace_event_init+0x204/0x340\n perf_trace_init+0x85/0xd0\n perf_tp_event_init+0x2e/0x50\n perf_try_init_event+0x6f/0x230\n ? perf_event_alloc+0x4bb/0xdc0\n perf_event_alloc+0x65a/0xdc0\n __se_sys_perf_event_open+0x290/0x9f0\n do_syscall_64+0x93/0x7b0\n ? entry_SYSCALL_64_after_hwframe+0x76/0x7e\n ? trace_hardirqs_off+0x53/0xc0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nInstead, have the code return -ENODEV, which doesn\u0026apos;t warn and has perf\nerror out with:\n\n # perf record -e synthetic:futex_wait\nError:\nThe sys_perf_event_open() syscall returned with 19 (No such device) for event (synthetic:futex_wait).\n\u0026quot;dmesg | grep -i perf\u0026quot; may provide additional information.\n\nIdeally perf should support synthetic events, but for now just fix the\nwarning. The support can come later.(CVE-2025-71125)",
"id": "OESA-2026-1275",
"modified": "2026-08-06T11:10:18Z",
"published": "2026-01-30T11:10:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1275"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49157"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50583"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50737"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53680"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53794"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-54263"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37740"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37768"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38051"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38102"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38103"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38111"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38342"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38697"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38705"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38712"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38713"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38714"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39691"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39737"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39823"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39839"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39951"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39968"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40111"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40178"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40259"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68229"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68354"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68800"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68801"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71087"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71093"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71104"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71125"
}
],
"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-49157",
"CVE-2022-50583",
"CVE-2022-50737",
"CVE-2023-53680",
"CVE-2023-53794",
"CVE-2023-54263",
"CVE-2025-37740",
"CVE-2025-37768",
"CVE-2025-38051",
"CVE-2025-38102",
"CVE-2025-38103",
"CVE-2025-38111",
"CVE-2025-38342",
"CVE-2025-38697",
"CVE-2025-38705",
"CVE-2025-38712",
"CVE-2025-38713",
"CVE-2025-38714",
"CVE-2025-39691",
"CVE-2025-39737",
"CVE-2025-39823",
"CVE-2025-39839",
"CVE-2025-39951",
"CVE-2025-39968",
"CVE-2025-40111",
"CVE-2025-40178",
"CVE-2025-40259",
"CVE-2025-68229",
"CVE-2025-68354",
"CVE-2025-68800",
"CVE-2025-68801",
"CVE-2025-71087",
"CVE-2025-71093",
"CVE-2025-71104",
"CVE-2025-71125"
]
}
OPENSUSE-SU-2025:20091-1
Vulnerability from csaf_opensuse - Published: 2025-11-26 17:04 - Updated: 2025-11-26 17:04SUSE-SU-2025:21040-1
Vulnerability from csaf_suse - Published: 2025-11-13 15:32 - Updated: 2025-11-13 15:32Sightings
| 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.
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.