Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2025-37789 (GCVE-0-2025-37789)
Vulnerability from cvelistv5 – Published: 2025-05-01 13:07 – Updated: 2026-08-05 11:57| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
ccb1352e76cff0524e7ccb2074826a092dd13016 , < 54c6957d1123a2032099b9eab51c314800f677ce
(git)
Affected: ccb1352e76cff0524e7ccb2074826a092dd13016 , < 7fcaec0b2ab8fa5fbf0b45e5512364a168f445bd (git) Affected: ccb1352e76cff0524e7ccb2074826a092dd13016 , < a27526e6b48eee9e2d82efff502c4f272f1a91d4 (git) Affected: ccb1352e76cff0524e7ccb2074826a092dd13016 , < 1489c195c8eecd262aa6712761ba5288203e28ec (git) Affected: ccb1352e76cff0524e7ccb2074826a092dd13016 , < 824a7c2df5127b2402b68a21a265d413e78dcad7 (git) Affected: ccb1352e76cff0524e7ccb2074826a092dd13016 , < be80768d4f3b6fd13f421451cc3fee8778aba8bc (git) Affected: ccb1352e76cff0524e7ccb2074826a092dd13016 , < 03d7262dd53e8c404da35cc81aaa887fd901f76b (git) Affected: ccb1352e76cff0524e7ccb2074826a092dd13016 , < 65d91192aa66f05710cfddf6a14b5a25ee554dba (git) |
guessed | |
| Linux | Linux |
Affected:
3.3
Unaffected: 0 , < 3.3 (semver) Unaffected: 5.4.293 , ≤ 5.4.* (semver) Unaffected: 5.10.237 , ≤ 5.10.* (semver) Unaffected: 5.15.181 , ≤ 5.15.* (semver) Unaffected: 6.1.135 , ≤ 6.1.* (semver) Unaffected: 6.6.88 , ≤ 6.6.* (semver) Unaffected: 6.12.25 , ≤ 6.12.* (semver) Unaffected: 6.14.4 , ≤ 6.14.* (semver) Unaffected: 6.15 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2025-11-03T19:55:14.808Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html"
},
{
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html"
}
],
"title": "CVE Program Container"
},
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2025-37789",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-06-10T20:41:41.618677Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-06-11T18:44:15.185Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"net/openvswitch/flow_netlink.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "54c6957d1123a2032099b9eab51c314800f677ce",
"status": "affected",
"version": "ccb1352e76cff0524e7ccb2074826a092dd13016",
"versionType": "git"
},
{
"lessThan": "7fcaec0b2ab8fa5fbf0b45e5512364a168f445bd",
"status": "affected",
"version": "ccb1352e76cff0524e7ccb2074826a092dd13016",
"versionType": "git"
},
{
"lessThan": "a27526e6b48eee9e2d82efff502c4f272f1a91d4",
"status": "affected",
"version": "ccb1352e76cff0524e7ccb2074826a092dd13016",
"versionType": "git"
},
{
"lessThan": "1489c195c8eecd262aa6712761ba5288203e28ec",
"status": "affected",
"version": "ccb1352e76cff0524e7ccb2074826a092dd13016",
"versionType": "git"
},
{
"lessThan": "824a7c2df5127b2402b68a21a265d413e78dcad7",
"status": "affected",
"version": "ccb1352e76cff0524e7ccb2074826a092dd13016",
"versionType": "git"
},
{
"lessThan": "be80768d4f3b6fd13f421451cc3fee8778aba8bc",
"status": "affected",
"version": "ccb1352e76cff0524e7ccb2074826a092dd13016",
"versionType": "git"
},
{
"lessThan": "03d7262dd53e8c404da35cc81aaa887fd901f76b",
"status": "affected",
"version": "ccb1352e76cff0524e7ccb2074826a092dd13016",
"versionType": "git"
},
{
"lessThan": "65d91192aa66f05710cfddf6a14b5a25ee554dba",
"status": "affected",
"version": "ccb1352e76cff0524e7ccb2074826a092dd13016",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/openvswitch/flow_netlink.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "3.3"
},
{
"lessThan": "3.3",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.293",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.237",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.181",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.135",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.88",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.25",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.14.*",
"status": "unaffected",
"version": "6.14.4",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.15",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.293",
"versionStartIncluding": "3.3",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.237",
"versionStartIncluding": "3.3",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.181",
"versionStartIncluding": "3.3",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.135",
"versionStartIncluding": "3.3",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.88",
"versionStartIncluding": "3.3",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.25",
"versionStartIncluding": "3.3",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.14.4",
"versionStartIncluding": "3.3",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.15",
"versionStartIncluding": "3.3",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: openvswitch: fix nested key length validation in the set() action\n\nIt\u0027s not safe to access nla_len(ovs_key) if the data is smaller than\nthe netlink header. Check that the attribute is OK first."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7.8,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:L - The vulnerability is reached only through a crafted generic-netlink message (OVS_FLOW_CMD_NEW / OVS_PACKET_CMD_EXECUTE) sent on an AF_NETLINK socket by a local process. There is no remote or adjacent-network path into openvswitch flow-action validation.\nAC:L - Triggering requires only a single well-formed netlink message containing an OVS_ACTION_ATTR_SET whose inner nlattr declares nla_len of 1-3; there is no race, no timing window, and no dependence on memory layout the attacker cannot influence. The negative-length path is fully in-bounds and deterministic, and the actions are validated before the datapath lookup so not even a datapath must exist.\nPR:L - The OVS flow genl ops use GENL_UNS_ADMIN_PERM with .netnsok = true, so the CAP_NET_ADMIN check is scoped to the netns\u0027s owning user namespace and any unprivileged user can satisfy it with `unshare -Urn`. The openvswitch module is autoloaded from an unprivileged CTRL_CMD_GETFAMILY lookup via MODULE_ALIAS_GENL_FAMILY.\nUI:N - The attacker performs the entire sequence themselves via socket()/sendmsg(); no action by any other user or administrator is needed.\nS:U - The corruption is confined to kernel memory under the same security authority as the attacking process; no VM, IOMMU, or hypervisor boundary is crossed.\nC:H - The bug produces out-of-bounds reads beyond the netlink skb \u2014 the KMSAN-confirmed header read, the unbounded forward scan in validate_masked() with a negative length, and a memcpy whose source is read for up to SIZE_MAX bytes. Data copied out of bounds lands in the flow\u0027s actions buffer, which is echoed back to userspace by OVS_FLOW_CMD_GET/DUMP, giving an arbitrary kernel-memory disclosure primitive.\nI:H - With key_len underflowing to (size_t)-1, `memcpy(nla_data(at), nla_data(ovs_key), key_len)` and the following `memset(..., 0xff, key_len)` perform an effectively unbounded out-of-bounds write over the kernel heap using attacker-influenced data. An out-of-bounds write of this scope is a full integrity compromise.\nA:H - The wild memcpy/memset will fault as soon as it walks off mapped memory, and the negative-length validate_masked() loop scans up to 4G of memory; either way the result is a kernel panic, and on sanitizer builds it is an immediate KASAN/KMSAN report. The crash is reachable repeatedly by an unprivileged local user."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T11:57:32.820Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/54c6957d1123a2032099b9eab51c314800f677ce"
},
{
"url": "https://git.kernel.org/stable/c/7fcaec0b2ab8fa5fbf0b45e5512364a168f445bd"
},
{
"url": "https://git.kernel.org/stable/c/a27526e6b48eee9e2d82efff502c4f272f1a91d4"
},
{
"url": "https://git.kernel.org/stable/c/1489c195c8eecd262aa6712761ba5288203e28ec"
},
{
"url": "https://git.kernel.org/stable/c/824a7c2df5127b2402b68a21a265d413e78dcad7"
},
{
"url": "https://git.kernel.org/stable/c/be80768d4f3b6fd13f421451cc3fee8778aba8bc"
},
{
"url": "https://git.kernel.org/stable/c/03d7262dd53e8c404da35cc81aaa887fd901f76b"
},
{
"url": "https://git.kernel.org/stable/c/65d91192aa66f05710cfddf6a14b5a25ee554dba"
}
],
"title": "net: openvswitch: fix nested key length validation in the set() action",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-37789",
"datePublished": "2025-05-01T13:07:22.809Z",
"dateReserved": "2025-04-16T04:51:23.940Z",
"dateUpdated": "2026-08-05T11:57:32.820Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2025-37789",
"date": "2026-09-19",
"epss": "0.00208",
"percentile": "0.11223"
},
"microsoft_vex": {
"current_release_date": "2026-02-18T14:13:28.000Z",
"cve": "CVE-2025-37789",
"id": "msrc_CVE-2025-37789",
"initial_release_date": "2025-05-02T00:00:00.000Z",
"product_status:fixed": "2",
"product_status:known_affected": "2",
"source": "Microsoft CSAF VEX",
"status": "final",
"title": "net: openvswitch: fix nested key length validation in the set() action",
"url": "https://msrc.microsoft.com/csaf/vex/2025/msrc_cve-2025-37789.json",
"version": "2"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"net/openvswitch/flow_netlink.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "54c6957d1123a2032099b9eab51c314800f677ce",
"status": "affected",
"version": "ccb1352e76cff0524e7ccb2074826a092dd13016",
"versionType": "git"
},
{
"lessThan": "7fcaec0b2ab8fa5fbf0b45e5512364a168f445bd",
"status": "affected",
"version": "ccb1352e76cff0524e7ccb2074826a092dd13016",
"versionType": "git"
},
{
"lessThan": "a27526e6b48eee9e2d82efff502c4f272f1a91d4",
"status": "affected",
"version": "ccb1352e76cff0524e7ccb2074826a092dd13016",
"versionType": "git"
},
{
"lessThan": "1489c195c8eecd262aa6712761ba5288203e28ec",
"status": "affected",
"version": "ccb1352e76cff0524e7ccb2074826a092dd13016",
"versionType": "git"
},
{
"lessThan": "824a7c2df5127b2402b68a21a265d413e78dcad7",
"status": "affected",
"version": "ccb1352e76cff0524e7ccb2074826a092dd13016",
"versionType": "git"
},
{
"lessThan": "be80768d4f3b6fd13f421451cc3fee8778aba8bc",
"status": "affected",
"version": "ccb1352e76cff0524e7ccb2074826a092dd13016",
"versionType": "git"
},
{
"lessThan": "03d7262dd53e8c404da35cc81aaa887fd901f76b",
"status": "affected",
"version": "ccb1352e76cff0524e7ccb2074826a092dd13016",
"versionType": "git"
},
{
"lessThan": "65d91192aa66f05710cfddf6a14b5a25ee554dba",
"status": "affected",
"version": "ccb1352e76cff0524e7ccb2074826a092dd13016",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/openvswitch/flow_netlink.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "3.3"
},
{
"lessThan": "3.3",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.293",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.237",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.181",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.135",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.88",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.25",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.14.*",
"status": "unaffected",
"version": "6.14.4",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.15",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "6DE62758-5D00-490E-B248-2E4C0507B082",
"versionEndExcluding": "5.4.293",
"versionStartIncluding": "3.3",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "0710B81E-E2FA-4E15-8F68-D297EBB4D50D",
"versionEndExcluding": "5.10.237",
"versionStartIncluding": "5.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "12331C9E-F601-4EFC-899E-369F98DCC70B",
"versionEndExcluding": "5.15.181",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "5B9ACE29-7445-4B6F-B761-6367C005E275",
"versionEndExcluding": "6.1.135",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "6E5947E5-45E3-462A-829B-382B3B1C61BD",
"versionEndExcluding": "6.6.88",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "8E59EE65-FA6B-4AE4-8125-26135E28BF35",
"versionEndExcluding": "6.12.25",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "29FA1A8E-1C2A-4B0B-B397-2C915ECDEDEE",
"versionEndExcluding": "6.14.4",
"versionStartIncluding": "6.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.15:rc1:*:*:*:*:*:*",
"matchCriteriaId": "8D465631-2980-487A-8E65-40AE2B9F8ED1",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.15:rc2:*:*:*:*:*:*",
"matchCriteriaId": "4C9D071F-B28E-46EC-AC61-22B913390211",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
},
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:debian:debian_linux:11.0:*:*:*:*:*:*:*",
"matchCriteriaId": "FA6FEEC2-9F11-4643-8827-749718254FED",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: openvswitch: fix nested key length validation in the set() action\n\nIt\u0027s not safe to access nla_len(ovs_key) if the data is smaller than\nthe netlink header. Check that the attribute is OK first."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: openvswitch: correcci\u00f3n de la validaci\u00f3n de la longitud de la clave anidada en la acci\u00f3n set(). No es seguro acceder a nla_len(ovs_key) si los datos son menores que el encabezado netlink. Compruebe primero que el atributo est\u00e9 correcto."
}
],
"id": "CVE-2025-37789",
"lastModified": "2026-07-30T06:22:20.270",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
},
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9,
"source": "nvd@nist.gov",
"type": "Primary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2025-37789",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-06-10T20:41:41.618677Z",
"version": "2.0.3"
}
}
]
},
"published": "2025-05-01T14:15:43.290",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/03d7262dd53e8c404da35cc81aaa887fd901f76b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/1489c195c8eecd262aa6712761ba5288203e28ec"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/54c6957d1123a2032099b9eab51c314800f677ce"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/65d91192aa66f05710cfddf6a14b5a25ee554dba"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/7fcaec0b2ab8fa5fbf0b45e5512364a168f445bd"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/824a7c2df5127b2402b68a21a265d413e78dcad7"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/a27526e6b48eee9e2d82efff502c4f272f1a91d4"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/be80768d4f3b6fd13f421451cc3fee8778aba8bc"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Mailing List",
"Third Party Advisory"
],
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Mailing List",
"Third Party Advisory"
],
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "NVD-CWE-noinfo"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Moderate",
"current_release_date": "2026-07-30T09:28:51+00:00",
"cve": "CVE-2025-37789",
"id": "CVE-2025-37789",
"initial_release_date": "2025-05-01T00:00:00+00:00",
"product_status:fixed": "1559",
"product_status:known_affected": "188",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: Linux kernel (openvswitch): Denial of Service and limited data exposure via improper key length validation",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2025/cve-2025-37789.json",
"version": "3"
},
"vulnrichment": {
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2025-11-03T19:55:14.808Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html"
},
{
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html"
}
],
"title": "CVE Program Container"
},
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2025-37789",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-06-10T20:41:41.618677Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-06-11T17:38:38.060Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"net/openvswitch/flow_netlink.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "54c6957d1123a2032099b9eab51c314800f677ce",
"status": "affected",
"version": "ccb1352e76cff0524e7ccb2074826a092dd13016",
"versionType": "git"
},
{
"lessThan": "7fcaec0b2ab8fa5fbf0b45e5512364a168f445bd",
"status": "affected",
"version": "ccb1352e76cff0524e7ccb2074826a092dd13016",
"versionType": "git"
},
{
"lessThan": "a27526e6b48eee9e2d82efff502c4f272f1a91d4",
"status": "affected",
"version": "ccb1352e76cff0524e7ccb2074826a092dd13016",
"versionType": "git"
},
{
"lessThan": "1489c195c8eecd262aa6712761ba5288203e28ec",
"status": "affected",
"version": "ccb1352e76cff0524e7ccb2074826a092dd13016",
"versionType": "git"
},
{
"lessThan": "824a7c2df5127b2402b68a21a265d413e78dcad7",
"status": "affected",
"version": "ccb1352e76cff0524e7ccb2074826a092dd13016",
"versionType": "git"
},
{
"lessThan": "be80768d4f3b6fd13f421451cc3fee8778aba8bc",
"status": "affected",
"version": "ccb1352e76cff0524e7ccb2074826a092dd13016",
"versionType": "git"
},
{
"lessThan": "03d7262dd53e8c404da35cc81aaa887fd901f76b",
"status": "affected",
"version": "ccb1352e76cff0524e7ccb2074826a092dd13016",
"versionType": "git"
},
{
"lessThan": "65d91192aa66f05710cfddf6a14b5a25ee554dba",
"status": "affected",
"version": "ccb1352e76cff0524e7ccb2074826a092dd13016",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/openvswitch/flow_netlink.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "3.3"
},
{
"lessThan": "3.3",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.293",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.237",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.181",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.135",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.88",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.25",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.14.*",
"status": "unaffected",
"version": "6.14.4",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.15",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.293",
"versionStartIncluding": "3.3",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.237",
"versionStartIncluding": "3.3",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.181",
"versionStartIncluding": "3.3",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.135",
"versionStartIncluding": "3.3",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.88",
"versionStartIncluding": "3.3",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.25",
"versionStartIncluding": "3.3",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.14.4",
"versionStartIncluding": "3.3",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.15",
"versionStartIncluding": "3.3",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: openvswitch: fix nested key length validation in the set() action\n\nIt\u0027s not safe to access nla_len(ovs_key) if the data is smaller than\nthe netlink header. Check that the attribute is OK first."
}
],
"providerMetadata": {
"dateUpdated": "2026-05-11T21:15:12.473Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/54c6957d1123a2032099b9eab51c314800f677ce"
},
{
"url": "https://git.kernel.org/stable/c/7fcaec0b2ab8fa5fbf0b45e5512364a168f445bd"
},
{
"url": "https://git.kernel.org/stable/c/a27526e6b48eee9e2d82efff502c4f272f1a91d4"
},
{
"url": "https://git.kernel.org/stable/c/1489c195c8eecd262aa6712761ba5288203e28ec"
},
{
"url": "https://git.kernel.org/stable/c/824a7c2df5127b2402b68a21a265d413e78dcad7"
},
{
"url": "https://git.kernel.org/stable/c/be80768d4f3b6fd13f421451cc3fee8778aba8bc"
},
{
"url": "https://git.kernel.org/stable/c/03d7262dd53e8c404da35cc81aaa887fd901f76b"
},
{
"url": "https://git.kernel.org/stable/c/65d91192aa66f05710cfddf6a14b5a25ee554dba"
}
],
"title": "net: openvswitch: fix nested key length validation in the set() action",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-37789",
"datePublished": "2025-05-01T13:07:22.809Z",
"dateReserved": "2025-04-16T04:51:23.940Z",
"dateUpdated": "2026-06-11T18:44:15.185Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
OESA-2025-2122 (CVE-2025-21678)
Vulnerability from osv_openeuler – Published: 2025-09-05 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:
gtp: Destroy device along with udp socket's netns dismantle.
gtp_newlink() links the device to a list in dev_net(dev) instead of src_net, where a udp tunnel socket is created.
Even when src_net is removed, the device stays alive on dev_net(dev). Then, removing src_net triggers the splat below. [0]
In this example, gtp0 is created in ns2, and the udp socket is created in ns1.
ip netns add ns1 ip netns add ns2 ip -n ns1 link add netns ns2 name gtp0 type gtp role sgsn ip netns del ns1
Let's link the device to the socket's netns instead.
Now, gtp_net_exit_batch_rtnl() needs another netdev iteration to remove all gtp devices in the netns.
[0]: ref_tracker: net notrefcnt@000000003d6e7d05 has 1/2 users at sk_alloc (./include/net/net_namespace.h:345 net/core/sock.c:2236) inet_create (net/ipv4/af_inet.c:326 net/ipv4/af_inet.c:252) __sock_create (net/socket.c:1558) udp_sock_create4 (net/ipv4/udp_tunnel_core.c:18) gtp_create_sock (./include/net/udp_tunnel.h:59 drivers/net/gtp.c:1423) gtp_create_sockets (drivers/net/gtp.c:1447) gtp_newlink (drivers/net/gtp.c:1507) rtnl_newlink (net/core/rtnetlink.c:3786 net/core/rtnetlink.c:3897 net/core/rtnetlink.c:4012) rtnetlink_rcv_msg (net/core/rtnetlink.c:6922) netlink_rcv_skb (net/netlink/af_netlink.c:2542) netlink_unicast (net/netlink/af_netlink.c:1321 net/netlink/af_netlink.c:1347) netlink_sendmsg (net/netlink/af_netlink.c:1891) _syssendmsg (net/socket.c:711 net/socket.c:726 net/socket.c:2583) _sys_sendmsg (net/socket.c:2639) __sys_sendmsg (net/socket.c:2669) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)
WARNING: CPU: 1 PID: 60 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179) Modules linked in: CPU: 1 UID: 0 PID: 60 Comm: kworker/u16:2 Not tainted 6.13.0-rc5-00147-g4c1224501e9d #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Workqueue: netns cleanup_net RIP: 0010:ref_tracker_dir_exit (lib/ref_tracker.c:179) Code: 00 00 00 fc ff df 4d 8b 26 49 bd 00 01 00 00 00 00 ad de 4c 39 f5 0f 85 df 00 00 00 48 8b 74 24 08 48 89 df e8 a5 cc 12 02 90 <0f> 0b 90 48 8d 6b 44 be 04 00 00 00 48 89 ef e8 80 de 67 ff 48 89 RSP: 0018:ff11000009a07b60 EFLAGS: 00010286 RAX: 0000000000002bd3 RBX: ff1100000f4e1aa0 RCX: 1ffffffff0e40ac6 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff8423ee3c RBP: ff1100000f4e1af0 R08: 0000000000000001 R09: fffffbfff0e395ae R10: 0000000000000001 R11: 0000000000036001 R12: ff1100000f4e1af0 R13: dead000000000100 R14: ff1100000f4e1af0 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ff1100006ce80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f9b2464bd98 CR3: 0000000005286005 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __warn (kernel/panic.c:748) ? ref_tracker_dir_exit (lib/ref_tracker.c:179) ? report_bug (lib/bug.c:201 lib/bug.c:219) ? handle_bug (arch/x86/kernel/traps.c:285) ? exc_invalid_op (arch/x86/kernel/traps.c:309 (discriminator 1)) ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) ? _raw_spin_unlock_irqrestore (./arch/x86/include/asm/irqflags.h:42 ./arch/x86/include/asm/irqflags.h:97 ./arch/x86/include/asm/irqflags.h:155 ./include/linux/spinlock_api_smp.h:151 kernel/locking/spinlock.c:194) ? ref_tracker_dir_exit (lib/ref_tracker.c:179) ? __pfx_ref_tracker_dir_exit (lib/ref_tracker.c:158) ? kfree (mm/slub.c:4613 mm/slub.c:4761) net_free (net/core/net_namespace.c:476 net/core/net_namespace.c:467) cleanup_net (net/core/net_namespace.c:664 (discriminator 3)) process_one_work (kernel/workqueue.c:3229) worker_thread (kernel/workqueue.c:3304 kernel/workqueue.c:3391 ---truncated---(CVE-2025-21678)
In the Linux kernel, the following vulnerability has been resolved:
scsi: mpi3mr: Fix possible crash when setting up bsg fails
If bsg_setup_queue() fails, the bsg_queue is assigned a non-NULL value. Consequently, in mpi3mr_bsg_exit(), the condition "if(!mrioc->bsg_queue)" will not be satisfied, preventing execution from entering bsg_remove_queue(), which could lead to the following crash:
BUG: kernel NULL pointer dereference, address: 000000000000041c Call Trace: <TASK> mpi3mr_bsg_exit+0x1f/0x50 [mpi3mr] mpi3mr_remove+0x6f/0x340 [mpi3mr] pci_device_remove+0x3f/0xb0 device_release_driver_internal+0x19d/0x220 unbind_store+0xa4/0xb0 kernfs_fop_write_iter+0x11f/0x200 vfs_write+0x1fc/0x3e0 ksys_write+0x67/0xe0 do_syscall_64+0x38/0x80 entry_SYSCALL_64_after_hwframe+0x78/0xe2(CVE-2025-21723)
In the Linux kernel, the following vulnerability has been resolved:
tcp: drop secpath at the same time as we currently drop dst
Xiumei reported hitting the WARN in xfrm6_tunnel_net_exit while running tests that boil down to: - create a pair of netns - run a basic TCP test over ipcomp6 - delete the pair of netns
The xfrm_state found on spi_byaddr was not deleted at the time we delete the netns, because we still have a reference on it. This lingering reference comes from a secpath (which holds a ref on the xfrm_state), which is still attached to an skb. This skb is not leaked, it ends up on sk_receive_queue and then gets defer-free'd by skb_attempt_defer_free.
The problem happens when we defer freeing an skb (push it on one CPU's defer_list), and don't flush that list before the netns is deleted. In that case, we still have a reference on the xfrm_state that we don't expect at this point.
We already drop the skb's dst in the TCP receive path when it's no longer needed, so let's also drop the secpath. At this point, tcp_filter has already called into the LSM hooks that may require the secpath, so it should not be needed anymore. However, in some of those places, the MPTCP extension has just been attached to the skb, so we cannot simply drop all extensions.(CVE-2025-21864)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: prevent connection release during oplock break notification
ksmbd_work could be freed when after connection release. Increment r_count of ksmbd_conn to indicate that requests are not finished yet and to not release the connection.(CVE-2025-21955)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix error code in chan_alloc_skb_cb()
The chan_alloc_skb_cb() function is supposed to return error pointers on error. Returning NULL will lead to a NULL dereference.(CVE-2025-22007)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: socket: Lookup orig tuple for IPv6 SNAT
nf_sk_lookup_slow_v4 does the conntrack lookup for IPv4 packets to restore the original 5-tuple in case of SNAT, to be able to find the right socket (if any). Then socket_match() can correctly check whether the socket was transparent.
However, the IPv6 counterpart (nf_sk_lookup_slow_v6) lacks this conntrack lookup, making xt_socket fail to match on the socket when the packet was SNATed. Add the same logic to nf_sk_lookup_slow_v6.
IPv6 SNAT is used in Kubernetes clusters for pod-to-world packets, as
pods' addresses are in the fd00::/8 ULA subnet and need to be replaced
with the node's external address. Cilium leverages Envoy to enforce L7
policies, and Envoy uses transparent sockets. Cilium inserts an iptables
prerouting rule that matches on -m socket --transparent and redirects
the packets to localhost, but it fails to match SNATed IPv6 packets due
to that missing conntrack lookup.(CVE-2025-22021)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_tunnel: fix geneve_opt type confusion addition
When handling multiple NFTA_TUNNEL_KEY_OPTS_GENEVE attributes, the parsing logic should place every geneve_opt structure one by one compactly. Hence, when deciding the next geneve_opt position, the pointer addition should be in units of char *.
However, the current implementation erroneously does type conversion before the addition, which will lead to heap out-of-bounds write.
[ 6.989857] ================================================================== [ 6.990293] BUG: KASAN: slab-out-of-bounds in nft_tunnel_obj_init+0x977/0xa70 [ 6.990725] Write of size 124 at addr ffff888005f18974 by task poc/178 [ 6.991162] [ 6.991259] CPU: 0 PID: 178 Comm: poc-oob-write Not tainted 6.1.132 #1 [ 6.991655] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 6.992281] Call Trace: [ 6.992423] <TASK> [ 6.992586] dump_stack_lvl+0x44/0x5c [ 6.992801] print_report+0x184/0x4be [ 6.993790] kasan_report+0xc5/0x100 [ 6.994252] kasan_check_range+0xf3/0x1a0 [ 6.994486] memcpy+0x38/0x60 [ 6.994692] nft_tunnel_obj_init+0x977/0xa70 [ 6.995677] nft_obj_init+0x10c/0x1b0 [ 6.995891] nf_tables_newobj+0x585/0x950 [ 6.996922] nfnetlink_rcv_batch+0xdf9/0x1020 [ 6.998997] nfnetlink_rcv+0x1df/0x220 [ 6.999537] netlink_unicast+0x395/0x530 [ 7.000771] netlink_sendmsg+0x3d0/0x6d0 [ 7.001462] __sock_sendmsg+0x99/0xa0 [ 7.001707] _syssendmsg+0x409/0x450 [ 7.002391] _sys_sendmsg+0xfd/0x170 [ 7.003145] __sys_sendmsg+0xea/0x170 [ 7.004359] do_syscall_64+0x5e/0x90 [ 7.005817] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 7.006127] RIP: 0033:0x7ec756d4e407 [ 7.006339] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf [ 7.007364] RSP: 002b:00007ffed5d46760 EFLAGS: 00000202 ORIG_RAX: 000000000000002e [ 7.007827] RAX: ffffffffffffffda RBX: 00007ec756cc4740 RCX: 00007ec756d4e407 [ 7.008223] RDX: 0000000000000000 RSI: 00007ffed5d467f0 RDI: 0000000000000003 [ 7.008620] RBP: 00007ffed5d468a0 R08: 0000000000000000 R09: 0000000000000000 [ 7.009039] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000 [ 7.009429] R13: 00007ffed5d478b0 R14: 00007ec756ee5000 R15: 00005cbd4e655cb8
Fix this bug with correct pointer addition and conversion in parse and dump code.(CVE-2025-22056)
In the Linux kernel, the following vulnerability has been resolved:
net: decrease cached dst counters in dst_release
Upstream fix ac888d58869b ("net: do not delay dst_entries_add() in dst_release()") moved decrementing the dst count from dst_destroy to dst_release to avoid accessing already freed data in case of netns dismantle. However in case CONFIG_DST_CACHE is enabled and OvS+tunnels are used, this fix is incomplete as the same issue will be seen for cached dsts:
Unable to handle kernel paging request at virtual address ffff5aabf6b5c000 Call trace: percpu_counter_add_batch+0x3c/0x160 (P) dst_release+0xec/0x108 dst_cache_destroy+0x68/0xd8 dst_destroy+0x13c/0x168 dst_destroy_rcu+0x1c/0xb0 rcu_do_batch+0x18c/0x7d0 rcu_core+0x174/0x378 rcu_core_si+0x18/0x30
Fix this by invalidating the cache, and thus decrementing cached dst counters, in dst_release too.(CVE-2025-22057)
In the Linux kernel, the following vulnerability has been resolved:
netlabel: Fix NULL pointer exception caused by CALIPSO on IPv4 sockets
When calling netlbl_conn_setattr(), addr->sa_family is used to determine the function behavior. If sk is an IPv4 socket, but the connect function is called with an IPv6 address, the function calipso_sock_setattr() is triggered. Inside this function, the following code is executed:
sk_fullsock(__sk) ? inet_sk(__sk)->pinet6 : NULL;
Since sk is an IPv4 socket, pinet6 is NULL, leading to a null pointer dereference.
This patch fixes the issue by checking if inet6_sk(sk) returns a NULL pointer before accessing pinet6.(CVE-2025-22063)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: don't unregister hook when table is dormant
When nf_tables_updchain encounters an error, hook registration needs to be rolled back.
This should only be done if the hook has been registered, which won't happen when the table is flagged as dormant (inactive).
Just move the assignment into the registration block.(CVE-2025-22064)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Fix mlx5_poll_one() cur_qp update flow
When cur_qp isn't NULL, in order to avoid fetching the QP from the radix tree again we check if the next cqe QP is identical to the one we already have.
The bug however is that we are checking if the QP is identical by checking the QP number inside the CQE against the QP number inside the mlx5_ib_qp, but that's wrong since the QP number from the CQE is from FW so it should be matched against mlx5_core_qp which is our FW QP number.
Otherwise we could use the wrong QP when handling a CQE which could cause the kernel trace below.
This issue is mainly noticeable over QPs 0 & 1, since for now they are the only QPs in our driver whereas the QP number inside mlx5_ib_qp doesn't match the QP number inside mlx5_core_qp.
BUG: kernel NULL pointer dereference, address: 0000000000000012 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP CPU: 0 UID: 0 PID: 7927 Comm: kworker/u62:1 Not tainted 6.14.0-rc3+ #189 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core] RIP: 0010:mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib] Code: 03 00 00 8d 58 ff 21 cb 66 39 d3 74 39 48 c7 c7 3c 89 6e a0 0f b7 db e8 b7 d2 b3 e0 49 8b 86 60 03 00 00 48 c7 c7 4a 89 6e a0 <0f> b7 5c 98 02 e8 9f d2 b3 e0 41 0f b7 86 78 03 00 00 83 e8 01 21 RSP: 0018:ffff88810511bd60 EFLAGS: 00010046 RAX: 0000000000000010 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff88885fa1b3c0 RDI: ffffffffa06e894a RBP: 00000000000000b0 R08: 0000000000000000 R09: ffff88810511bc10 R10: 0000000000000001 R11: 0000000000000001 R12: ffff88810d593000 R13: ffff88810e579108 R14: ffff888105146000 R15: 00000000000000b0 FS: 0000000000000000(0000) GS:ffff88885fa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000012 CR3: 00000001077e6001 CR4: 0000000000370eb0 Call Trace: <TASK> ? __die+0x20/0x60 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x130 ? asm_exc_page_fault+0x22/0x30 ? mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib] __ib_process_cq+0x5a/0x150 [ib_core] ib_cq_poll_work+0x31/0x90 [ib_core] process_one_work+0x169/0x320 worker_thread+0x288/0x3a0 ? work_busy+0xb0/0xb0 kthread+0xd7/0x1f0 ? kthreads_online_cpu+0x130/0x130 ? kthreads_online_cpu+0x130/0x130 ret_from_fork+0x2d/0x50 ? kthreads_online_cpu+0x130/0x130 ret_from_fork_asm+0x11/0x20 </TASK>(CVE-2025-22086)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/core: Don't expose hw_counters outside of init net namespace
Commit 467f432a521a ("RDMA/core: Split port and device counter sysfs attributes") accidentally almost exposed hw counters to non-init net namespaces. It didn't expose them fully, as an attempt to read any of those counters leads to a crash like this one:
[42021.807566] BUG: kernel NULL pointer dereference, address: 0000000000000028 [42021.814463] #PF: supervisor read access in kernel mode [42021.819549] #PF: error_code(0x0000) - not-present page [42021.824636] PGD 0 P4D 0 [42021.827145] Oops: 0000 [#1] SMP PTI [42021.830598] CPU: 82 PID: 2843922 Comm: switchto-defaul Kdump: loaded Tainted: G S W I XXX [42021.841697] Hardware name: XXX [42021.849619] RIP: 0010:hw_stat_device_show+0x1e/0x40 [ib_core] [42021.855362] Code: 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 49 89 d0 4c 8b 5e 20 48 8b 8f b8 04 00 00 48 81 c7 f0 fa ff ff <48> 8b 41 28 48 29 ce 48 83 c6 d0 48 c1 ee 04 69 d6 ab aa aa aa 48 [42021.873931] RSP: 0018:ffff97fe90f03da0 EFLAGS: 00010287 [42021.879108] RAX: ffff9406988a8c60 RBX: ffff940e1072d438 RCX: 0000000000000000 [42021.886169] RDX: ffff94085f1aa000 RSI: ffff93c6cbbdbcb0 RDI: ffff940c7517aef0 [42021.893230] RBP: ffff97fe90f03e70 R08: ffff94085f1aa000 R09: 0000000000000000 [42021.900294] R10: ffff94085f1aa000 R11: ffffffffc0775680 R12: ffffffff87ca2530 [42021.907355] R13: ffff940651602840 R14: ffff93c6cbbdbcb0 R15: ffff94085f1aa000 [42021.914418] FS: 00007fda1a3b9700(0000) GS:ffff94453fb80000(0000) knlGS:0000000000000000 [42021.922423] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [42021.928130] CR2: 0000000000000028 CR3: 00000042dcfb8003 CR4: 00000000003726f0 [42021.935194] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [42021.942257] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [42021.949324] Call Trace: [42021.951756] <TASK> [42021.953842] [<ffffffff86c58674>] ? show_regs+0x64/0x70 [42021.959030] [<ffffffff86c58468>] ? __die+0x78/0xc0 [42021.963874] [<ffffffff86c9ef75>] ? page_fault_oops+0x2b5/0x3b0 [42021.969749] [<ffffffff87674b92>] ? exc_page_fault+0x1a2/0x3c0 [42021.975549] [<ffffffff87801326>] ? asm_exc_page_fault+0x26/0x30 [42021.981517] [<ffffffffc0775680>] ? __pfx_show_hw_stats+0x10/0x10 [ib_core] [42021.988482] [<ffffffffc077564e>] ? hw_stat_device_show+0x1e/0x40 [ib_core] [42021.995438] [<ffffffff86ac7f8e>] dev_attr_show+0x1e/0x50 [42022.000803] [<ffffffff86a3eeb1>] sysfs_kf_seq_show+0x81/0xe0 [42022.006508] [<ffffffff86a11134>] seq_read_iter+0xf4/0x410 [42022.011954] [<ffffffff869f4b2e>] vfs_read+0x16e/0x2f0 [42022.017058] [<ffffffff869f50ee>] ksys_read+0x6e/0xe0 [42022.022073] [<ffffffff8766f1ca>] do_syscall_64+0x6a/0xa0 [42022.027441] [<ffffffff8780013b>] entry_SYSCALL_64_after_hwframe+0x78/0xe2
The problem can be reproduced using the following steps: ip netns add foo ip netns exec foo bash cat /sys/class/infiniband/mlx4_0/hw_counters/*
The panic occurs because of casting the device pointer into an ib_device pointer using container_of() in hw_stat_device_show() is wrong and leads to a memory corruption.
However the real problem is that hw counters should never been exposed outside of the non-init net namespace.
Fix this by saving the index of the corresponding attribute group (it might be 1 or 2 depending on the presence of driver-specific attributes) and zeroing the pointer to hw_counters group for compat devices during the initialization.
With this fix applied hw_counters are not available in a non-init net namespace: find /sys/class/infiniband/mlx4_0/ -name hw_counters /sys/class/infiniband/mlx4_0/ports/1/hw_counters /sys/class/infiniband/mlx4_0/ports/2/hw_counters /sys/class/infiniband/mlx4_0/hw_counters
ip netns add foo ip netns exec foo bash find /sys/class/infiniband/mlx4_0/ -name hw_counters(CVE-2025-22089)
In the Linux kernel, the following vulnerability has been resolved:
vmxnet3: unregister xdp rxq info in the reset path
vmxnet3 does not unregister xdp rxq info in the vmxnet3_reset_work() code path as vmxnet3_rq_destroy() is not invoked in this code path. So, we get below message with a backtrace.
Missing unregister, handled but fix driver WARNING: CPU:48 PID: 500 at net/core/xdp.c:182 __xdp_rxq_info_reg+0x93/0xf0
This patch fixes the problem by moving the unregister code of XDP from vmxnet3_rq_destroy() to vmxnet3_rq_cleanup().(CVE-2025-22106)
In the Linux kernel, the following vulnerability has been resolved:
net: ppp: Add bound checking for skb data on ppp_sync_txmung
Ensure we have enough data in linear buffer from skb before accessing initial bytes. This prevents potential out-of-bounds accesses when processing short packets.
When ppp_sync_txmung receives an incoming package with an empty payload: (remote) gef➤ p (struct pppoe_hdr ) (skb->head + skb->network_header) $18 = { type = 0x1, ver = 0x1, code = 0x0, sid = 0x2, length = 0x0, tag = 0xffff8880371cdb96 }
from the skb struct (trimmed) tail = 0x16, end = 0x140, head = 0xffff88803346f400 "4", data = 0xffff88803346f416 ":\377", truesize = 0x380, len = 0x0, data_len = 0x0, mac_len = 0xe, hdr_len = 0x0,
it is not safe to access data[2].
[(CVE-2025-37749)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: sch_sfq: move the limit validation
It is not sufficient to directly validate the limit on the data that the user passes as it can be updated based on how the other parameters are changed.
Move the check at the end of the configuration update process to also catch scenarios where the limit is indirectly updated, for example with the following configurations:
tc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 depth 1 tc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 divisor 1
This fixes the following syzkaller reported crash:
------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:203:6 index 65535 is out of range for type 'struct sfq_head[128]' CPU: 1 UID: 0 PID: 3037 Comm: syz.2.16 Not tainted 6.14.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x201/0x300 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_out_of_bounds+0xf5/0x120 lib/ubsan.c:429 sfq_link net/sched/sch_sfq.c:203 [inline] sfq_dec+0x53c/0x610 net/sched/sch_sfq.c:231 sfq_dequeue+0x34e/0x8c0 net/sched/sch_sfq.c:493 sfq_reset+0x17/0x60 net/sched/sch_sfq.c:518 qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035 tbf_reset+0x41/0x110 net/sched/sch_tbf.c:339 qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035 dev_reset_queue+0x100/0x1b0 net/sched/sch_generic.c:1311 netdev_for_each_tx_queue include/linux/netdevice.h:2590 [inline] dev_deactivate_many+0x7e5/0xe70 net/sched/sch_generic.c:1375(CVE-2025-37752)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/cma: Fix workqueue crash in cma_netevent_work_handler
struct rdma_cm_id has member "struct work_struct net_work" that is reused for enqueuing cma_netevent_work_handler()s onto cma_wq.
Below crash[1] can occur if more than one call to cma_netevent_callback() occurs in quick succession, which further enqueues cma_netevent_work_handler()s for the same rdma_cm_id, overwriting any previously queued work-item(s) that was just scheduled to run i.e. there is no guarantee the queued work item may run between two successive calls to cma_netevent_callback() and the 2nd INIT_WORK would overwrite the 1st work item (for the same rdma_cm_id), despite grabbing id_table_lock during enqueue.
Also drgn analysis [2] indicates the work item was likely overwritten.
Fix this by moving the INIT_WORK() to __rdma_create_id(), so that it doesn't race with any existing queue_work() or its worker thread.
[1] Trimmed crash stack:
BUG: kernel NULL pointer dereference, address: 0000000000000008 kworker/u256:6 ... 6.12.0-0... Workqueue: cma_netevent_work_handler [rdma_cm] (rdma_cm) RIP: 0010:process_one_work+0xba/0x31a Call Trace: worker_thread+0x266/0x3a0 kthread+0xcf/0x100 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1a/0x30 =============================================
[2] drgn crash analysis:
>>> trace = prog.crashed_thread().stack_trace() >>> trace (0) crash_setup_regs (./arch/x86/include/asm/kexec.h:111:15) (1) __crash_kexec (kernel/crash_core.c:122:4) (2) panic (kernel/panic.c:399:3) (3) oops_end (arch/x86/kernel/dumpstack.c:382:3) ... (8) process_one_work (kernel/workqueue.c:3168:2) (9) process_scheduled_works (kernel/workqueue.c:3310:3) (10) worker_thread (kernel/workqueue.c:3391:4) (11) kthread (kernel/kthread.c:389:9)
Line workqueue.c:3168 for this kernel version is in process_one_work(): 3168 strscpy(worker->desc, pwq->wq->name, WORKER_DESC_LEN);
>>> trace[8]["work"] (struct work_struct )0xffff92577d0a21d8 = { .data = (atomic_long_t){ .counter = (s64)536870912, <=== Note }, .entry = (struct list_head){ .next = (struct list_head )0xffff924d075924c0, .prev = (struct list_head )0xffff924d075924c0, }, .func = (work_func_t)cma_netevent_work_handler+0x0 = 0xffffffffc2cec280, }
Suspicion is that pwq is NULL: >>> trace[8]["pwq"] (struct pool_workqueue *)<absent>
In process_one_work(), pwq is assigned from: struct pool_workqueue *pwq = get_work_pwq(work);
and get_work_pwq() is: static struct pool_workqueue get_work_pwq(struct work_struct work) { unsigned long data = atomic_long_read(&work->data);
if (data & WORK_STRUCT_PWQ)
return work_struct_pwq(data);
else
return NULL;
}
WORK_STRUCT_PWQ is 0x4: >>> print(repr(prog['WORK_STRUCT_PWQ'])) Object(prog, 'enum work_flags', value=4)
But work->data is 536870912 which is 0x20000000. So, get_work_pwq() returns NULL and we crash in process_one_work(): 3168 strscpy(worker->desc, pwq->wq->name, WORKER_DESC_LEN); =============================================(CVE-2025-37772)
In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: fix nested key length validation in the set() action
It's not safe to access nla_len(ovs_key) if the data is smaller than the netlink header. Check that the attribute is OK first.(CVE-2025-37789)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: Purge vif txq in ieee80211_do_stop()
After ieee80211_do_stop() SKB from vif's txq could still be processed. Indeed another concurrent vif schedule_and_wake_txq call could cause those packets to be dequeued (see ieee80211_handle_wake_tx_queue()) without checking the sdata current state.
Because vif.drv_priv is now cleared in this function, this could lead to driver crash.
For example in ath12k, ahvif is store in vif.drv_priv. Thus if ath12k_mac_op_tx() is called after ieee80211_do_stop(), ahvif->ah can be NULL, leading the ath12k_warn(ahvif->ah,...) call in this function to trigger the NULL deref below.
Unable to handle kernel paging request at virtual address dfffffc000000001 KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] batman_adv: bat0: Interface deactivated: brbh1337 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [dfffffc000000001] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP CPU: 1 UID: 0 PID: 978 Comm: lbd Not tainted 6.13.0-g633f875b8f1e #114 Hardware name: HW (DT) pstate: 10000005 (nzcV daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] lr : ath12k_mac_op_tx+0x174/0x29b8 [ath12k] sp : ffffffc086ace450 x29: ffffffc086ace450 x28: 0000000000000000 x27: 1ffffff810d59ca4 x26: ffffff801d05f7c0 x25: 0000000000000000 x24: 000000004000001e x23: ffffff8009ce4926 x22: ffffff801f9c0800 x21: ffffff801d05f7f0 x20: ffffff8034a19f40 x19: 0000000000000000 x18: ffffff801f9c0958 x17: ffffff800bc0a504 x16: dfffffc000000000 x15: ffffffc086ace4f8 x14: ffffff801d05f83c x13: 0000000000000000 x12: ffffffb003a0bf03 x11: 0000000000000000 x10: ffffffb003a0bf02 x9 : ffffff8034a19f40 x8 : ffffff801d05f818 x7 : 1ffffff0069433dc x6 : ffffff8034a19ee0 x5 : ffffff801d05f7f0 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000008 Call trace: ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] (P) ieee80211_handle_wake_tx_queue+0x16c/0x260 ieee80211_queue_skb+0xeec/0x1d20 ieee80211_tx+0x200/0x2c8 ieee80211_xmit+0x22c/0x338 __ieee80211_subif_start_xmit+0x7e8/0xc60 ieee80211_subif_start_xmit+0xc4/0xee0 __ieee80211_subif_start_xmit_8023.isra.0+0x854/0x17a0 ieee80211_subif_start_xmit_8023+0x124/0x488 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 br_dev_queue_push_xmit+0x120/0x4a8 __br_forward+0xe4/0x2b0 deliver_clone+0x5c/0xd0 br_flood+0x398/0x580 br_dev_xmit+0x454/0x9f8 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 ip6_finish_output2+0xc28/0x1b60 __ip6_finish_output+0x38c/0x638 ip6_output+0x1b4/0x338 ip6_local_out+0x7c/0xa8 ip6_send_skb+0x7c/0x1b0 ip6_push_pending_frames+0x94/0xd0 rawv6_sendmsg+0x1a98/0x2898 inet_sendmsg+0x94/0xe0 __sys_sendto+0x1e4/0x308 __arm64_sys_sendto+0xc4/0x140 do_el0_svc+0x110/0x280 el0_svc+0x20/0x60 el0t_64_sync_handler+0x104/0x138 el0t_64_sync+0x154/0x158
To avoid that, empty vif's txq at ieee80211_do_stop() so no packet could be dequeued after ieee80211_do_stop() (new packets cannot be queued because SDATA_STATE_RUNNING is cleared at this point).(CVE-2025-37794)
In the Linux kernel, the following vulnerability has been resolved:
cpufreq: scpi: Fix null-ptr-deref in scpi_cpufreq_get_rate()
cpufreq_cpu_get_raw() can return NULL when the target CPU is not present in the policy->cpus mask. scpi_cpufreq_get_rate() does not check for this case, which results in a NULL pointer dereference.(CVE-2025-37829)
In the Linux kernel, the following vulnerability has been resolved:
mm/vmscan: don't try to reclaim hwpoison folio
Syzkaller reports a bug as follows:
Injecting memory failure for pfn 0x18b00e at process virtual address 0x20ffd000 Memory failure: 0x18b00e: dirty swapcache page still referenced by 2 users Memory failure: 0x18b00e: recovery action for dirty swapcache page: Failed page: refcount:2 mapcount:0 mapping:0000000000000000 index:0x20ffd pfn:0x18b00e memcg:ffff0000dd6d9000 anon flags: 0x5ffffe00482011(locked|dirty|arch_1|swapbacked|hwpoison|node=0|zone=2|lastcpupid=0xfffff) raw: 005ffffe00482011 dead000000000100 dead000000000122 ffff0000e232a7c9 raw: 0000000000020ffd 0000000000000000 00000002ffffffff ffff0000dd6d9000 page dumped because: VM_BUG_ON_FOLIO(!folio_test_uptodate(folio)) ------------[ cut here ]------------ kernel BUG at mm/swap_state.c:184! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP Modules linked in: CPU: 0 PID: 60 Comm: kswapd0 Not tainted 6.6.0-gcb097e7de84e #3 Hardware name: linux,dummy-virt (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : add_to_swap+0xbc/0x158 lr : add_to_swap+0xbc/0x158 sp : ffff800087f37340 x29: ffff800087f37340 x28: fffffc00052c0380 x27: ffff800087f37780 x26: ffff800087f37490 x25: ffff800087f37c78 x24: ffff800087f377a0 x23: ffff800087f37c50 x22: 0000000000000000 x21: fffffc00052c03b4 x20: 0000000000000000 x19: fffffc00052c0380 x18: 0000000000000000 x17: 296f696c6f662865 x16: 7461646f7470755f x15: 747365745f6f696c x14: 6f6621284f494c4f x13: 0000000000000001 x12: ffff600036d8b97b x11: 1fffe00036d8b97a x10: ffff600036d8b97a x9 : dfff800000000000 x8 : 00009fffc9274686 x7 : ffff0001b6c5cbd3 x6 : 0000000000000001 x5 : ffff0000c25896c0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff0000c25896c0 x0 : 0000000000000000 Call trace: add_to_swap+0xbc/0x158 shrink_folio_list+0x12ac/0x2648 shrink_inactive_list+0x318/0x948 shrink_lruvec+0x450/0x720 shrink_node_memcgs+0x280/0x4a8 shrink_node+0x128/0x978 balance_pgdat+0x4f0/0xb20 kswapd+0x228/0x438 kthread+0x214/0x230 ret_from_fork+0x10/0x20
I can reproduce this issue with the following steps:
1) When a dirty swapcache page is isolated by reclaim process and the page isn't locked, inject memory failure for the page. me_swapcache_dirty() clears uptodate flag and tries to delete from lru, but fails. Reclaim process will put the hwpoisoned page back to lru.
2) The process that maps the hwpoisoned page exits, the page is deleted the page will never be freed and will be in the lru forever.
3) If we trigger a reclaim again and tries to reclaim the page, add_to_swap() will trigger VM_BUG_ON_FOLIO due to the uptodate flag is cleared.
To fix it, skip the hwpoisoned page in shrink_folio_list(). Besides, the hwpoison folio may not be unmapped by hwpoison_user_mappings() yet, unmap it in shrink_folio_list(), otherwise the folio will fail to be unmaped by hwpoison_user_mappings() since the folio isn't in lru list.(CVE-2025-37834)
In the Linux kernel, the following vulnerability has been resolved:
page_pool: avoid infinite loop to schedule delayed worker
We noticed the kworker in page_pool_release_retry() was waken up repeatedly and infinitely in production because of the buggy driver causing the inflight less than 0 and warning us in page_pool_inflight()[1].
Since the inflight value goes negative, it means we should not expect the whole page_pool to get back to work normally.
This patch mitigates the adverse effect by not rescheduling the kworker when detecting the inflight negative in page_pool_release_retry().
[1] [Mon Feb 10 20:36:11 2025] ------------[ cut here ]------------ [Mon Feb 10 20:36:11 2025] Negative(-51446) inflight packet-pages ... [Mon Feb 10 20:36:11 2025] Call Trace: [Mon Feb 10 20:36:11 2025] page_pool_release_retry+0x23/0x70 [Mon Feb 10 20:36:11 2025] process_one_work+0x1b1/0x370 [Mon Feb 10 20:36:11 2025] worker_thread+0x37/0x3a0 [Mon Feb 10 20:36:11 2025] kthread+0x11a/0x140 [Mon Feb 10 20:36:11 2025] ? process_one_work+0x370/0x370 [Mon Feb 10 20:36:11 2025] ? __kthread_cancel_work+0x40/0x40 [Mon Feb 10 20:36:11 2025] ret_from_fork+0x35/0x40 [Mon Feb 10 20:36:11 2025] ---[ end trace ebffe800f33e7e34 ]--- Note: before this patch, the above calltrace would flood the dmesg due to repeated reschedule of release_dw kworker.(CVE-2025-37859)
In the Linux kernel, the following vulnerability has been resolved:
igc: fix PTM cycle trigger logic
Writing to clear the PTM status 'valid' bit while the PTM cycle is triggered results in unreliable PTM operation. To fix this, clear the PTM 'trigger' and status after each PTM transaction.
The issue can be reproduced with the following:
$ sudo phc2sys -R 1000 -O 0 -i tsn0 -m
Note: 1000 Hz (-R 1000) is unrealistically large, but provides a way to quickly reproduce the issue.
PHC2SYS exits with:
"ioctl PTP_OFFSET_PRECISE: Connection timed out" when the PTM transaction fails
This patch also fixes a hang in igc_probe() when loading the igc driver in the kdump kernel on systems supporting PTM.
The igc driver running in the base kernel enables PTM trigger in igc_probe(). Therefore the driver is always in PTM trigger mode, except in brief periods when manually triggering a PTM cycle.
When a crash occurs, the NIC is reset while PTM trigger is enabled. Due to a hardware problem, the NIC is subsequently in a bad busmaster state and doesn't handle register reads/writes. When running igc_probe() in the kdump kernel, the first register access to a NIC register hangs driver probing and ultimately breaks kdump.
With this patch, igc has PTM trigger disabled most of the time, and the trigger is only enabled for very brief (10 - 100 us) periods when manually triggering a PTM cycle. Chances that a crash occurs during a PTM trigger are not 0, but extremely reduced.(CVE-2025-37875)
In the Linux kernel, the following vulnerability has been resolved:
9p/net: fix improper handling of bogus negative read/write replies
In p9_client_write() and p9_client_read_once(), if the server incorrectly replies with success but a negative write/read count then we would consider written (negative) <= rsize (positive) because both variables were signed.
Make variables unsigned to avoid this problem.
The reproducer linked below now fails with the following error instead of a null pointer deref: 9pnet: bogus RWRITE count (4294967295 > 3)(CVE-2025-37879)
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Reset IRTE to host control if new route isn't postable
Restore an IRTE back to host control (remapped or posted MSI mode) if the new GSI route prevents posting the IRQ directly to a vCPU, regardless of the GSI routing type. Updating the IRTE if and only if the new GSI is an MSI results in KVM leaving an IRTE posting to a vCPU.
The dangling IRTE can result in interrupts being incorrectly delivered to the guest, and in the worst case scenario can result in use-after-free, e.g. if the VM is torn down, but the underlying host IRQ isn't freed.(CVE-2025-37885)
In the Linux kernel, the following vulnerability has been resolved:
net: lan743x: Fix memleak issue when GSO enabled
Always map the skb to the LS descriptor. Previously skb was
mapped to EXT descriptor when the number of fragments is zero with
GSO enabled. Mapping the skb to EXT descriptor prevents it from
being freed, leading to a memory leak(CVE-2025-37909)
In the Linux kernel, the following vulnerability has been resolved:
bnxt_en: Fix out-of-bound memcpy() during ethtool -w
When retrieving the FW coredump using ethtool, it can sometimes cause memory corruption:
BUG: KFENCE: memory corruption in __bnxt_get_coredump+0x3ef/0x670 [bnxt_en] Corrupted memory at 0x000000008f0f30e8 [ ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ] (in kfence-#45): __bnxt_get_coredump+0x3ef/0x670 [bnxt_en] ethtool_get_dump_data+0xdc/0x1a0 __dev_ethtool+0xa1e/0x1af0 dev_ethtool+0xa8/0x170 dev_ioctl+0x1b5/0x580 sock_do_ioctl+0xab/0xf0 sock_ioctl+0x1ce/0x2e0 __x64_sys_ioctl+0x87/0xc0 do_syscall_64+0x5c/0xf0 entry_SYSCALL_64_after_hwframe+0x78/0x80
...
This happens when copying the coredump segment list in bnxt_hwrm_dbg_dma_data() with the HWRM_DBG_COREDUMP_LIST FW command. The info->dest_buf buffer is allocated based on the number of coredump segments returned by the FW. The segment list is then DMA'ed by the FW and the length of the DMA is returned by FW. The driver then copies this DMA'ed segment list to info->dest_buf.
In some cases, this DMA length may exceed the info->dest_buf length and cause the above BUG condition. Fix it by capping the copy length to not exceed the length of info->dest_buf. The extra DMA data contains no useful information.
This code path is shared for the HWRM_DBG_COREDUMP_LIST and the HWRM_DBG_COREDUMP_RETRIEVE FW commands. The buffering is different for these 2 FW commands. To simplify the logic, we need to move the line to adjust the buffer length for HWRM_DBG_COREDUMP_RETRIEVE up, so that the new check to cap the copy length will work for both commands.(CVE-2025-37911)
In the Linux kernel, the following vulnerability has been resolved:
ice: Check VF VSI Pointer Value in ice_vc_add_fdir_fltr()
As mentioned in the commit baeb705fd6a7 ("ice: always check VF VSI pointer values"), we need to perform a null pointer check on the return value of ice_get_vf_vsi() before using it.(CVE-2025-37912)
In the Linux kernel, the following vulnerability has been resolved:
sch_htb: make htb_qlen_notify() idempotent
htb_qlen_notify() always deactivates the HTB class and in fact could trigger a warning if it is already deactivated. Therefore, it is not idempotent and not friendly to its callers, like fq_codel_dequeue().
Let's make it idempotent to ease qdisc_tree_reduce_backlog() callers' life.(CVE-2025-37932)
In the Linux kernel, the following vulnerability has been resolved:
net: phy: allow MDIO bus PM ops to start/stop state machine for phylink-controlled PHY
DSA has 2 kinds of drivers:
- Those who call dsa_switch_suspend() and dsa_switch_resume() from their device PM ops: qca8k-8xxx, bcm_sf2, microchip ksz
- Those who don't: all others. The above methods should be optional.
For type 1, dsa_switch_suspend() calls dsa_user_suspend() -> phylink_stop(), and dsa_switch_resume() calls dsa_user_resume() -> phylink_start(). These seem good candidates for setting mac_managed_pm = true because that is essentially its definition [1], but that does not seem to be the biggest problem for now, and is not what this change focuses on.
Talking strictly about the 2nd category of DSA drivers here (which do not have MAC managed PM, meaning that for their attached PHYs, mdio_bus_phy_suspend() and mdio_bus_phy_resume() should run in full), I have noticed that the following warning from mdio_bus_phy_resume() is triggered:
WARN_ON(phydev->state != PHY_HALTED && phydev->state != PHY_READY &&
phydev->state != PHY_UP);
because the PHY state machine is running.
It's running as a result of a previous dsa_user_open() -> ... -> phylink_start() -> phy_start() having been initiated by the user.
The previous mdio_bus_phy_suspend() was supposed to have called phy_stop_machine(), but it didn't. So this is why the PHY is in state PHY_NOLINK by the time mdio_bus_phy_resume() runs.
mdio_bus_phy_suspend() did not call phy_stop_machine() because for phylink, the phydev->adjust_link function pointer is NULL. This seems a technicality introduced by commit fddd91016d16 ("phylib: fix PAL state machine restart on resume"). That commit was written before phylink existed, and was intended to avoid crashing with consumer drivers which don't use the PHY state machine - phylink always does, when using a PHY. But phylink itself has historically not been developed with suspend/resume in mind, and apparently not tested too much in that scenario, allowing this bug to exist unnoticed for so long. Plus, prior to the WARN_ON(), it would have likely been invisible.
This issue is not in fact restricted to type 2 DSA drivers (according to the above ad-hoc classification), but can be extrapolated to any MAC driver with phylink and MDIO-bus-managed PHY PM ops. DSA is just where the issue was reported. Assuming mac_managed_pm is set correctly, a quick search indicates the following other drivers might be affected:
$ grep -Zlr PHYLINK_NETDEV drivers/ | xargs -0 grep -L mac_managed_pm drivers/net/ethernet/atheros/ag71xx.c drivers/net/ethernet/microchip/sparx5/sparx5_main.c drivers/net/ethernet/microchip/lan966x/lan966x_main.c drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c drivers/net/ethernet/freescale/dpaa/dpaa_eth.c drivers/net/ethernet/freescale/ucc_geth.c drivers/net/ethernet/freescale/enetc/enetc_pf_common.c drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c drivers/net/ethernet/marvell/mvneta.c drivers/net/ethernet/marvell/prestera/prestera_main.c drivers/net/ethernet/mediatek/mtk_eth_soc.c drivers/net/ethernet/altera/altera_tse_main.c drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c drivers/net/ethernet/meta/fbnic/fbnic_phylink.c drivers/net/ethernet/tehuti/tn40_phy.c drivers/net/ethernet/mscc/ocelot_net.c
Make the existing conditions dependent on the PHY device having a phydev->phy_link_change() implementation equal to the default phy_link_change() provided by phylib. Otherwise, we implicitly know that the phydev has the phylink-provided phylink_phy_change() callback, and when phylink is used, the PHY state machine always needs to be stopped/ started on the suspend/resume path. The code is structured as such that if phydev->phy_link_change() is absent, it is a matter of time until the kernel will crash - no need to further complicate the test.
Thus, for the situation where the PM is not managed b ---truncated---(CVE-2025-37945)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Scrub packet on bpf_redirect_peer
When bpf_redirect_peer is used to redirect packets to a device in another network namespace, the skb isn't scrubbed. That can lead skb information from one namespace to be "misused" in another namespace.
As one example, this is causing Cilium to drop traffic when using bpf_redirect_peer to redirect packets that just went through IPsec decryption to a container namespace. The following pwru trace shows (1) the packet path from the host's XFRM layer to the container's XFRM layer where it's dropped and (2) the number of active skb extensions at each function.
NETNS MARK IFACE TUPLE FUNC
4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 xfrm_rcv_cb
.active_extensions = (__u8)2,
4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 xfrm4_rcv_cb
.active_extensions = (__u8)2,
4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 gro_cells_receive
.active_extensions = (__u8)2,
[...]
4026533547 0 eth0 10.244.3.124:35473->10.244.2.158:53 skb_do_redirect
.active_extensions = (__u8)2,
4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 ip_rcv
.active_extensions = (__u8)2,
4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 ip_rcv_core
.active_extensions = (__u8)2,
[...]
4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 udp_queue_rcv_one_skb
.active_extensions = (__u8)2,
4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 __xfrm_policy_check
.active_extensions = (__u8)2,
4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 __xfrm_decode_session
.active_extensions = (__u8)2,
4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 security_xfrm_decode_session
.active_extensions = (__u8)2,
4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 kfree_skb_reason(SKB_DROP_REASON_XFRM_POLICY)
.active_extensions = (__u8)2,
In this case, there are no XFRM policies in the container's network namespace so the drop is unexpected. When we decrypt the IPsec packet, the XFRM state used for decryption is set in the skb extensions. This information is preserved across the netns switch. When we reach the XFRM policy check in the container's netns, __xfrm_policy_check drops the packet with LINUX_MIB_XFRMINNOPOLS because a (container-side) XFRM policy can't be found that matches the (host-side) XFRM state used for decryption.
This patch fixes this by scrubbing the packet when using bpf_redirect_peer, as is done on typical netns switches via veth devices except skb->mark and skb->tstamp are not zeroed.(CVE-2025-37959)
In the Linux kernel, the following vulnerability has been resolved:
memblock: Accept allocated memory before use in memblock_double_array()
When increasing the array size in memblock_double_array() and the slab is not yet available, a call to memblock_find_in_range() is used to reserve/allocate memory. However, the range returned may not have been accepted, which can result in a crash when booting an SNP guest:
RIP: 0010:memcpy_orig+0x68/0x130 Code: ... RSP: 0000:ffffffff9cc03ce8 EFLAGS: 00010006 RAX: ff11001ff83e5000 RBX: 0000000000000000 RCX: fffffffffffff000 RDX: 0000000000000bc0 RSI: ffffffff9dba8860 RDI: ff11001ff83e5c00 RBP: 0000000000002000 R08: 0000000000000000 R09: 0000000000002000 R10: 000000207fffe000 R11: 0000040000000000 R12: ffffffff9d06ef78 R13: ff11001ff83e5000 R14: ffffffff9dba7c60 R15: 0000000000000c00 memblock_double_array+0xff/0x310 memblock_add_range+0x1fb/0x2f0 memblock_reserve+0x4f/0xa0 memblock_alloc_range_nid+0xac/0x130 memblock_alloc_internal+0x53/0xc0 memblock_alloc_try_nid+0x3d/0xa0 swiotlb_init_remap+0x149/0x2f0 mem_init+0xb/0xb0 mm_core_init+0x8f/0x350 start_kernel+0x17e/0x5d0 x86_64_start_reservations+0x14/0x30 x86_64_start_kernel+0x92/0xa0 secondary_startup_64_no_verify+0x194/0x19b
Mitigate this by calling accept_memory() on the memory range returned before the slab is available.
Prior to v6.12, the accept_memory() interface used a 'start' and 'end' parameter instead of 'start' and 'size', therefore the accept_memory() call must be adjusted to specify 'start + size' for 'end' when applying to kernels prior to v6.12.(CVE-2025-37960)
In the Linux kernel, the following vulnerability has been resolved:
ipvs: fix uninit-value for saddr in do_output_route4
syzbot reports for uninit-value for the saddr argument [1]. commit 4754957f04f5 ("ipvs: do not use random local source address for tunnels") already implies that the input value of saddr should be ignored but the code is still reading it which can prevent to connect the route. Fix it by changing the argument to ret_saddr.
[1] BUG: KMSAN: uninit-value in do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147 do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147 __ip_vs_get_out_rt+0x403/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:330 ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136 ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118 ip_local_out net/ipv4/ip_output.c:127 [inline] ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501 udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195 udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x267/0x380 net/socket.c:727 _syssendmsg+0x91b/0xda0 net/socket.c:2566 _sys_sendmsg+0x28d/0x3c0 net/socket.c:2620 __sys_sendmmsg+0x41d/0x880 net/socket.c:2702 __compat_sys_sendmmsg net/compat.c:360 [inline] __do_compat_sys_sendmmsg net/compat.c:367 [inline] __se_compat_sys_sendmmsg net/compat.c:364 [inline] __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364 ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369 entry_SYSENTER_compat_after_hwframe+0x84/0x8e
Uninit was created at: slab_post_alloc_hook mm/slub.c:4167 [inline] slab_alloc_node mm/slub.c:4210 [inline] __kmalloc_cache_noprof+0x8fa/0xe00 mm/slub.c:4367 kmalloc_noprof include/linux/slab.h:905 [inline] ip_vs_dest_dst_alloc net/netfilter/ipvs/ip_vs_xmit.c:61 [inline] __ip_vs_get_out_rt+0x35d/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:323 ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136 ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118 ip_local_out net/ipv4/ip_output.c:127 [inline] ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501 udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195 udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x267/0x380 net/socket.c:727 _syssendmsg+0x91b/0xda0 net/socket.c:2566 _sys_sendmsg+0x28d/0x3c0 net/socket.c:2620 __sys_sendmmsg+0x41d/0x880 net/socket.c:2702 __compat_sys_sendmmsg net/compat.c:360 [inline] __do_compat_sys_sendmmsg net/compat.c:367 [inline] __se_compat_sys_sendmmsg net/compat.c:364 [inline] __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364 ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369 entry_SYSENTER_compat_after_hwframe+0x84/0x8e
CPU: 0 UID: 0 PID: 22408 Comm: syz.4.5165 Not tainted 6.15.0-rc3-syzkaller-00019-gbc3372351d0c #0 PREEMPT(undef) Hardware name: Google Google Compute Engi ---truncated---(CVE-2025-37961)
In the Linux kernel, the following vulnerability has been resolved:
net: phy: leds: fix memory leak
A network restart test on a router led to an out-of-memory condition, which was traced to a memory leak in the PHY LED trigger code.
The root cause is misuse of the devm API. The registration function (phy_led_triggers_register) is called from phy_attach_direct, not phy_probe, and the unregister function (phy_led_triggers_unregister) is called from phy_detach, not phy_remove. This means the register and unregister functions can be called multiple times for the same PHY device, but devm-allocated memory is not freed until the driver is unbound.
This also prevents kmemleak from detecting the leak, as the devm API internally stores the allocated pointer.
Fix this by replacing devm_kzalloc/devm_kcalloc with standard kzalloc/kcalloc, and add the corresponding kfree calls in the unregister path.(CVE-2025-37989)
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcm80211: fmac: Add error handling for brcmf_usb_dl_writeimage()
The function brcmf_usb_dl_writeimage() calls the function brcmf_usb_dl_cmd() but dose not check its return value. The 'state.state' and the 'state.bytes' are uninitialized if the function brcmf_usb_dl_cmd() fails. It is dangerous to use uninitialized variables in the conditions.
Add error handling for brcmf_usb_dl_cmd() to jump to error handling path if the brcmf_usb_dl_cmd() fails and the 'state.state' and the 'state.bytes' are uninitialized.
Improve the error message to report more detailed error information.(CVE-2025-37990)
In the Linux kernel, the following vulnerability has been resolved:
can: bcm: add missing rcu read protection for procfs content
When the procfs content is generated for a bcm_op which is in the process to be removed the procfs output might show unreliable data (UAF).
As the removal of bcm_op's is already implemented with rcu handling this patch adds the missing rcu_read_lock() and makes sure the list entries are properly removed under rcu protection.(CVE-2025-38003)
In the Linux kernel, the following vulnerability has been resolved:
can: bcm: add locking for bcm_op runtime updates
The CAN broadcast manager (CAN BCM) can send a sequence of CAN frames via hrtimer. The content and also the length of the sequence can be changed resp reduced at runtime where the 'currframe' counter is then set to zero.
Although this appeared to be a safe operation the updates of 'currframe' can be triggered from user space and hrtimer context in bcm_can_tx(). Anderson Nascimento created a proof of concept that triggered a KASAN slab-out-of-bounds read access which can be prevented with a spin_lock_bh.
At the rework of bcm_can_tx() the 'count' variable has been moved into the protected section as this variable can be modified from both contexts too.(CVE-2025-38004)
In the Linux kernel, the following vulnerability has been resolved:
phy: tegra: xusb: Use a bitmask for UTMI pad power state tracking
The current implementation uses bias_pad_enable as a reference count to manage the shared bias pad for all UTMI PHYs. However, during system suspension with connected USB devices, multiple power-down requests for the UTMI pad result in a mismatch in the reference count, which in turn produces warnings such as:
[ 237.762967] WARNING: CPU: 10 PID: 1618 at tegra186_utmi_pad_power_down+0x160/0x170 [ 237.763103] Call trace: [ 237.763104] tegra186_utmi_pad_power_down+0x160/0x170 [ 237.763107] tegra186_utmi_phy_power_off+0x10/0x30 [ 237.763110] phy_power_off+0x48/0x100 [ 237.763113] tegra_xusb_enter_elpg+0x204/0x500 [ 237.763119] tegra_xusb_suspend+0x48/0x140 [ 237.763122] platform_pm_suspend+0x2c/0xb0 [ 237.763125] dpm_run_callback.isra.0+0x20/0xa0 [ 237.763127] __device_suspend+0x118/0x330 [ 237.763129] dpm_suspend+0x10c/0x1f0 [ 237.763130] dpm_suspend_start+0x88/0xb0 [ 237.763132] suspend_devices_and_enter+0x120/0x500 [ 237.763135] pm_suspend+0x1ec/0x270
The root cause was traced back to the dynamic power-down changes introduced in commit a30951d31b25 ("xhci: tegra: USB2 pad power controls"), where the UTMI pad was being powered down without verifying its current state. This unbalanced behavior led to discrepancies in the reference count.
To rectify this issue, this patch replaces the single reference counter with a bitmask, renamed to utmi_pad_enabled. Each bit in the mask corresponds to one of the four USB2 PHYs, allowing us to track each pad's enablement status individually.
With this change: - The bias pad is powered on only when the mask is clear. - Each UTMI pad is powered on or down based on its corresponding bit in the mask, preventing redundant operations. - The overall power state of the shared bias pad is maintained correctly during suspend/resume cycles.
The mutex used to prevent race conditions during UTMI pad enable/disable operations has been moved from the tegra186_utmi_bias_pad_power_on/off functions to the parent functions tegra186_utmi_pad_power_on/down. This change ensures that there are no race conditions when updating the bitmask.(CVE-2025-38010)
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_router: Fix use-after-free when deleting GRE net devices
The driver only offloads neighbors that are constructed on top of net devices registered by it or their uppers (which are all Ethernet). The device supports GRE encapsulation and decapsulation of forwarded traffic, but the driver will not offload dummy neighbors constructed on top of GRE net devices as they are not uppers of its net devices:
# ip link add name gre1 up type gre tos inherit local 192.0.2.1 remote 198.51.100.1 # ip neigh add 0.0.0.0 lladdr 0.0.0.0 nud noarp dev gre1 $ ip neigh show dev gre1 nud noarp 0.0.0.0 lladdr 0.0.0.0 NOARP
(Note that the neighbor is not marked with 'offload')
When the driver is reloaded and the existing configuration is replayed, the driver does not perform the same check regarding existing neighbors and offloads the previously added one:
# devlink dev reload pci/0000:01:00.0 $ ip neigh show dev gre1 nud noarp 0.0.0.0 lladdr 0.0.0.0 offload NOARP
If the neighbor is later deleted, the driver will ignore the notification (given the GRE net device is not its upper) and will therefore keep referencing freed memory, resulting in a use-after-free [1] when the net device is deleted:
# ip neigh del 0.0.0.0 lladdr 0.0.0.0 dev gre1 # ip link del dev gre1
Fix by skipping neighbor replay if the net device for which the replay is performed is not our upper.
[1] BUG: KASAN: slab-use-after-free in mlxsw_sp_neigh_entry_update+0x1ea/0x200 Read of size 8 at addr ffff888155b0e420 by task ip/2282 [...] Call Trace: <TASK> dump_stack_lvl+0x6f/0xa0 print_address_description.constprop.0+0x6f/0x350 print_report+0x108/0x205 kasan_report+0xdf/0x110 mlxsw_sp_neigh_entry_update+0x1ea/0x200 mlxsw_sp_router_rif_gone_sync+0x2a8/0x440 mlxsw_sp_rif_destroy+0x1e9/0x750 mlxsw_sp_netdevice_ipip_ol_event+0x3c9/0xdc0 mlxsw_sp_router_netdevice_event+0x3ac/0x15e0 notifier_call_chain+0xca/0x150 call_netdevice_notifiers_info+0x7f/0x100 unregister_netdevice_many_notify+0xc8c/0x1d90 rtnl_dellink+0x34e/0xa50 rtnetlink_rcv_msg+0x6fb/0xb70 netlink_rcv_skb+0x131/0x360 netlink_unicast+0x426/0x710 netlink_sendmsg+0x75a/0xc20 __sock_sendmsg+0xc1/0x150 _syssendmsg+0x5aa/0x7b0 _sys_sendmsg+0xfc/0x180 __sys_sendmsg+0x121/0x1b0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53(CVE-2025-38019)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Disable MACsec offload for uplink representor profile
MACsec offload is not supported in switchdev mode for uplink representors. When switching to the uplink representor profile, the MACsec offload feature must be cleared from the netdevice's features.
If left enabled, attempts to add offloads result in a null pointer dereference, as the uplink representor does not support MACsec offload even though the feature bit remains set.
Clear NETIF_F_HW_MACSEC in mlx5e_fix_uplink_rep_features().
Kernel log:
Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f] CPU: 29 UID: 0 PID: 4714 Comm: ip Not tainted 6.14.0-rc4_for_upstream_debug_2025_03_02_17_35 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__mutex_lock+0x128/0x1dd0 Code: d0 7c 08 84 d2 0f 85 ad 15 00 00 8b 35 91 5c fe 03 85 f6 75 29 49 8d 7e 60 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 a6 15 00 00 4d 3b 76 60 0f 85 fd 0b 00 00 65 ff RSP: 0018:ffff888147a4f160 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000001 RDX: 000000000000000f RSI: 0000000000000000 RDI: 0000000000000078 RBP: ffff888147a4f2e0 R08: ffffffffa05d2c19 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: dffffc0000000000 R14: 0000000000000018 R15: ffff888152de0000 FS: 00007f855e27d800(0000) GS:ffff88881ee80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000004e5768 CR3: 000000013ae7c005 CR4: 0000000000372eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 Call Trace: <TASK> ? die_addr+0x3d/0xa0 ? exc_general_protection+0x144/0x220 ? asm_exc_general_protection+0x22/0x30 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] ? __mutex_lock+0x128/0x1dd0 ? lockdep_set_lock_cmp_fn+0x190/0x190 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] ? mutex_lock_io_nested+0x1ae0/0x1ae0 ? lock_acquire+0x1c2/0x530 ? macsec_upd_offload+0x145/0x380 ? lockdep_hardirqs_on_prepare+0x400/0x400 ? kasan_save_stack+0x30/0x40 ? kasan_save_stack+0x20/0x40 ? kasan_save_track+0x10/0x30 ? __kasan_kmalloc+0x77/0x90 ? __kmalloc_noprof+0x249/0x6b0 ? genl_family_rcv_msg_attrs_parse.constprop.0+0xb5/0x240 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] ? mlx5e_macsec_add_rxsa+0x11a0/0x11a0 [mlx5_core] macsec_update_offload+0x26c/0x820 ? macsec_set_mac_address+0x4b0/0x4b0 ? lockdep_hardirqs_on_prepare+0x284/0x400 ? _raw_spin_unlock_irqrestore+0x47/0x50 macsec_upd_offload+0x2c8/0x380 ? macsec_update_offload+0x820/0x820 ? __nla_parse+0x22/0x30 ? genl_family_rcv_msg_attrs_parse.constprop.0+0x15e/0x240 genl_family_rcv_msg_doit+0x1cc/0x2a0 ? genl_family_rcv_msg_attrs_parse.constprop.0+0x240/0x240 ? cap_capable+0xd4/0x330 genl_rcv_msg+0x3ea/0x670 ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0 ? lockdep_set_lock_cmp_fn+0x190/0x190 ? macsec_update_offload+0x820/0x820 netlink_rcv_skb+0x12b/0x390 ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0 ? netlink_ack+0xd80/0xd80 ? rwsem_down_read_slowpath+0xf90/0xf90 ? netlink_deliver_tap+0xcd/0xac0 ? netlink_deliver_tap+0x155/0xac0 ? _copy_from_iter+0x1bb/0x12c0 genl_rcv+0x24/0x40 netlink_unicast+0x440/0x700 ? netlink_attachskb+0x760/0x760 ? lock_acquire+0x1c2/0x530 ? __might_fault+0xbb/0x170 netlink_sendmsg+0x749/0xc10 ? netlink_unicast+0x700/0x700 ? __might_fault+0xbb/0x170 ? netlink_unicast+0x700/0x700 __sock_sendmsg+0xc5/0x190 _syssendmsg+0x53f/0x760 ? import_iovec+0x7/0x10 ? kernel_sendmsg+0x30/0x30 ? copy_msghdr+0x3c0/0x3c0 ? filter_irq_stacks+0x90/0x90 ? stack_depot_save_flags+0x28/0xa30 ___sys_sen ---truncated---(CVE-2025-38020)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/core: Fix "KASAN: slab-use-after-free Read in ib_register_device" problem
Call Trace:
__dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 strlen+0x93/0xa0 lib/string.c:420 __fortify_strlen include/linux/fortify-string.h:268 [inline] get_kobj_path_length lib/kobject.c:118 [inline] kobject_get_path+0x3f/0x2a0 lib/kobject.c:158 kobject_uevent_env+0x289/0x1870 lib/kobject_uevent.c:545 ib_register_device drivers/infiniband/core/device.c:1472 [inline] ib_register_device+0x8cf/0xe00 drivers/infiniband/core/device.c:1393 rxe_register_device+0x275/0x320 drivers/infiniband/sw/rxe/rxe_verbs.c:1552 rxe_net_add+0x8e/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:550 rxe_newlink+0x70/0x190 drivers/infiniband/sw/rxe/rxe.c:225 nldev_newlink+0x3a3/0x680 drivers/infiniband/core/nldev.c:1796 rdma_nl_rcv_msg+0x387/0x6e0 drivers/infiniband/core/netlink.c:195 rdma_nl_rcv_skb.constprop.0.isra.0+0x2e5/0x450 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] _syssendmsg+0xa95/0xc70 net/socket.c:2566 _sys_sendmsg+0x134/0x1d0 net/socket.c:2620 __sys_sendmsg+0x16d/0x220 net/socket.c:2652 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f
This problem is similar to the problem that the commit 1d6a9e7449e2 ("RDMA/core: Fix use-after-free when rename device name") fixes.
The root cause is: the function ib_device_rename() renames the name with lock. But in the function kobject_uevent(), this name is accessed without lock protection at the same time.
The solution is to add the lock protection when this name is accessed in the function kobject_uevent().(CVE-2025-38022)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bug
Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x7d/0xa0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcf/0x610 mm/kasan/report.c:489 kasan_report+0xb5/0xe0 mm/kasan/report.c:602 rxe_queue_cleanup+0xd0/0xe0 drivers/infiniband/sw/rxe/rxe_queue.c:195 rxe_cq_cleanup+0x3f/0x50 drivers/infiniband/sw/rxe/rxe_cq.c:132 __rxe_cleanup+0x168/0x300 drivers/infiniband/sw/rxe/rxe_pool.c:232 rxe_create_cq+0x22e/0x3a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1109 create_cq+0x658/0xb90 drivers/infiniband/core/uverbs_cmd.c:1052 ib_uverbs_create_cq+0xc7/0x120 drivers/infiniband/core/uverbs_cmd.c:1095 ib_uverbs_write+0x969/0xc90 drivers/infiniband/core/uverbs_main.c:679 vfs_write fs/read_write.c:677 [inline] vfs_write+0x26a/0xcc0 fs/read_write.c:659 ksys_write+0x1b8/0x200 fs/read_write.c:731 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
In the function rxe_create_cq, when rxe_cq_from_init fails, the function rxe_cleanup will be called to handle the allocated resources. In fact, some memory resources have already been freed in the function rxe_cq_from_init. Thus, this problem will occur.
The solution is to let rxe_cleanup do all the work.(CVE-2025-38024)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Avoid WARN_ON when configuring MQPRIO with HTB offload enabled
When attempting to enable MQPRIO while HTB offload is already
configured, the driver currently returns -EINVAL and triggers a
WARN_ON, leading to an unnecessary call trace.
Update the code to handle this case more gracefully by returning
-EOPNOTSUPP instead, while also providing a helpful user message.(CVE-2025-38039)
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: ti: k3-udma-glue: Drop skip_fdq argument from k3_udma_glue_reset_rx_chn
The user of k3_udma_glue_reset_rx_chn() e.g. ti_am65_cpsw_nuss can run on multiple platforms having different DMA architectures. On some platforms there can be one FDQ for all flows in the RX channel while for others there is a separate FDQ for each flow in the RX channel.
So far we have been relying on the skip_fdq argument of k3_udma_glue_reset_rx_chn().
Instead of relying on the user to provide this information, infer it based on DMA architecture during k3_udma_glue_request_rx_chn() and save it in an internal flag 'single_fdq'. Use that flag at k3_udma_glue_reset_rx_chn() to deicide if the FDQ needs to be cleared for every flow or just for flow 0.
Fixes the below issue on ti_am65_cpsw_nuss driver on AM62-SK.
> ip link set eth1 down > ip link set eth0 down > ethtool -L eth0 rx 8 > ip link set eth0 up > modprobe -r ti_am65_cpsw_nuss
[ 103.045726] ------------[ cut here ]------------ [ 103.050505] k3_knav_desc_pool size 512000 != avail 64000 [ 103.050703] WARNING: CPU: 1 PID: 450 at drivers/net/ethernet/ti/k3-cppi-desc-pool.c:33 k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool] [ 103.068810] Modules linked in: ti_am65_cpsw_nuss(-) k3_cppi_desc_pool snd_soc_hdmi_codec crct10dif_ce snd_soc_simple_card snd_soc_simple_card_utils display_connector rtc_ti_k3 k3_j72xx_bandgap tidss drm_client_lib snd_soc_davinci_mcas p drm_dma_helper tps6598x phylink snd_soc_ti_udma rti_wdt drm_display_helper snd_soc_tlv320aic3x_i2c typec at24 phy_gmii_sel snd_soc_ti_edma snd_soc_tlv320aic3x sii902x snd_soc_ti_sdma sa2ul omap_mailbox drm_kms_helper authenc cfg80211 r fkill fuse drm drm_panel_orientation_quirks backlight ip_tables x_tables ipv6 [last unloaded: k3_cppi_desc_pool] [ 103.119950] CPU: 1 UID: 0 PID: 450 Comm: modprobe Not tainted 6.13.0-rc7-00001-g9c5e3435fa66 #1011 [ 103.119968] Hardware name: Texas Instruments AM625 SK (DT) [ 103.119974] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 103.119983] pc : k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool] [ 103.148007] lr : k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool] [ 103.154709] sp : ffff8000826ebbc0 [ 103.158015] x29: ffff8000826ebbc0 x28: ffff0000090b6300 x27: 0000000000000000 [ 103.165145] x26: 0000000000000000 x25: 0000000000000000 x24: ffff0000019df6b0 [ 103.172271] x23: ffff0000019df6b8 x22: ffff0000019df410 x21: ffff8000826ebc88 [ 103.179397] x20: 000000000007d000 x19: ffff00000a3b3000 x18: 0000000000000000 [ 103.186522] x17: 0000000000000000 x16: 0000000000000000 x15: 000001e8c35e1cde [ 103.193647] x14: 0000000000000396 x13: 000000000000035c x12: 0000000000000000 [ 103.200772] x11: 000000000000003a x10: 00000000000009c0 x9 : ffff8000826eba20 [ 103.207897] x8 : ffff0000090b6d20 x7 : ffff00007728c180 x6 : ffff00007728c100 [ 103.215022] x5 : 0000000000000001 x4 : ffff000000508a50 x3 : ffff7ffff6146000 [ 103.222147] x2 : 0000000000000000 x1 : e300b4173ee6b200 x0 : 0000000000000000 [ 103.229274] Call trace: [ 103.231714] k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool] (P) [ 103.238408] am65_cpsw_nuss_free_rx_chns+0x28/0x4c [ti_am65_cpsw_nuss] [ 103.244942] devm_action_release+0x14/0x20 [ 103.249040] release_nodes+0x3c/0x68 [ 103.252610] devres_release_all+0x8c/0xdc [ 103.256614] device_unbind_cleanup+0x18/0x60 [ 103.260876] device_release_driver_internal+0xf8/0x178 [ 103.266004] driver_detach+0x50/0x9c [ 103.269571] bus_remove_driver+0x6c/0xbc [ 103.273485] driver_unregister+0x30/0x60 [ 103.277401] platform_driver_unregister+0x14/0x20 [ 103.282096] am65_cpsw_nuss_driver_exit+0x18/0xff4 [ti_am65_cpsw_nuss] [ 103.288620] __arm64_sys_delete_module+0x17c/0x25c [ 103.293404] invoke_syscall+0x44/0x100 [ 103.297149] el0_svc_common.constprop.0+0xc0/0xe0 [ 103.301845] do_el0_svc+0x1c/0x28 [ 103.305155] el0_svc+0x28/0x98 ---truncated---(CVE-2025-38042)
In the Linux kernel, the following vulnerability has been resolved:
media: cx231xx: set device_caps for 417
The video_device for the MPEG encoder did not set device_caps.
Add this, otherwise the video device can't be registered (you get a WARN_ON instead).
Not seen before since currently 417 support is disabled, but I found this while experimenting with it.(CVE-2025-38044)
In the Linux kernel, the following vulnerability has been resolved:
espintcp: fix skb leaks
A few error paths are missing a kfree_skb.(CVE-2025-38057)
In the Linux kernel, the following vulnerability has been resolved:
dm cache: prevent BUG_ON by blocking retries on failed device resumes
A cache device failing to resume due to mapping errors should not be retried, as the failure leaves a partially initialized policy object. Repeating the resume operation risks triggering BUG_ON when reloading cache mappings into the incomplete policy object.
Reproduce steps:
- create a cache metadata consisting of 512 or more cache blocks, with some mappings stored in the first array block of the mapping array. Here we use cache_restore v1.0 to build the metadata.
cat <<EOF >> cmeta.xml <superblock uuid="" block_size="128" nr_cache_blocks="512" \ policy="smq" hint_width="4"> <mappings> <mapping cache_block="0" origin_block="0" dirty="false"/> </mappings> </superblock> EOF dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" cache_restore -i cmeta.xml -o /dev/mapper/cmeta --metadata-version=2 dmsetup remove cmeta
- wipe the second array block of the mapping array to simulate data degradations.
mapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \ 2>/dev/null | hexdump -e '1/8 "%u\n"') ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \ 2>/dev/null | hexdump -e '1/8 "%u\n"') dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock
- try bringing up the cache device. The resume is expected to fail due to the broken array block.
dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dmsetup create cache --notable dmsetup load cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" dmsetup resume cache
- try resuming the cache again. An unexpected BUG_ON is triggered while loading cache mappings.
dmsetup resume cache
Kernel logs:
(snip) ------------[ cut here ]------------ kernel BUG at drivers/md/dm-cache-policy-smq.c:752! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 UID: 0 PID: 332 Comm: dmsetup Not tainted 6.13.4 #3 RIP: 0010:smq_load_mapping+0x3e5/0x570
Fix by disallowing resume operations for devices that failed the initial attempt.(CVE-2025-38066)
In the Linux kernel, the following vulnerability has been resolved:
mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race
huge_pmd_unshare() drops a reference on a page table that may have previously been shared across processes, potentially turning it into a normal page table used in another process in which unrelated VMAs can afterwards be installed.
If this happens in the middle of a concurrent gup_fast(), gup_fast() could end up walking the page tables of another process. While I don't see any way in which that immediately leads to kernel memory corruption, it is really weird and unexpected.
Fix it with an explicit broadcast IPI through tlb_remove_table_sync_one(), just like we do in khugepaged when removing page tables for a THP collapse.(CVE-2025-38085)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: fix use-after-free in taprio_dev_notifier
Since taprio’s taprio_dev_notifier() isn’t protected by an RCU read-side critical section, a race with advance_sched() can lead to a use-after-free.
Adding rcu_read_lock() inside taprio_dev_notifier() prevents this.(CVE-2025-38087)
In the Linux kernel, the following vulnerability has been resolved:
espintcp: remove encap socket caching to avoid reference leak
The current scheme for caching the encap socket can lead to reference leaks when we try to delete the netns.
The reference chain is: xfrm_state -> enacp_sk -> netns
Since the encap socket is a userspace socket, it holds a reference on the netns. If we delete the espintcp state (through flush or individual delete) before removing the netns, the reference on the socket is dropped and the netns is correctly deleted. Otherwise, the netns may not be reachable anymore (if all processes within the ns have terminated), so we cannot delete the xfrm state to drop its reference on the socket.
This patch results in a small (~2% in my tests) performance regression.
A GC-type mechanism could be added for the socket cache, to clear references if the state hasn't been used "recently", but it's a lot more complex than just not caching the socket.(CVE-2025-38097)
In the Linux kernel, the following vulnerability has been resolved:
page_pool: Fix use-after-free in page_pool_recycle_in_ring
syzbot reported a uaf in page_pool_recycle_in_ring:
BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862 Read of size 8 at addr ffff8880286045a0 by task syz.0.284/6943
CPU: 0 UID: 0 PID: 6943 Comm: syz.0.284 Not tainted 6.13.0-rc3-syzkaller-gdfa94ce54f41 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862 __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:165 [inline] _raw_spin_unlock_bh+0x1b/0x40 kernel/locking/spinlock.c:210 spin_unlock_bh include/linux/spinlock.h:396 [inline] ptr_ring_produce_bh include/linux/ptr_ring.h:164 [inline] page_pool_recycle_in_ring net/core/page_pool.c:707 [inline] page_pool_put_unrefed_netmem+0x748/0xb00 net/core/page_pool.c:826 page_pool_put_netmem include/net/page_pool/helpers.h:323 [inline] page_pool_put_full_netmem include/net/page_pool/helpers.h:353 [inline] napi_pp_put_page+0x149/0x2b0 net/core/skbuff.c:1036 skb_pp_recycle net/core/skbuff.c:1047 [inline] skb_free_head net/core/skbuff.c:1094 [inline] skb_release_data+0x6c4/0x8a0 net/core/skbuff.c:1125 skb_release_all net/core/skbuff.c:1190 [inline] __kfree_skb net/core/skbuff.c:1204 [inline] sk_skb_reason_drop+0x1c9/0x380 net/core/skbuff.c:1242 kfree_skb_reason include/linux/skbuff.h:1263 [inline] __skb_queue_purge_reason include/linux/skbuff.h:3343 [inline]
root cause is:
page_pool_recycle_in_ring ptr_ring_produce spin_lock(&r->producer_lock); WRITE_ONCE(r->queue[r->producer++], ptr) //recycle last page to pool page_pool_release page_pool_scrub page_pool_empty_ring ptr_ring_consume page_pool_return_page //release all page __page_pool_destroy free_percpu(pool->recycle_stats); free(pool) //free
spin_unlock(&r->producer_lock); //pool->ring uaf read
recycle_stat_inc(pool, ring);
page_pool can be free while page pool recycle the last page in ring. Add producer-lock barrier to page_pool_release to prevent the page pool from being free before all pages have been recycled.
recycle_stat_inc() is empty when CONFIG_PAGE_POOL_STATS is not enabled, which will trigger Wempty-body build warning. Add definition for pool stat macro to fix warning.(CVE-2025-38129)
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Avoid using sk_socket after free when sending
The sk->sk_socket is not locked or referenced in backlog thread, and during the call to skb_send_sock(), there is a race condition with the release of sk_socket. All types of sockets(tcp/udp/unix/vsock) will be affected.
Race conditions: ''' CPU0 CPU1
backlog::skb_send_sock sendmsg_unlocked sock_sendmsg sock_sendmsg_nosec close(fd): ... ops->release() -> sock_map_close() sk_socket->ops = NULL free(socket) sock->ops->sendmsg ^ panic here '''
The ref of psock become 0 after sock_map_close() executed. ''' void sock_map_close() { ... if (likely(psock)) { ... // !! here we remove psock and the ref of psock become 0 sock_map_remove_links(sk, psock) psock = sk_psock_get(sk); if (unlikely(!psock)) goto no_psock; <=== Control jumps here via goto ... cancel_delayed_work_sync(&psock->work); <=== not executed sk_psock_put(sk, psock); ... } '''
Based on the fact that we already wait for the workqueue to finish in sock_map_close() if psock is held, we simply increase the psock reference count to avoid race conditions.
With this patch, if the backlog thread is running, sock_map_close() will wait for the backlog thread to complete and cancel all pending work.
If no backlog running, any pending work that hasn't started by then will fail when invoked by sk_psock_get(), as the psock reference count have been zeroed, and sk_psock_drop() will cancel all jobs via cancel_delayed_work_sync().
In summary, we require synchronization to coordinate the backlog thread and close() thread.
The panic I catched: ''' Workqueue: events sk_psock_backlog RIP: 0010:sock_sendmsg+0x21d/0x440 RAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001 ... Call Trace: <TASK> ? die_addr+0x40/0xa0 ? exc_general_protection+0x14c/0x230 ? asm_exc_general_protection+0x26/0x30 ? sock_sendmsg+0x21d/0x440 ? sock_sendmsg+0x3e0/0x440 ? __pfx_sock_sendmsg+0x10/0x10 __skb_send_sock+0x543/0xb70 sk_psock_backlog+0x247/0xb80 ... '''(CVE-2025-38154)
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix panic when calling skb_linearize
The panic can be reproduced by executing the command: ./bench sockmap -c 2 -p 1 -a --rx-verdict-ingress --rx-strp 100000
Then a kernel panic was captured: ''' [ 657.460555] kernel BUG at net/core/skbuff.c:2178! [ 657.462680] Tainted: [W]=WARN [ 657.463287] Workqueue: events sk_psock_backlog ... [ 657.469610] <TASK> [ 657.469738] ? die+0x36/0x90 [ 657.469916] ? do_trap+0x1d0/0x270 [ 657.470118] ? pskb_expand_head+0x612/0xf40 [ 657.470376] ? pskb_expand_head+0x612/0xf40 [ 657.470620] ? do_error_trap+0xa3/0x170 [ 657.470846] ? pskb_expand_head+0x612/0xf40 [ 657.471092] ? handle_invalid_op+0x2c/0x40 [ 657.471335] ? pskb_expand_head+0x612/0xf40 [ 657.471579] ? exc_invalid_op+0x2d/0x40 [ 657.471805] ? asm_exc_invalid_op+0x1a/0x20 [ 657.472052] ? pskb_expand_head+0xd1/0xf40 [ 657.472292] ? pskb_expand_head+0x612/0xf40 [ 657.472540] ? lock_acquire+0x18f/0x4e0 [ 657.472766] ? find_held_lock+0x2d/0x110 [ 657.472999] ? __pfx_pskb_expand_head+0x10/0x10 [ 657.473263] ? __kmalloc_cache_noprof+0x5b/0x470 [ 657.473537] ? __pfxlockrelease.isra.0+0x10/0x10 [ 657.473826] pskb_pull_tail+0xfd/0x1d20 [ 657.474062] ? __kasan_slab_alloc+0x4e/0x90 [ 657.474707] sk_psock_skb_ingress_enqueue+0x3bf/0x510 [ 657.475392] ? __kasan_kmalloc+0xaa/0xb0 [ 657.476010] sk_psock_backlog+0x5cf/0xd70 [ 657.476637] process_one_work+0x858/0x1a20 '''
The panic originates from the assertion BUG_ON(skb_shared(skb)) in skb_linearize(). A previous commit(see Fixes tag) introduced skb_get() to avoid race conditions between skb operations in the backlog and skb release in the recvmsg path. However, this caused the panic to always occur when skb_linearize is executed.
The "--rx-strp 100000" parameter forces the RX path to use the strparser module which aggregates data until it reaches 100KB before calling sockmap logic. The 100KB payload exceeds MAX_MSG_FRAGS, triggering skb_linearize.
To fix this issue, just move skb_get into sk_psock_skb_ingress_enqueue.
''' sk_psock_backlog: sk_psock_handle_skb skb_get(skb) <== we move it into 'sk_psock_skb_ingress_enqueue' sk_psock_skb_ingress__ ↓ | | → sk_psock_skb_ingress_self | sk_psock_skb_ingress_enqueue sk_psock_verdict_apply___↑ skb_linearize '''
Note that for verdict_apply path, the skb_get operation is unnecessary so we add 'take_ref' param to control it's behavior.(CVE-2025-38165)
In the Linux kernel, the following vulnerability has been resolved:
bpf: fix ktls panic with sockmap
[ 2172.936997] ------------[ cut here ]------------ [ 2172.936999] kernel BUG at lib/iov_iter.c:629! ...... [ 2172.944996] PKRU: 55555554 [ 2172.945155] Call Trace: [ 2172.945299] <TASK> [ 2172.945428] ? die+0x36/0x90 [ 2172.945601] ? do_trap+0xdd/0x100 [ 2172.945795] ? iov_iter_revert+0x178/0x180 [ 2172.946031] ? iov_iter_revert+0x178/0x180 [ 2172.946267] ? do_error_trap+0x7d/0x110 [ 2172.946499] ? iov_iter_revert+0x178/0x180 [ 2172.946736] ? exc_invalid_op+0x50/0x70 [ 2172.946961] ? iov_iter_revert+0x178/0x180 [ 2172.947197] ? asm_exc_invalid_op+0x1a/0x20 [ 2172.947446] ? iov_iter_revert+0x178/0x180 [ 2172.947683] ? iov_iter_revert+0x5c/0x180 [ 2172.947913] tls_sw_sendmsg_locked.isra.0+0x794/0x840 [ 2172.948206] tls_sw_sendmsg+0x52/0x80 [ 2172.948420] ? inet_sendmsg+0x1f/0x70 [ 2172.948634] __sys_sendto+0x1cd/0x200 [ 2172.948848] ? find_held_lock+0x2b/0x80 [ 2172.949072] ? syscall_trace_enter+0x140/0x270 [ 2172.949330] ? __lock_release.isra.0+0x5e/0x170 [ 2172.949595] ? find_held_lock+0x2b/0x80 [ 2172.949817] ? syscall_trace_enter+0x140/0x270 [ 2172.950211] ? lockdep_hardirqs_on_prepare+0xda/0x190 [ 2172.950632] ? ktime_get_coarse_real_ts64+0xc2/0xd0 [ 2172.951036] __x64_sys_sendto+0x24/0x30 [ 2172.951382] do_syscall_64+0x90/0x170 ......
After calling bpf_exec_tx_verdict(), the size of msg_pl->sg may increase, e.g., when the BPF program executes bpf_msg_push_data().
If the BPF program sets cork_bytes and sg.size is smaller than cork_bytes, it will return -ENOSPC and attempt to roll back to the non-zero copy logic. However, during rollback, msg->msg_iter is reset, but since msg_pl->sg.size has been increased, subsequent executions will exceed the actual size of msg_iter. ''' iov_iter_revert(&msg->msg_iter, msg_pl->sg.size - orig_size); '''
The changes in this commit are based on the following considerations:
-
When cork_bytes is set, rolling back to non-zero copy logic is pointless and can directly go to zero-copy logic.
-
We can not calculate the correct number of bytes to revert msg_iter.
Assume the original data is "abcdefgh" (8 bytes), and after 3 pushes by the BPF program, it becomes 11-byte data: "abc?de?fgh?". Then, we set cork_bytes to 6, which means the first 6 bytes have been processed, and the remaining 5 bytes "?fgh?" will be cached until the length meets the cork_bytes requirement.
However, some data in "?fgh?" is not within 'sg->msg_iter' (but in msg_pl instead), especially the data "?" we pushed.
So it doesn't seem as simple as just reverting through an offset of msg_iter.
- For non-TLS sockets in tcp_bpf_sendmsg, when a "cork" situation occurs, the user-space send() doesn't return an error, and the returned length is the same as the input length parameter, even if some data is cached.
Additionally, I saw that the current non-zero-copy logic for handling corking is written as: ''' line 1177 else if (ret != -EAGAIN) { if (ret == -ENOSPC) ret = 0; goto send_end; '''
So it's ok to just return 'copied' without error when a "cork" situation occurs.(CVE-2025-38166)
In the Linux kernel, the following vulnerability has been resolved:
sch_hfsc: make hfsc_qlen_notify() idempotent
hfsc_qlen_notify() is not idempotent either and not friendly to its callers, like fq_codel_dequeue(). Let's make it idempotent to ease qdisc_tree_reduce_backlog() callers' life:
-
update_vf() decreases cl->cl_nactive, so we can check whether it is non-zero before calling it.
-
eltree_remove() always removes RB node cl->el_node, but we can use RB_EMPTY_NODE() + RB_CLEAR_NODE() to make it safe.(CVE-2025-38177)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAX
Otherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof() when resizing hashtable because __GFP_NOWARN is unset.
Similar to:
b541ba7d1f5a ("netfilter: conntrack: clamp maximum hashtable size to INT_MAX")(CVE-2025-38201)
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86/hyper-v: Skip non-canonical addresses during PV TLB flush
In KVM guests with Hyper-V hypercalls enabled, the hypercalls HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST and HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX allow a guest to request invalidation of portions of a virtual TLB. For this, the hypercall parameter includes a list of GVAs that are supposed to be invalidated.
However, when non-canonical GVAs are passed, there is currently no filtering in place and they are eventually passed to checked invocations of INVVPID on Intel / INVLPGA on AMD. While AMD's INVLPGA silently ignores non-canonical addresses (effectively a no-op), Intel's INVVPID explicitly signals VM-Fail and ultimately triggers the WARN_ONCE in invvpid_error():
invvpid failed: ext=0x0 vpid=1 gva=0xaaaaaaaaaaaaa000 WARNING: CPU: 6 PID: 326 at arch/x86/kvm/vmx/vmx.c:482 invvpid_error+0x91/0xa0 [kvm_intel] Modules linked in: kvm_intel kvm 9pnet_virtio irqbypass fuse CPU: 6 UID: 0 PID: 326 Comm: kvm-vm Not tainted 6.15.0 #14 PREEMPT(voluntary) RIP: 0010:invvpid_error+0x91/0xa0 [kvm_intel] Call Trace: vmx_flush_tlb_gva+0x320/0x490 [kvm_intel] kvm_hv_vcpu_flush_tlb+0x24f/0x4f0 [kvm] kvm_arch_vcpu_ioctl_run+0x3013/0x5810 [kvm]
Hyper-V documents that invalid GVAs (those that are beyond a partition's GVA space) are to be ignored. While not completely clear whether this ruling also applies to non-canonical GVAs, it is likely fine to make that assumption, and manual testing on Azure confirms "real" Hyper-V interprets the specification in the same way.
Skip non-canonical GVAs when processing the list of address to avoid tripping the INVVPID failure. Alternatively, KVM could filter out "bad" GVAs before inserting into the FIFO, but practically speaking the only downside of pushing validation to the final processing is that doing so is suboptimal for the guest, and no well-behaved guest will request TLB flushes for non-canonical addresses.(CVE-2025-38351)
In the Linux kernel, the following vulnerability has been resolved:
platform/x86: dell-wmi-sysman: Fix WMI data block retrieval in sysfs callbacks
After retrieving WMI data blocks in sysfs callbacks, check for the validity of them before dereferencing their content.(CVE-2025-38412)
In the Linux kernel, the following vulnerability has been resolved:
HID: core: do not bypass hid_hw_raw_request
hid_hw_raw_request() is actually useful to ensure the provided buffer and length are valid. Directly calling in the low level transport driver function bypassed those checks and allowed invalid paramto be used.(CVE-2025-38494)
In the Linux kernel, the collect_md property of xfrm interfaces can only be set during device creation. However, the xfrmi_changelink() function failed to properly validate this when called. This resulted in the erroneous placement of the special interface xi in the xfrmi_net->xfrmi hash when attempting to modify a collect_md interface. Since it also exists in the xfrmi_net->collect_md_xfrmi pointer, this led to a double free when the net namespace was taken down, causing a kernel crash.(CVE-2025-38500)
In the Linux kernel, the wx_rx_buffer structure contained two DMA address fields: 'dma' and 'page_dma'. However, only 'page_dma' was actually initialized and used to program the Rx descriptor. But 'dma' was uninitialized and used in some paths. This could lead to undefined behavior, including DMA errors or use-after-free, if the uninitialized 'dma' was used. Although such error has not yet occurred, it is worth fixing in the code.(CVE-2025-38533)
In the Linux kernel, the following vulnerability has been resolved: HID: quirks: Add quirk for 2 Chicony Electronics HP 5MP Cameras. The Chicony Electronics HP 5MP Cameras (USB ID 04F2:B824 & 04F2:B82C) report a HID sensor interface that is not actually implemented. Attempting to access this non-functional sensor via iio_info causes system hangs as runtime PM tries to wake up an unresponsive sensor. Add these 2 devices to the HID ignore list since the sensor interface is non-functional by design and should not be exposed to userspace.(CVE-2025-38540)
In the Linux kernel, the following vulnerability has been resolved:
perf/core: Prevent VMA split of buffer mappings
The perf mmap code is careful about mmap()'ing the user page with the ringbuffer and additionally the auxiliary buffer, when the event supports it. Once the first mapping is established, subsequent mapping have to use the same offset and the same size in both cases. The reference counting for the ringbuffer and the auxiliary buffer depends on this being correct.
Though perf does not prevent that a related mapping is split via mmap(2), munmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls, which take reference counts, but then the subsequent perf_mmap_close() calls are not longer fulfilling the offset and size checks. This leads to reference count leaks.
As perf already has the requirement for subsequent mappings to match the initial mapping, the obvious consequence is that VMA splits, caused by resizing of a mapping or partial unmapping, have to be prevented.
Implement the vm_operations_struct::may_split() callback and return unconditionally -EINVAL.
That ensures that the mapping offsets and sizes cannot be changed after the fact. Remapping to a different fixed address with the same size is still possible as it takes the references for the new mapping and drops those of the old mapping.(CVE-2025-38563)
In the Linux kernel, the following vulnerability has been resolved:
benet: fix BUG when creating VFs
benet crashes as soon as SRIOV VFs are created:
kernel BUG at mm/vmalloc.c:3457! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 4 UID: 0 PID: 7408 Comm: test.sh Kdump: loaded Not tainted 6.16.0+ #1 PREEMPT(voluntary) [...] RIP: 0010:vunmap+0x5f/0x70 [...] Call Trace: <TASK> __iommu_dma_free+0xe8/0x1c0 be_cmd_set_mac_list+0x3fe/0x640 [be2net] be_cmd_set_mac+0xaf/0x110 [be2net] be_vf_eth_addr_config+0x19f/0x330 [be2net] be_vf_setup+0x4f7/0x990 [be2net] be_pci_sriov_configure+0x3a1/0x470 [be2net] sriov_numvfs_store+0x20b/0x380 kernfs_fop_write_iter+0x354/0x530 vfs_write+0x9b9/0xf60 ksys_write+0xf3/0x1d0 do_syscall_64+0x8c/0x3d0
be_cmd_set_mac_list() calls dma_free_coherent() under a spin_lock_bh. Fix it by freeing only after the lock has been released.(CVE-2025-38569)
In the Linux kernel, the following vulnerability has been resolved:
vmci: Prevent the dispatching of uninitialized payloads
The reproducer executes the host's unlocked_ioctl call in two different tasks. When init_context fails, the struct vmci_event_ctx is not fully initialized when executing vmci_datagram_dispatch() to send events to all vm contexts. This affects the datagram taken from the datagram queue of its context by another task, because the datagram payload is not initialized according to the size payload_size, which causes the kernel data to leak to the user space.
Before dispatching the datagram, and before setting the payload content, explicitly set the payload content to 0 to avoid data leakage caused by incomplete payload initialization.(CVE-2025-38611)
In the Linux kernel, the following vulnerability has been resolved:
pinmux: fix race causing mux_owner NULL with active mux_usecount
commit 5a3e85c3c397 ("pinmux: Use sequential access to access desc->pinmux data") tried to address the issue when two client of the same gpio calls pinctrl_select_state() for the same functionality, was resulting in NULL pointer issue while accessing desc->mux_owner. However, issue was not completely fixed due to the way it was handled and it can still result in the same NULL pointer.
The issue occurs due to the following interleaving:
cpu0 (process A) cpu1 (process B)
pin_request() { pin_free() {
mutex_lock()
desc->mux_usecount--; //becomes 0
..
mutex_unlock()
mutex_lock(desc->mux) desc->mux_usecount++; // becomes 1 desc->mux_owner = owner; mutex_unlock(desc->mux)
mutex_lock(desc->mux)
desc->mux_owner = NULL;
mutex_unlock(desc->mux)
This sequence leads to a state where the pin appears to be in use
(mux_usecount == 1) but has no owner (mux_owner == NULL), which can
cause NULL pointer on next pin_request on the same pin.
Ensure that updates to mux_usecount and mux_owner are performed atomically under the same lock. Only clear mux_owner when mux_usecount reaches zero and no new owner has been assigned.(CVE-2025-38632)
In the Linux kernel, a vulnerability has been resolved where checking proc_lseek in the same manner as proc_read_iter and others could lead to a Use-After-Free (UAF) scenario during rmmod. This was a gap in proc_reg_open() after commit 654b33ada4ab (proc: fix UAF in proc_get_inode()). Following AI Viro's suggestion, it was fixed in the same manner.(CVE-2025-38653)
In the Linux kernel, a vulnerability was found in the i2c: qup driver where the original logic only sets the return value but does not break out of the loop when the bus remains active due to a client. This unexpected behavior could allow a malicious or faulty i2c client to hang the kernel. The issue was observed during long-term testing with a PCA953x GPIO extender. The fix modifies the logic to not only set the return value but also break out of the loop and return -ETIMEDOUT to the caller.(CVE-2025-38671)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm",
"bpftool-debuginfo-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm",
"kernel-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm",
"kernel-debuginfo-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm",
"kernel-debugsource-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm",
"kernel-devel-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm",
"kernel-extra-modules-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm",
"kernel-headers-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm",
"kernel-source-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm",
"kernel-tools-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm",
"kernel-tools-devel-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm",
"perf-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm",
"perf-debuginfo-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm",
"python3-perf-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm"
],
"src": [
"kernel-6.6.0-108.0.0.114.oe2403sp2.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm",
"bpftool-debuginfo-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm",
"kernel-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm",
"kernel-debuginfo-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm",
"kernel-debugsource-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm",
"kernel-devel-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm",
"kernel-extra-modules-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm",
"kernel-headers-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm",
"kernel-source-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm",
"kernel-tools-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm",
"kernel-tools-devel-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm",
"perf-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm",
"perf-debuginfo-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm",
"python3-perf-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-108.0.0.114.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-108.0.0.114.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\ngtp: Destroy device along with udp socket\u0026apos;s netns dismantle.\n\ngtp_newlink() links the device to a list in dev_net(dev) instead of\nsrc_net, where a udp tunnel socket is created.\n\nEven when src_net is removed, the device stays alive on dev_net(dev).\nThen, removing src_net triggers the splat below. [0]\n\nIn this example, gtp0 is created in ns2, and the udp socket is created\nin ns1.\n\n ip netns add ns1\n ip netns add ns2\n ip -n ns1 link add netns ns2 name gtp0 type gtp role sgsn\n ip netns del ns1\n\nLet\u0026apos;s link the device to the socket\u0026apos;s netns instead.\n\nNow, gtp_net_exit_batch_rtnl() needs another netdev iteration to remove\nall gtp devices in the netns.\n\n[0]:\nref_tracker: net notrefcnt@000000003d6e7d05 has 1/2 users at\n sk_alloc (./include/net/net_namespace.h:345 net/core/sock.c:2236)\n inet_create (net/ipv4/af_inet.c:326 net/ipv4/af_inet.c:252)\n __sock_create (net/socket.c:1558)\n udp_sock_create4 (net/ipv4/udp_tunnel_core.c:18)\n gtp_create_sock (./include/net/udp_tunnel.h:59 drivers/net/gtp.c:1423)\n gtp_create_sockets (drivers/net/gtp.c:1447)\n gtp_newlink (drivers/net/gtp.c:1507)\n rtnl_newlink (net/core/rtnetlink.c:3786 net/core/rtnetlink.c:3897 net/core/rtnetlink.c:4012)\n rtnetlink_rcv_msg (net/core/rtnetlink.c:6922)\n netlink_rcv_skb (net/netlink/af_netlink.c:2542)\n netlink_unicast (net/netlink/af_netlink.c:1321 net/netlink/af_netlink.c:1347)\n netlink_sendmsg (net/netlink/af_netlink.c:1891)\n ____sys_sendmsg (net/socket.c:711 net/socket.c:726 net/socket.c:2583)\n ___sys_sendmsg (net/socket.c:2639)\n __sys_sendmsg (net/socket.c:2669)\n do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)\n\nWARNING: CPU: 1 PID: 60 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179)\nModules linked in:\nCPU: 1 UID: 0 PID: 60 Comm: kworker/u16:2 Not tainted 6.13.0-rc5-00147-g4c1224501e9d #5\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nWorkqueue: netns cleanup_net\nRIP: 0010:ref_tracker_dir_exit (lib/ref_tracker.c:179)\nCode: 00 00 00 fc ff df 4d 8b 26 49 bd 00 01 00 00 00 00 ad de 4c 39 f5 0f 85 df 00 00 00 48 8b 74 24 08 48 89 df e8 a5 cc 12 02 90 \u0026lt;0f\u0026gt; 0b 90 48 8d 6b 44 be 04 00 00 00 48 89 ef e8 80 de 67 ff 48 89\nRSP: 0018:ff11000009a07b60 EFLAGS: 00010286\nRAX: 0000000000002bd3 RBX: ff1100000f4e1aa0 RCX: 1ffffffff0e40ac6\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff8423ee3c\nRBP: ff1100000f4e1af0 R08: 0000000000000001 R09: fffffbfff0e395ae\nR10: 0000000000000001 R11: 0000000000036001 R12: ff1100000f4e1af0\nR13: dead000000000100 R14: ff1100000f4e1af0 R15: dffffc0000000000\nFS: 0000000000000000(0000) GS:ff1100006ce80000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f9b2464bd98 CR3: 0000000005286005 CR4: 0000000000771ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __warn (kernel/panic.c:748)\n ? ref_tracker_dir_exit (lib/ref_tracker.c:179)\n ? report_bug (lib/bug.c:201 lib/bug.c:219)\n ? handle_bug (arch/x86/kernel/traps.c:285)\n ? exc_invalid_op (arch/x86/kernel/traps.c:309 (discriminator 1))\n ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621)\n ? _raw_spin_unlock_irqrestore (./arch/x86/include/asm/irqflags.h:42 ./arch/x86/include/asm/irqflags.h:97 ./arch/x86/include/asm/irqflags.h:155 ./include/linux/spinlock_api_smp.h:151 kernel/locking/spinlock.c:194)\n ? ref_tracker_dir_exit (lib/ref_tracker.c:179)\n ? __pfx_ref_tracker_dir_exit (lib/ref_tracker.c:158)\n ? kfree (mm/slub.c:4613 mm/slub.c:4761)\n net_free (net/core/net_namespace.c:476 net/core/net_namespace.c:467)\n cleanup_net (net/core/net_namespace.c:664 (discriminator 3))\n process_one_work (kernel/workqueue.c:3229)\n worker_thread (kernel/workqueue.c:3304 kernel/workqueue.c:3391\n---truncated---(CVE-2025-21678)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: mpi3mr: Fix possible crash when setting up bsg fails\n\nIf bsg_setup_queue() fails, the bsg_queue is assigned a non-NULL value.\nConsequently, in mpi3mr_bsg_exit(), the condition \u0026quot;if(!mrioc-\u0026gt;bsg_queue)\u0026quot;\nwill not be satisfied, preventing execution from entering\nbsg_remove_queue(), which could lead to the following crash:\n\nBUG: kernel NULL pointer dereference, address: 000000000000041c\nCall Trace:\n \u0026lt;TASK\u0026gt;\n mpi3mr_bsg_exit+0x1f/0x50 [mpi3mr]\n mpi3mr_remove+0x6f/0x340 [mpi3mr]\n pci_device_remove+0x3f/0xb0\n device_release_driver_internal+0x19d/0x220\n unbind_store+0xa4/0xb0\n kernfs_fop_write_iter+0x11f/0x200\n vfs_write+0x1fc/0x3e0\n ksys_write+0x67/0xe0\n do_syscall_64+0x38/0x80\n entry_SYSCALL_64_after_hwframe+0x78/0xe2(CVE-2025-21723)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp: drop secpath at the same time as we currently drop dst\n\nXiumei reported hitting the WARN in xfrm6_tunnel_net_exit while\nrunning tests that boil down to:\n - create a pair of netns\n - run a basic TCP test over ipcomp6\n - delete the pair of netns\n\nThe xfrm_state found on spi_byaddr was not deleted at the time we\ndelete the netns, because we still have a reference on it. This\nlingering reference comes from a secpath (which holds a ref on the\nxfrm_state), which is still attached to an skb. This skb is not\nleaked, it ends up on sk_receive_queue and then gets defer-free\u0026apos;d by\nskb_attempt_defer_free.\n\nThe problem happens when we defer freeing an skb (push it on one CPU\u0026apos;s\ndefer_list), and don\u0026apos;t flush that list before the netns is deleted. In\nthat case, we still have a reference on the xfrm_state that we don\u0026apos;t\nexpect at this point.\n\nWe already drop the skb\u0026apos;s dst in the TCP receive path when it\u0026apos;s no\nlonger needed, so let\u0026apos;s also drop the secpath. At this point,\ntcp_filter has already called into the LSM hooks that may require the\nsecpath, so it should not be needed anymore. However, in some of those\nplaces, the MPTCP extension has just been attached to the skb, so we\ncannot simply drop all extensions.(CVE-2025-21864)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: prevent connection release during oplock break notification\n\nksmbd_work could be freed when after connection release.\nIncrement r_count of ksmbd_conn to indicate that requests\nare not finished yet and to not release the connection.(CVE-2025-21955)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: Fix error code in chan_alloc_skb_cb()\n\nThe chan_alloc_skb_cb() function is supposed to return error pointers on\nerror. Returning NULL will lead to a NULL dereference.(CVE-2025-22007)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: socket: Lookup orig tuple for IPv6 SNAT\n\nnf_sk_lookup_slow_v4 does the conntrack lookup for IPv4 packets to\nrestore the original 5-tuple in case of SNAT, to be able to find the\nright socket (if any). Then socket_match() can correctly check whether\nthe socket was transparent.\n\nHowever, the IPv6 counterpart (nf_sk_lookup_slow_v6) lacks this\nconntrack lookup, making xt_socket fail to match on the socket when the\npacket was SNATed. Add the same logic to nf_sk_lookup_slow_v6.\n\nIPv6 SNAT is used in Kubernetes clusters for pod-to-world packets, as\npods\u0026apos; addresses are in the fd00::/8 ULA subnet and need to be replaced\nwith the node\u0026apos;s external address. Cilium leverages Envoy to enforce L7\npolicies, and Envoy uses transparent sockets. Cilium inserts an iptables\nprerouting rule that matches on `-m socket --transparent` and redirects\nthe packets to localhost, but it fails to match SNATed IPv6 packets due\nto that missing conntrack lookup.(CVE-2025-22021)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_tunnel: fix geneve_opt type confusion addition\n\nWhen handling multiple NFTA_TUNNEL_KEY_OPTS_GENEVE attributes, the\nparsing logic should place every geneve_opt structure one by one\ncompactly. Hence, when deciding the next geneve_opt position, the\npointer addition should be in units of char *.\n\nHowever, the current implementation erroneously does type conversion\nbefore the addition, which will lead to heap out-of-bounds write.\n\n[ 6.989857] ==================================================================\n[ 6.990293] BUG: KASAN: slab-out-of-bounds in nft_tunnel_obj_init+0x977/0xa70\n[ 6.990725] Write of size 124 at addr ffff888005f18974 by task poc/178\n[ 6.991162]\n[ 6.991259] CPU: 0 PID: 178 Comm: poc-oob-write Not tainted 6.1.132 #1\n[ 6.991655] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\n[ 6.992281] Call Trace:\n[ 6.992423] \u0026lt;TASK\u0026gt;\n[ 6.992586] dump_stack_lvl+0x44/0x5c\n[ 6.992801] print_report+0x184/0x4be\n[ 6.993790] kasan_report+0xc5/0x100\n[ 6.994252] kasan_check_range+0xf3/0x1a0\n[ 6.994486] memcpy+0x38/0x60\n[ 6.994692] nft_tunnel_obj_init+0x977/0xa70\n[ 6.995677] nft_obj_init+0x10c/0x1b0\n[ 6.995891] nf_tables_newobj+0x585/0x950\n[ 6.996922] nfnetlink_rcv_batch+0xdf9/0x1020\n[ 6.998997] nfnetlink_rcv+0x1df/0x220\n[ 6.999537] netlink_unicast+0x395/0x530\n[ 7.000771] netlink_sendmsg+0x3d0/0x6d0\n[ 7.001462] __sock_sendmsg+0x99/0xa0\n[ 7.001707] ____sys_sendmsg+0x409/0x450\n[ 7.002391] ___sys_sendmsg+0xfd/0x170\n[ 7.003145] __sys_sendmsg+0xea/0x170\n[ 7.004359] do_syscall_64+0x5e/0x90\n[ 7.005817] entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n[ 7.006127] RIP: 0033:0x7ec756d4e407\n[ 7.006339] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 \u0026lt;5b\u0026gt; c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf\n[ 7.007364] RSP: 002b:00007ffed5d46760 EFLAGS: 00000202 ORIG_RAX: 000000000000002e\n[ 7.007827] RAX: ffffffffffffffda RBX: 00007ec756cc4740 RCX: 00007ec756d4e407\n[ 7.008223] RDX: 0000000000000000 RSI: 00007ffed5d467f0 RDI: 0000000000000003\n[ 7.008620] RBP: 00007ffed5d468a0 R08: 0000000000000000 R09: 0000000000000000\n[ 7.009039] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000\n[ 7.009429] R13: 00007ffed5d478b0 R14: 00007ec756ee5000 R15: 00005cbd4e655cb8\n\nFix this bug with correct pointer addition and conversion in parse\nand dump code.(CVE-2025-22056)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: decrease cached dst counters in dst_release\n\nUpstream fix ac888d58869b (\u0026quot;net: do not delay dst_entries_add() in\ndst_release()\u0026quot;) moved decrementing the dst count from dst_destroy to\ndst_release to avoid accessing already freed data in case of netns\ndismantle. However in case CONFIG_DST_CACHE is enabled and OvS+tunnels\nare used, this fix is incomplete as the same issue will be seen for\ncached dsts:\n\n Unable to handle kernel paging request at virtual address ffff5aabf6b5c000\n Call trace:\n percpu_counter_add_batch+0x3c/0x160 (P)\n dst_release+0xec/0x108\n dst_cache_destroy+0x68/0xd8\n dst_destroy+0x13c/0x168\n dst_destroy_rcu+0x1c/0xb0\n rcu_do_batch+0x18c/0x7d0\n rcu_core+0x174/0x378\n rcu_core_si+0x18/0x30\n\nFix this by invalidating the cache, and thus decrementing cached dst\ncounters, in dst_release too.(CVE-2025-22057)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetlabel: Fix NULL pointer exception caused by CALIPSO on IPv4 sockets\n\nWhen calling netlbl_conn_setattr(), addr-\u0026gt;sa_family is used\nto determine the function behavior. If sk is an IPv4 socket,\nbut the connect function is called with an IPv6 address,\nthe function calipso_sock_setattr() is triggered.\nInside this function, the following code is executed:\n\nsk_fullsock(__sk) ? inet_sk(__sk)-\u0026gt;pinet6 : NULL;\n\nSince sk is an IPv4 socket, pinet6 is NULL, leading to a\nnull pointer dereference.\n\nThis patch fixes the issue by checking if inet6_sk(sk)\nreturns a NULL pointer before accessing pinet6.(CVE-2025-22063)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: don\u0026apos;t unregister hook when table is dormant\n\nWhen nf_tables_updchain encounters an error, hook registration needs to\nbe rolled back.\n\nThis should only be done if the hook has been registered, which won\u0026apos;t\nhappen when the table is flagged as dormant (inactive).\n\nJust move the assignment into the registration block.(CVE-2025-22064)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Fix mlx5_poll_one() cur_qp update flow\n\nWhen cur_qp isn\u0026apos;t NULL, in order to avoid fetching the QP from\nthe radix tree again we check if the next cqe QP is identical to\nthe one we already have.\n\nThe bug however is that we are checking if the QP is identical by\nchecking the QP number inside the CQE against the QP number inside the\nmlx5_ib_qp, but that\u0026apos;s wrong since the QP number from the CQE is from\nFW so it should be matched against mlx5_core_qp which is our FW QP\nnumber.\n\nOtherwise we could use the wrong QP when handling a CQE which could\ncause the kernel trace below.\n\nThis issue is mainly noticeable over QPs 0 \u0026amp; 1, since for now they are\nthe only QPs in our driver whereas the QP number inside mlx5_ib_qp\ndoesn\u0026apos;t match the QP number inside mlx5_core_qp.\n\nBUG: kernel NULL pointer dereference, address: 0000000000000012\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: Oops: 0000 [#1] SMP\n CPU: 0 UID: 0 PID: 7927 Comm: kworker/u62:1 Not tainted 6.14.0-rc3+ #189\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core]\n RIP: 0010:mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib]\n Code: 03 00 00 8d 58 ff 21 cb 66 39 d3 74 39 48 c7 c7 3c 89 6e a0 0f b7 db e8 b7 d2 b3 e0 49 8b 86 60 03 00 00 48 c7 c7 4a 89 6e a0 \u0026lt;0f\u0026gt; b7 5c 98 02 e8 9f d2 b3 e0 41 0f b7 86 78 03 00 00 83 e8 01 21\n RSP: 0018:ffff88810511bd60 EFLAGS: 00010046\n RAX: 0000000000000010 RBX: 0000000000000000 RCX: 0000000000000000\n RDX: 0000000000000000 RSI: ffff88885fa1b3c0 RDI: ffffffffa06e894a\n RBP: 00000000000000b0 R08: 0000000000000000 R09: ffff88810511bc10\n R10: 0000000000000001 R11: 0000000000000001 R12: ffff88810d593000\n R13: ffff88810e579108 R14: ffff888105146000 R15: 00000000000000b0\n FS: 0000000000000000(0000) GS:ffff88885fa00000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000012 CR3: 00000001077e6001 CR4: 0000000000370eb0\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ? __die+0x20/0x60\n ? page_fault_oops+0x150/0x3e0\n ? exc_page_fault+0x74/0x130\n ? asm_exc_page_fault+0x22/0x30\n ? mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib]\n __ib_process_cq+0x5a/0x150 [ib_core]\n ib_cq_poll_work+0x31/0x90 [ib_core]\n process_one_work+0x169/0x320\n worker_thread+0x288/0x3a0\n ? work_busy+0xb0/0xb0\n kthread+0xd7/0x1f0\n ? kthreads_online_cpu+0x130/0x130\n ? kthreads_online_cpu+0x130/0x130\n ret_from_fork+0x2d/0x50\n ? kthreads_online_cpu+0x130/0x130\n ret_from_fork_asm+0x11/0x20\n \u0026lt;/TASK\u0026gt;(CVE-2025-22086)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/core: Don\u0026apos;t expose hw_counters outside of init net namespace\n\nCommit 467f432a521a (\u0026quot;RDMA/core: Split port and device counter sysfs\nattributes\u0026quot;) accidentally almost exposed hw counters to non-init net\nnamespaces. It didn\u0026apos;t expose them fully, as an attempt to read any of\nthose counters leads to a crash like this one:\n\n[42021.807566] BUG: kernel NULL pointer dereference, address: 0000000000000028\n[42021.814463] #PF: supervisor read access in kernel mode\n[42021.819549] #PF: error_code(0x0000) - not-present page\n[42021.824636] PGD 0 P4D 0\n[42021.827145] Oops: 0000 [#1] SMP PTI\n[42021.830598] CPU: 82 PID: 2843922 Comm: switchto-defaul Kdump: loaded Tainted: G S W I XXX\n[42021.841697] Hardware name: XXX\n[42021.849619] RIP: 0010:hw_stat_device_show+0x1e/0x40 [ib_core]\n[42021.855362] Code: 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 49 89 d0 4c 8b 5e 20 48 8b 8f b8 04 00 00 48 81 c7 f0 fa ff ff \u0026lt;48\u0026gt; 8b 41 28 48 29 ce 48 83 c6 d0 48 c1 ee 04 69 d6 ab aa aa aa 48\n[42021.873931] RSP: 0018:ffff97fe90f03da0 EFLAGS: 00010287\n[42021.879108] RAX: ffff9406988a8c60 RBX: ffff940e1072d438 RCX: 0000000000000000\n[42021.886169] RDX: ffff94085f1aa000 RSI: ffff93c6cbbdbcb0 RDI: ffff940c7517aef0\n[42021.893230] RBP: ffff97fe90f03e70 R08: ffff94085f1aa000 R09: 0000000000000000\n[42021.900294] R10: ffff94085f1aa000 R11: ffffffffc0775680 R12: ffffffff87ca2530\n[42021.907355] R13: ffff940651602840 R14: ffff93c6cbbdbcb0 R15: ffff94085f1aa000\n[42021.914418] FS: 00007fda1a3b9700(0000) GS:ffff94453fb80000(0000) knlGS:0000000000000000\n[42021.922423] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[42021.928130] CR2: 0000000000000028 CR3: 00000042dcfb8003 CR4: 00000000003726f0\n[42021.935194] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[42021.942257] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[42021.949324] Call Trace:\n[42021.951756] \u0026lt;TASK\u0026gt;\n[42021.953842] [\u0026lt;ffffffff86c58674\u0026gt;] ? show_regs+0x64/0x70\n[42021.959030] [\u0026lt;ffffffff86c58468\u0026gt;] ? __die+0x78/0xc0\n[42021.963874] [\u0026lt;ffffffff86c9ef75\u0026gt;] ? page_fault_oops+0x2b5/0x3b0\n[42021.969749] [\u0026lt;ffffffff87674b92\u0026gt;] ? exc_page_fault+0x1a2/0x3c0\n[42021.975549] [\u0026lt;ffffffff87801326\u0026gt;] ? asm_exc_page_fault+0x26/0x30\n[42021.981517] [\u0026lt;ffffffffc0775680\u0026gt;] ? __pfx_show_hw_stats+0x10/0x10 [ib_core]\n[42021.988482] [\u0026lt;ffffffffc077564e\u0026gt;] ? hw_stat_device_show+0x1e/0x40 [ib_core]\n[42021.995438] [\u0026lt;ffffffff86ac7f8e\u0026gt;] dev_attr_show+0x1e/0x50\n[42022.000803] [\u0026lt;ffffffff86a3eeb1\u0026gt;] sysfs_kf_seq_show+0x81/0xe0\n[42022.006508] [\u0026lt;ffffffff86a11134\u0026gt;] seq_read_iter+0xf4/0x410\n[42022.011954] [\u0026lt;ffffffff869f4b2e\u0026gt;] vfs_read+0x16e/0x2f0\n[42022.017058] [\u0026lt;ffffffff869f50ee\u0026gt;] ksys_read+0x6e/0xe0\n[42022.022073] [\u0026lt;ffffffff8766f1ca\u0026gt;] do_syscall_64+0x6a/0xa0\n[42022.027441] [\u0026lt;ffffffff8780013b\u0026gt;] entry_SYSCALL_64_after_hwframe+0x78/0xe2\n\nThe problem can be reproduced using the following steps:\n ip netns add foo\n ip netns exec foo bash\n cat /sys/class/infiniband/mlx4_0/hw_counters/*\n\nThe panic occurs because of casting the device pointer into an\nib_device pointer using container_of() in hw_stat_device_show() is\nwrong and leads to a memory corruption.\n\nHowever the real problem is that hw counters should never been exposed\noutside of the non-init net namespace.\n\nFix this by saving the index of the corresponding attribute group\n(it might be 1 or 2 depending on the presence of driver-specific\nattributes) and zeroing the pointer to hw_counters group for compat\ndevices during the initialization.\n\nWith this fix applied hw_counters are not available in a non-init\nnet namespace:\n find /sys/class/infiniband/mlx4_0/ -name hw_counters\n /sys/class/infiniband/mlx4_0/ports/1/hw_counters\n /sys/class/infiniband/mlx4_0/ports/2/hw_counters\n /sys/class/infiniband/mlx4_0/hw_counters\n\n ip netns add foo\n ip netns exec foo bash\n find /sys/class/infiniband/mlx4_0/ -name hw_counters(CVE-2025-22089)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvmxnet3: unregister xdp rxq info in the reset path\n\nvmxnet3 does not unregister xdp rxq info in the\nvmxnet3_reset_work() code path as vmxnet3_rq_destroy()\nis not invoked in this code path. So, we get below message with a\nbacktrace.\n\nMissing unregister, handled but fix driver\nWARNING: CPU:48 PID: 500 at net/core/xdp.c:182\n__xdp_rxq_info_reg+0x93/0xf0\n\nThis patch fixes the problem by moving the unregister\ncode of XDP from vmxnet3_rq_destroy() to vmxnet3_rq_cleanup().(CVE-2025-22106)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ppp: Add bound checking for skb data on ppp_sync_txmung\n\nEnsure we have enough data in linear buffer from skb before accessing\ninitial bytes. This prevents potential out-of-bounds accesses\nwhen processing short packets.\n\nWhen ppp_sync_txmung receives an incoming package with an empty\npayload:\n(remote) gef\u27a4 p *(struct pppoe_hdr *) (skb-\u0026gt;head + skb-\u0026gt;network_header)\n$18 = {\n\ttype = 0x1,\n\tver = 0x1,\n\tcode = 0x0,\n\tsid = 0x2,\n length = 0x0,\n\ttag = 0xffff8880371cdb96\n}\n\nfrom the skb struct (trimmed)\n tail = 0x16,\n end = 0x140,\n head = 0xffff88803346f400 \u0026quot;4\u0026quot;,\n data = 0xffff88803346f416 \u0026quot;:\\377\u0026quot;,\n truesize = 0x380,\n len = 0x0,\n data_len = 0x0,\n mac_len = 0xe,\n hdr_len = 0x0,\n\nit is not safe to access data[2].\n\n[(CVE-2025-37749)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: sch_sfq: move the limit validation\n\nIt is not sufficient to directly validate the limit on the data that\nthe user passes as it can be updated based on how the other parameters\nare changed.\n\nMove the check at the end of the configuration update process to also\ncatch scenarios where the limit is indirectly updated, for example\nwith the following configurations:\n\ntc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 depth 1\ntc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 divisor 1\n\nThis fixes the following syzkaller reported crash:\n\n------------[ cut here ]------------\nUBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:203:6\nindex 65535 is out of range for type \u0026apos;struct sfq_head[128]\u0026apos;\nCPU: 1 UID: 0 PID: 3037 Comm: syz.2.16 Not tainted 6.14.0-rc2-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x201/0x300 lib/dump_stack.c:120\n ubsan_epilogue lib/ubsan.c:231 [inline]\n __ubsan_handle_out_of_bounds+0xf5/0x120 lib/ubsan.c:429\n sfq_link net/sched/sch_sfq.c:203 [inline]\n sfq_dec+0x53c/0x610 net/sched/sch_sfq.c:231\n sfq_dequeue+0x34e/0x8c0 net/sched/sch_sfq.c:493\n sfq_reset+0x17/0x60 net/sched/sch_sfq.c:518\n qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035\n tbf_reset+0x41/0x110 net/sched/sch_tbf.c:339\n qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035\n dev_reset_queue+0x100/0x1b0 net/sched/sch_generic.c:1311\n netdev_for_each_tx_queue include/linux/netdevice.h:2590 [inline]\n dev_deactivate_many+0x7e5/0xe70 net/sched/sch_generic.c:1375(CVE-2025-37752)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/cma: Fix workqueue crash in cma_netevent_work_handler\n\nstruct rdma_cm_id has member \u0026quot;struct work_struct net_work\u0026quot;\nthat is reused for enqueuing cma_netevent_work_handler()s\nonto cma_wq.\n\nBelow crash[1] can occur if more than one call to\ncma_netevent_callback() occurs in quick succession,\nwhich further enqueues cma_netevent_work_handler()s for the\nsame rdma_cm_id, overwriting any previously queued work-item(s)\nthat was just scheduled to run i.e. there is no guarantee\nthe queued work item may run between two successive calls\nto cma_netevent_callback() and the 2nd INIT_WORK would overwrite\nthe 1st work item (for the same rdma_cm_id), despite grabbing\nid_table_lock during enqueue.\n\nAlso drgn analysis [2] indicates the work item was likely overwritten.\n\nFix this by moving the INIT_WORK() to __rdma_create_id(),\nso that it doesn\u0026apos;t race with any existing queue_work() or\nits worker thread.\n\n[1] Trimmed crash stack:\n=============================================\nBUG: kernel NULL pointer dereference, address: 0000000000000008\nkworker/u256:6 ... 6.12.0-0...\nWorkqueue: cma_netevent_work_handler [rdma_cm] (rdma_cm)\nRIP: 0010:process_one_work+0xba/0x31a\nCall Trace:\n worker_thread+0x266/0x3a0\n kthread+0xcf/0x100\n ret_from_fork+0x31/0x50\n ret_from_fork_asm+0x1a/0x30\n=============================================\n\n[2] drgn crash analysis:\n\n\u0026gt;\u0026gt;\u0026gt; trace = prog.crashed_thread().stack_trace()\n\u0026gt;\u0026gt;\u0026gt; trace\n(0) crash_setup_regs (./arch/x86/include/asm/kexec.h:111:15)\n(1) __crash_kexec (kernel/crash_core.c:122:4)\n(2) panic (kernel/panic.c:399:3)\n(3) oops_end (arch/x86/kernel/dumpstack.c:382:3)\n...\n(8) process_one_work (kernel/workqueue.c:3168:2)\n(9) process_scheduled_works (kernel/workqueue.c:3310:3)\n(10) worker_thread (kernel/workqueue.c:3391:4)\n(11) kthread (kernel/kthread.c:389:9)\n\nLine workqueue.c:3168 for this kernel version is in process_one_work():\n3168\tstrscpy(worker-\u0026gt;desc, pwq-\u0026gt;wq-\u0026gt;name, WORKER_DESC_LEN);\n\n\u0026gt;\u0026gt;\u0026gt; trace[8][\u0026quot;work\u0026quot;]\n*(struct work_struct *)0xffff92577d0a21d8 = {\n\t.data = (atomic_long_t){\n\t\t.counter = (s64)536870912, \u0026lt;=== Note\n\t},\n\t.entry = (struct list_head){\n\t\t.next = (struct list_head *)0xffff924d075924c0,\n\t\t.prev = (struct list_head *)0xffff924d075924c0,\n\t},\n\t.func = (work_func_t)cma_netevent_work_handler+0x0 = 0xffffffffc2cec280,\n}\n\nSuspicion is that pwq is NULL:\n\u0026gt;\u0026gt;\u0026gt; trace[8][\u0026quot;pwq\u0026quot;]\n(struct pool_workqueue *)\u0026lt;absent\u0026gt;\n\nIn process_one_work(), pwq is assigned from:\nstruct pool_workqueue *pwq = get_work_pwq(work);\n\nand get_work_pwq() is:\nstatic struct pool_workqueue *get_work_pwq(struct work_struct *work)\n{\n \tunsigned long data = atomic_long_read(\u0026amp;work-\u0026gt;data);\n\n \tif (data \u0026amp; WORK_STRUCT_PWQ)\n \t\treturn work_struct_pwq(data);\n \telse\n \t\treturn NULL;\n}\n\nWORK_STRUCT_PWQ is 0x4:\n\u0026gt;\u0026gt;\u0026gt; print(repr(prog[\u0026apos;WORK_STRUCT_PWQ\u0026apos;]))\nObject(prog, \u0026apos;enum work_flags\u0026apos;, value=4)\n\nBut work-\u0026gt;data is 536870912 which is 0x20000000.\nSo, get_work_pwq() returns NULL and we crash in process_one_work():\n3168\tstrscpy(worker-\u0026gt;desc, pwq-\u0026gt;wq-\u0026gt;name, WORKER_DESC_LEN);\n=============================================(CVE-2025-37772)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: openvswitch: fix nested key length validation in the set() action\n\nIt\u0026apos;s not safe to access nla_len(ovs_key) if the data is smaller than\nthe netlink header. Check that the attribute is OK first.(CVE-2025-37789)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: Purge vif txq in ieee80211_do_stop()\n\nAfter ieee80211_do_stop() SKB from vif\u0026apos;s txq could still be processed.\nIndeed another concurrent vif schedule_and_wake_txq call could cause\nthose packets to be dequeued (see ieee80211_handle_wake_tx_queue())\nwithout checking the sdata current state.\n\nBecause vif.drv_priv is now cleared in this function, this could lead to\ndriver crash.\n\nFor example in ath12k, ahvif is store in vif.drv_priv. Thus if\nath12k_mac_op_tx() is called after ieee80211_do_stop(), ahvif-\u0026gt;ah can be\nNULL, leading the ath12k_warn(ahvif-\u0026gt;ah,...) call in this function to\ntrigger the NULL deref below.\n\n Unable to handle kernel paging request at virtual address dfffffc000000001\n KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\n batman_adv: bat0: Interface deactivated: brbh1337\n Mem abort info:\n ESR = 0x0000000096000004\n EC = 0x25: DABT (current EL), IL = 32 bits\n SET = 0, FnV = 0\n EA = 0, S1PTW = 0\n FSC = 0x04: level 0 translation fault\n Data abort info:\n ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n [dfffffc000000001] address between user and kernel address ranges\n Internal error: Oops: 0000000096000004 [#1] SMP\n CPU: 1 UID: 0 PID: 978 Comm: lbd Not tainted 6.13.0-g633f875b8f1e #114\n Hardware name: HW (DT)\n pstate: 10000005 (nzcV daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k]\n lr : ath12k_mac_op_tx+0x174/0x29b8 [ath12k]\n sp : ffffffc086ace450\n x29: ffffffc086ace450 x28: 0000000000000000 x27: 1ffffff810d59ca4\n x26: ffffff801d05f7c0 x25: 0000000000000000 x24: 000000004000001e\n x23: ffffff8009ce4926 x22: ffffff801f9c0800 x21: ffffff801d05f7f0\n x20: ffffff8034a19f40 x19: 0000000000000000 x18: ffffff801f9c0958\n x17: ffffff800bc0a504 x16: dfffffc000000000 x15: ffffffc086ace4f8\n x14: ffffff801d05f83c x13: 0000000000000000 x12: ffffffb003a0bf03\n x11: 0000000000000000 x10: ffffffb003a0bf02 x9 : ffffff8034a19f40\n x8 : ffffff801d05f818 x7 : 1ffffff0069433dc x6 : ffffff8034a19ee0\n x5 : ffffff801d05f7f0 x4 : 0000000000000000 x3 : 0000000000000001\n x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000008\n Call trace:\n ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] (P)\n ieee80211_handle_wake_tx_queue+0x16c/0x260\n ieee80211_queue_skb+0xeec/0x1d20\n ieee80211_tx+0x200/0x2c8\n ieee80211_xmit+0x22c/0x338\n __ieee80211_subif_start_xmit+0x7e8/0xc60\n ieee80211_subif_start_xmit+0xc4/0xee0\n __ieee80211_subif_start_xmit_8023.isra.0+0x854/0x17a0\n ieee80211_subif_start_xmit_8023+0x124/0x488\n dev_hard_start_xmit+0x160/0x5a8\n __dev_queue_xmit+0x6f8/0x3120\n br_dev_queue_push_xmit+0x120/0x4a8\n __br_forward+0xe4/0x2b0\n deliver_clone+0x5c/0xd0\n br_flood+0x398/0x580\n br_dev_xmit+0x454/0x9f8\n dev_hard_start_xmit+0x160/0x5a8\n __dev_queue_xmit+0x6f8/0x3120\n ip6_finish_output2+0xc28/0x1b60\n __ip6_finish_output+0x38c/0x638\n ip6_output+0x1b4/0x338\n ip6_local_out+0x7c/0xa8\n ip6_send_skb+0x7c/0x1b0\n ip6_push_pending_frames+0x94/0xd0\n rawv6_sendmsg+0x1a98/0x2898\n inet_sendmsg+0x94/0xe0\n __sys_sendto+0x1e4/0x308\n __arm64_sys_sendto+0xc4/0x140\n do_el0_svc+0x110/0x280\n el0_svc+0x20/0x60\n el0t_64_sync_handler+0x104/0x138\n el0t_64_sync+0x154/0x158\n\nTo avoid that, empty vif\u0026apos;s txq at ieee80211_do_stop() so no packet could\nbe dequeued after ieee80211_do_stop() (new packets cannot be queued\nbecause SDATA_STATE_RUNNING is cleared at this point).(CVE-2025-37794)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncpufreq: scpi: Fix null-ptr-deref in scpi_cpufreq_get_rate()\n\ncpufreq_cpu_get_raw() can return NULL when the target CPU is not present\nin the policy-\u0026gt;cpus mask. scpi_cpufreq_get_rate() does not check for\nthis case, which results in a NULL pointer dereference.(CVE-2025-37829)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmscan: don\u0026apos;t try to reclaim hwpoison folio\n\nSyzkaller reports a bug as follows:\n\nInjecting memory failure for pfn 0x18b00e at process virtual address 0x20ffd000\nMemory failure: 0x18b00e: dirty swapcache page still referenced by 2 users\nMemory failure: 0x18b00e: recovery action for dirty swapcache page: Failed\npage: refcount:2 mapcount:0 mapping:0000000000000000 index:0x20ffd pfn:0x18b00e\nmemcg:ffff0000dd6d9000\nanon flags: 0x5ffffe00482011(locked|dirty|arch_1|swapbacked|hwpoison|node=0|zone=2|lastcpupid=0xfffff)\nraw: 005ffffe00482011 dead000000000100 dead000000000122 ffff0000e232a7c9\nraw: 0000000000020ffd 0000000000000000 00000002ffffffff ffff0000dd6d9000\npage dumped because: VM_BUG_ON_FOLIO(!folio_test_uptodate(folio))\n------------[ cut here ]------------\nkernel BUG at mm/swap_state.c:184!\nInternal error: Oops - BUG: 00000000f2000800 [#1] SMP\nModules linked in:\nCPU: 0 PID: 60 Comm: kswapd0 Not tainted 6.6.0-gcb097e7de84e #3\nHardware name: linux,dummy-virt (DT)\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : add_to_swap+0xbc/0x158\nlr : add_to_swap+0xbc/0x158\nsp : ffff800087f37340\nx29: ffff800087f37340 x28: fffffc00052c0380 x27: ffff800087f37780\nx26: ffff800087f37490 x25: ffff800087f37c78 x24: ffff800087f377a0\nx23: ffff800087f37c50 x22: 0000000000000000 x21: fffffc00052c03b4\nx20: 0000000000000000 x19: fffffc00052c0380 x18: 0000000000000000\nx17: 296f696c6f662865 x16: 7461646f7470755f x15: 747365745f6f696c\nx14: 6f6621284f494c4f x13: 0000000000000001 x12: ffff600036d8b97b\nx11: 1fffe00036d8b97a x10: ffff600036d8b97a x9 : dfff800000000000\nx8 : 00009fffc9274686 x7 : ffff0001b6c5cbd3 x6 : 0000000000000001\nx5 : ffff0000c25896c0 x4 : 0000000000000000 x3 : 0000000000000000\nx2 : 0000000000000000 x1 : ffff0000c25896c0 x0 : 0000000000000000\nCall trace:\n add_to_swap+0xbc/0x158\n shrink_folio_list+0x12ac/0x2648\n shrink_inactive_list+0x318/0x948\n shrink_lruvec+0x450/0x720\n shrink_node_memcgs+0x280/0x4a8\n shrink_node+0x128/0x978\n balance_pgdat+0x4f0/0xb20\n kswapd+0x228/0x438\n kthread+0x214/0x230\n ret_from_fork+0x10/0x20\n\nI can reproduce this issue with the following steps:\n\n1) When a dirty swapcache page is isolated by reclaim process and the\n page isn\u0026apos;t locked, inject memory failure for the page. \n me_swapcache_dirty() clears uptodate flag and tries to delete from lru,\n but fails. Reclaim process will put the hwpoisoned page back to lru.\n\n2) The process that maps the hwpoisoned page exits, the page is deleted\n the page will never be freed and will be in the lru forever.\n\n3) If we trigger a reclaim again and tries to reclaim the page,\n add_to_swap() will trigger VM_BUG_ON_FOLIO due to the uptodate flag is\n cleared.\n\nTo fix it, skip the hwpoisoned page in shrink_folio_list(). Besides, the\nhwpoison folio may not be unmapped by hwpoison_user_mappings() yet, unmap\nit in shrink_folio_list(), otherwise the folio will fail to be unmaped by\nhwpoison_user_mappings() since the folio isn\u0026apos;t in lru list.(CVE-2025-37834)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npage_pool: avoid infinite loop to schedule delayed worker\n\nWe noticed the kworker in page_pool_release_retry() was waken\nup repeatedly and infinitely in production because of the\nbuggy driver causing the inflight less than 0 and warning\nus in page_pool_inflight()[1].\n\nSince the inflight value goes negative, it means we should\nnot expect the whole page_pool to get back to work normally.\n\nThis patch mitigates the adverse effect by not rescheduling\nthe kworker when detecting the inflight negative in\npage_pool_release_retry().\n\n[1]\n[Mon Feb 10 20:36:11 2025] ------------[ cut here ]------------\n[Mon Feb 10 20:36:11 2025] Negative(-51446) inflight packet-pages\n...\n[Mon Feb 10 20:36:11 2025] Call Trace:\n[Mon Feb 10 20:36:11 2025] page_pool_release_retry+0x23/0x70\n[Mon Feb 10 20:36:11 2025] process_one_work+0x1b1/0x370\n[Mon Feb 10 20:36:11 2025] worker_thread+0x37/0x3a0\n[Mon Feb 10 20:36:11 2025] kthread+0x11a/0x140\n[Mon Feb 10 20:36:11 2025] ? process_one_work+0x370/0x370\n[Mon Feb 10 20:36:11 2025] ? __kthread_cancel_work+0x40/0x40\n[Mon Feb 10 20:36:11 2025] ret_from_fork+0x35/0x40\n[Mon Feb 10 20:36:11 2025] ---[ end trace ebffe800f33e7e34 ]---\nNote: before this patch, the above calltrace would flood the\ndmesg due to repeated reschedule of release_dw kworker.(CVE-2025-37859)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nigc: fix PTM cycle trigger logic\n\nWriting to clear the PTM status \u0026apos;valid\u0026apos; bit while the PTM cycle is\ntriggered results in unreliable PTM operation. To fix this, clear the\nPTM \u0026apos;trigger\u0026apos; and status after each PTM transaction.\n\nThe issue can be reproduced with the following:\n\n$ sudo phc2sys -R 1000 -O 0 -i tsn0 -m\n\nNote: 1000 Hz (-R 1000) is unrealistically large, but provides a way to\nquickly reproduce the issue.\n\nPHC2SYS exits with:\n\n\u0026quot;ioctl PTP_OFFSET_PRECISE: Connection timed out\u0026quot; when the PTM transaction\n fails\n\nThis patch also fixes a hang in igc_probe() when loading the igc\ndriver in the kdump kernel on systems supporting PTM.\n\nThe igc driver running in the base kernel enables PTM trigger in\nigc_probe(). Therefore the driver is always in PTM trigger mode,\nexcept in brief periods when manually triggering a PTM cycle.\n\nWhen a crash occurs, the NIC is reset while PTM trigger is enabled.\nDue to a hardware problem, the NIC is subsequently in a bad busmaster\nstate and doesn\u0026apos;t handle register reads/writes. When running\nigc_probe() in the kdump kernel, the first register access to a NIC\nregister hangs driver probing and ultimately breaks kdump.\n\nWith this patch, igc has PTM trigger disabled most of the time,\nand the trigger is only enabled for very brief (10 - 100 us) periods\nwhen manually triggering a PTM cycle. Chances that a crash occurs\nduring a PTM trigger are not 0, but extremely reduced.(CVE-2025-37875)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\n9p/net: fix improper handling of bogus negative read/write replies\n\nIn p9_client_write() and p9_client_read_once(), if the server\nincorrectly replies with success but a negative write/read count then we\nwould consider written (negative) \u0026lt;= rsize (positive) because both\nvariables were signed.\n\nMake variables unsigned to avoid this problem.\n\nThe reproducer linked below now fails with the following error instead\nof a null pointer deref:\n9pnet: bogus RWRITE count (4294967295 \u0026gt; 3)(CVE-2025-37879)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Reset IRTE to host control if *new* route isn\u0026apos;t postable\n\nRestore an IRTE back to host control (remapped or posted MSI mode) if the\n*new* GSI route prevents posting the IRQ directly to a vCPU, regardless of\nthe GSI routing type. Updating the IRTE if and only if the new GSI is an\nMSI results in KVM leaving an IRTE posting to a vCPU.\n\nThe dangling IRTE can result in interrupts being incorrectly delivered to\nthe guest, and in the worst case scenario can result in use-after-free,\ne.g. if the VM is torn down, but the underlying host IRQ isn\u0026apos;t freed.(CVE-2025-37885)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: lan743x: Fix memleak issue when GSO enabled\n\nAlways map the `skb` to the LS descriptor. Previously skb was\nmapped to EXT descriptor when the number of fragments is zero with\nGSO enabled. Mapping the skb to EXT descriptor prevents it from\nbeing freed, leading to a memory leak(CVE-2025-37909)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbnxt_en: Fix out-of-bound memcpy() during ethtool -w\n\nWhen retrieving the FW coredump using ethtool, it can sometimes cause\nmemory corruption:\n\nBUG: KFENCE: memory corruption in __bnxt_get_coredump+0x3ef/0x670 [bnxt_en]\nCorrupted memory at 0x000000008f0f30e8 [ ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ] (in kfence-#45):\n__bnxt_get_coredump+0x3ef/0x670 [bnxt_en]\nethtool_get_dump_data+0xdc/0x1a0\n__dev_ethtool+0xa1e/0x1af0\ndev_ethtool+0xa8/0x170\ndev_ioctl+0x1b5/0x580\nsock_do_ioctl+0xab/0xf0\nsock_ioctl+0x1ce/0x2e0\n__x64_sys_ioctl+0x87/0xc0\ndo_syscall_64+0x5c/0xf0\nentry_SYSCALL_64_after_hwframe+0x78/0x80\n\n...\n\nThis happens when copying the coredump segment list in\nbnxt_hwrm_dbg_dma_data() with the HWRM_DBG_COREDUMP_LIST FW command.\nThe info-\u0026gt;dest_buf buffer is allocated based on the number of coredump\nsegments returned by the FW. The segment list is then DMA\u0026apos;ed by\nthe FW and the length of the DMA is returned by FW. The driver then\ncopies this DMA\u0026apos;ed segment list to info-\u0026gt;dest_buf.\n\nIn some cases, this DMA length may exceed the info-\u0026gt;dest_buf length\nand cause the above BUG condition. Fix it by capping the copy\nlength to not exceed the length of info-\u0026gt;dest_buf. The extra\nDMA data contains no useful information.\n\nThis code path is shared for the HWRM_DBG_COREDUMP_LIST and the\nHWRM_DBG_COREDUMP_RETRIEVE FW commands. The buffering is different\nfor these 2 FW commands. To simplify the logic, we need to move\nthe line to adjust the buffer length for HWRM_DBG_COREDUMP_RETRIEVE\nup, so that the new check to cap the copy length will work for both\ncommands.(CVE-2025-37911)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nice: Check VF VSI Pointer Value in ice_vc_add_fdir_fltr()\n\nAs mentioned in the commit baeb705fd6a7 (\u0026quot;ice: always check VF VSI\npointer values\u0026quot;), we need to perform a null pointer check on the return\nvalue of ice_get_vf_vsi() before using it.(CVE-2025-37912)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsch_htb: make htb_qlen_notify() idempotent\n\nhtb_qlen_notify() always deactivates the HTB class and in fact could\ntrigger a warning if it is already deactivated. Therefore, it is not\nidempotent and not friendly to its callers, like fq_codel_dequeue().\n\nLet\u0026apos;s make it idempotent to ease qdisc_tree_reduce_backlog() callers\u0026apos;\nlife.(CVE-2025-37932)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: phy: allow MDIO bus PM ops to start/stop state machine for phylink-controlled PHY\n\nDSA has 2 kinds of drivers:\n\n1. Those who call dsa_switch_suspend() and dsa_switch_resume() from\n their device PM ops: qca8k-8xxx, bcm_sf2, microchip ksz\n2. Those who don\u0026apos;t: all others. The above methods should be optional.\n\nFor type 1, dsa_switch_suspend() calls dsa_user_suspend() -\u0026gt; phylink_stop(),\nand dsa_switch_resume() calls dsa_user_resume() -\u0026gt; phylink_start().\nThese seem good candidates for setting mac_managed_pm = true because\nthat is essentially its definition [1], but that does not seem to be the\nbiggest problem for now, and is not what this change focuses on.\n\nTalking strictly about the 2nd category of DSA drivers here (which\ndo not have MAC managed PM, meaning that for their attached PHYs,\nmdio_bus_phy_suspend() and mdio_bus_phy_resume() should run in full),\nI have noticed that the following warning from mdio_bus_phy_resume() is\ntriggered:\n\n\tWARN_ON(phydev-\u0026gt;state != PHY_HALTED \u0026amp;\u0026amp; phydev-\u0026gt;state != PHY_READY \u0026amp;\u0026amp;\n\t\tphydev-\u0026gt;state != PHY_UP);\n\nbecause the PHY state machine is running.\n\nIt\u0026apos;s running as a result of a previous dsa_user_open() -\u0026gt; ... -\u0026gt;\nphylink_start() -\u0026gt; phy_start() having been initiated by the user.\n\nThe previous mdio_bus_phy_suspend() was supposed to have called\nphy_stop_machine(), but it didn\u0026apos;t. So this is why the PHY is in state\nPHY_NOLINK by the time mdio_bus_phy_resume() runs.\n\nmdio_bus_phy_suspend() did not call phy_stop_machine() because for\nphylink, the phydev-\u0026gt;adjust_link function pointer is NULL. This seems a\ntechnicality introduced by commit fddd91016d16 (\u0026quot;phylib: fix PAL state\nmachine restart on resume\u0026quot;). That commit was written before phylink\nexisted, and was intended to avoid crashing with consumer drivers which\ndon\u0026apos;t use the PHY state machine - phylink always does, when using a PHY.\nBut phylink itself has historically not been developed with\nsuspend/resume in mind, and apparently not tested too much in that\nscenario, allowing this bug to exist unnoticed for so long. Plus, prior\nto the WARN_ON(), it would have likely been invisible.\n\nThis issue is not in fact restricted to type 2 DSA drivers (according to\nthe above ad-hoc classification), but can be extrapolated to any MAC\ndriver with phylink and MDIO-bus-managed PHY PM ops. DSA is just where\nthe issue was reported. Assuming mac_managed_pm is set correctly, a\nquick search indicates the following other drivers might be affected:\n\n$ grep -Zlr PHYLINK_NETDEV drivers/ | xargs -0 grep -L mac_managed_pm\ndrivers/net/ethernet/atheros/ag71xx.c\ndrivers/net/ethernet/microchip/sparx5/sparx5_main.c\ndrivers/net/ethernet/microchip/lan966x/lan966x_main.c\ndrivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c\ndrivers/net/ethernet/freescale/fs_enet/fs_enet-main.c\ndrivers/net/ethernet/freescale/dpaa/dpaa_eth.c\ndrivers/net/ethernet/freescale/ucc_geth.c\ndrivers/net/ethernet/freescale/enetc/enetc_pf_common.c\ndrivers/net/ethernet/marvell/mvpp2/mvpp2_main.c\ndrivers/net/ethernet/marvell/mvneta.c\ndrivers/net/ethernet/marvell/prestera/prestera_main.c\ndrivers/net/ethernet/mediatek/mtk_eth_soc.c\ndrivers/net/ethernet/altera/altera_tse_main.c\ndrivers/net/ethernet/wangxun/txgbe/txgbe_phy.c\ndrivers/net/ethernet/meta/fbnic/fbnic_phylink.c\ndrivers/net/ethernet/tehuti/tn40_phy.c\ndrivers/net/ethernet/mscc/ocelot_net.c\n\nMake the existing conditions dependent on the PHY device having a\nphydev-\u0026gt;phy_link_change() implementation equal to the default\nphy_link_change() provided by phylib. Otherwise, we implicitly know that\nthe phydev has the phylink-provided phylink_phy_change() callback, and\nwhen phylink is used, the PHY state machine always needs to be stopped/\nstarted on the suspend/resume path. The code is structured as such that\nif phydev-\u0026gt;phy_link_change() is absent, it is a matter of time until the\nkernel will crash - no need to further complicate the test.\n\nThus, for the situation where the PM is not managed b\n---truncated---(CVE-2025-37945)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Scrub packet on bpf_redirect_peer\n\nWhen bpf_redirect_peer is used to redirect packets to a device in\nanother network namespace, the skb isn\u0026apos;t scrubbed. That can lead skb\ninformation from one namespace to be \u0026quot;misused\u0026quot; in another namespace.\n\nAs one example, this is causing Cilium to drop traffic when using\nbpf_redirect_peer to redirect packets that just went through IPsec\ndecryption to a container namespace. The following pwru trace shows (1)\nthe packet path from the host\u0026apos;s XFRM layer to the container\u0026apos;s XFRM\nlayer where it\u0026apos;s dropped and (2) the number of active skb extensions at\neach function.\n\n NETNS MARK IFACE TUPLE FUNC\n 4026533547 d00 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 xfrm_rcv_cb\n .active_extensions = (__u8)2,\n 4026533547 d00 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 xfrm4_rcv_cb\n .active_extensions = (__u8)2,\n 4026533547 d00 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 gro_cells_receive\n .active_extensions = (__u8)2,\n [...]\n 4026533547 0 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 skb_do_redirect\n .active_extensions = (__u8)2,\n 4026534999 0 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 ip_rcv\n .active_extensions = (__u8)2,\n 4026534999 0 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 ip_rcv_core\n .active_extensions = (__u8)2,\n [...]\n 4026534999 0 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 udp_queue_rcv_one_skb\n .active_extensions = (__u8)2,\n 4026534999 0 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 __xfrm_policy_check\n .active_extensions = (__u8)2,\n 4026534999 0 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 __xfrm_decode_session\n .active_extensions = (__u8)2,\n 4026534999 0 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 security_xfrm_decode_session\n .active_extensions = (__u8)2,\n 4026534999 0 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 kfree_skb_reason(SKB_DROP_REASON_XFRM_POLICY)\n .active_extensions = (__u8)2,\n\nIn this case, there are no XFRM policies in the container\u0026apos;s network\nnamespace so the drop is unexpected. When we decrypt the IPsec packet,\nthe XFRM state used for decryption is set in the skb extensions. This\ninformation is preserved across the netns switch. When we reach the\nXFRM policy check in the container\u0026apos;s netns, __xfrm_policy_check drops\nthe packet with LINUX_MIB_XFRMINNOPOLS because a (container-side) XFRM\npolicy can\u0026apos;t be found that matches the (host-side) XFRM state used for\ndecryption.\n\nThis patch fixes this by scrubbing the packet when using\nbpf_redirect_peer, as is done on typical netns switches via veth\ndevices except skb-\u0026gt;mark and skb-\u0026gt;tstamp are not zeroed.(CVE-2025-37959)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmemblock: Accept allocated memory before use in memblock_double_array()\n\nWhen increasing the array size in memblock_double_array() and the slab\nis not yet available, a call to memblock_find_in_range() is used to\nreserve/allocate memory. However, the range returned may not have been\naccepted, which can result in a crash when booting an SNP guest:\n\n RIP: 0010:memcpy_orig+0x68/0x130\n Code: ...\n RSP: 0000:ffffffff9cc03ce8 EFLAGS: 00010006\n RAX: ff11001ff83e5000 RBX: 0000000000000000 RCX: fffffffffffff000\n RDX: 0000000000000bc0 RSI: ffffffff9dba8860 RDI: ff11001ff83e5c00\n RBP: 0000000000002000 R08: 0000000000000000 R09: 0000000000002000\n R10: 000000207fffe000 R11: 0000040000000000 R12: ffffffff9d06ef78\n R13: ff11001ff83e5000 R14: ffffffff9dba7c60 R15: 0000000000000c00\n memblock_double_array+0xff/0x310\n memblock_add_range+0x1fb/0x2f0\n memblock_reserve+0x4f/0xa0\n memblock_alloc_range_nid+0xac/0x130\n memblock_alloc_internal+0x53/0xc0\n memblock_alloc_try_nid+0x3d/0xa0\n swiotlb_init_remap+0x149/0x2f0\n mem_init+0xb/0xb0\n mm_core_init+0x8f/0x350\n start_kernel+0x17e/0x5d0\n x86_64_start_reservations+0x14/0x30\n x86_64_start_kernel+0x92/0xa0\n secondary_startup_64_no_verify+0x194/0x19b\n\nMitigate this by calling accept_memory() on the memory range returned\nbefore the slab is available.\n\nPrior to v6.12, the accept_memory() interface used a \u0026apos;start\u0026apos; and \u0026apos;end\u0026apos;\nparameter instead of \u0026apos;start\u0026apos; and \u0026apos;size\u0026apos;, therefore the accept_memory()\ncall must be adjusted to specify \u0026apos;start + size\u0026apos; for \u0026apos;end\u0026apos; when applying\nto kernels prior to v6.12.(CVE-2025-37960)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: fix uninit-value for saddr in do_output_route4\n\nsyzbot reports for uninit-value for the saddr argument [1].\ncommit 4754957f04f5 (\u0026quot;ipvs: do not use random local source address for\ntunnels\u0026quot;) already implies that the input value of saddr\nshould be ignored but the code is still reading it which can prevent\nto connect the route. Fix it by changing the argument to ret_saddr.\n\n[1]\nBUG: KMSAN: uninit-value in do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147\n do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147\n __ip_vs_get_out_rt+0x403/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:330\n ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136\n ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063\n nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]\n nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626\n nf_hook include/linux/netfilter.h:269 [inline]\n __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118\n ip_local_out net/ipv4/ip_output.c:127 [inline]\n ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501\n udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195\n udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483\n inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851\n sock_sendmsg_nosec net/socket.c:712 [inline]\n __sock_sendmsg+0x267/0x380 net/socket.c:727\n ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620\n __sys_sendmmsg+0x41d/0x880 net/socket.c:2702\n __compat_sys_sendmmsg net/compat.c:360 [inline]\n __do_compat_sys_sendmmsg net/compat.c:367 [inline]\n __se_compat_sys_sendmmsg net/compat.c:364 [inline]\n __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364\n ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346\n do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]\n __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306\n do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331\n do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369\n entry_SYSENTER_compat_after_hwframe+0x84/0x8e\n\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:4167 [inline]\n slab_alloc_node mm/slub.c:4210 [inline]\n __kmalloc_cache_noprof+0x8fa/0xe00 mm/slub.c:4367\n kmalloc_noprof include/linux/slab.h:905 [inline]\n ip_vs_dest_dst_alloc net/netfilter/ipvs/ip_vs_xmit.c:61 [inline]\n __ip_vs_get_out_rt+0x35d/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:323\n ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136\n ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063\n nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]\n nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626\n nf_hook include/linux/netfilter.h:269 [inline]\n __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118\n ip_local_out net/ipv4/ip_output.c:127 [inline]\n ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501\n udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195\n udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483\n inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851\n sock_sendmsg_nosec net/socket.c:712 [inline]\n __sock_sendmsg+0x267/0x380 net/socket.c:727\n ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620\n __sys_sendmmsg+0x41d/0x880 net/socket.c:2702\n __compat_sys_sendmmsg net/compat.c:360 [inline]\n __do_compat_sys_sendmmsg net/compat.c:367 [inline]\n __se_compat_sys_sendmmsg net/compat.c:364 [inline]\n __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364\n ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346\n do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]\n __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306\n do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331\n do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369\n entry_SYSENTER_compat_after_hwframe+0x84/0x8e\n\nCPU: 0 UID: 0 PID: 22408 Comm: syz.4.5165 Not tainted 6.15.0-rc3-syzkaller-00019-gbc3372351d0c #0 PREEMPT(undef)\nHardware name: Google Google Compute Engi\n---truncated---(CVE-2025-37961)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: phy: leds: fix memory leak\n\nA network restart test on a router led to an out-of-memory condition,\nwhich was traced to a memory leak in the PHY LED trigger code.\n\nThe root cause is misuse of the devm API. The registration function\n(phy_led_triggers_register) is called from phy_attach_direct, not\nphy_probe, and the unregister function (phy_led_triggers_unregister)\nis called from phy_detach, not phy_remove. This means the register and\nunregister functions can be called multiple times for the same PHY\ndevice, but devm-allocated memory is not freed until the driver is\nunbound.\n\nThis also prevents kmemleak from detecting the leak, as the devm API\ninternally stores the allocated pointer.\n\nFix this by replacing devm_kzalloc/devm_kcalloc with standard\nkzalloc/kcalloc, and add the corresponding kfree calls in the unregister\npath.(CVE-2025-37989)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcm80211: fmac: Add error handling for brcmf_usb_dl_writeimage()\n\nThe function brcmf_usb_dl_writeimage() calls the function\nbrcmf_usb_dl_cmd() but dose not check its return value. The\n\u0026apos;state.state\u0026apos; and the \u0026apos;state.bytes\u0026apos; are uninitialized if the\nfunction brcmf_usb_dl_cmd() fails. It is dangerous to use\nuninitialized variables in the conditions.\n\nAdd error handling for brcmf_usb_dl_cmd() to jump to error\nhandling path if the brcmf_usb_dl_cmd() fails and the\n\u0026apos;state.state\u0026apos; and the \u0026apos;state.bytes\u0026apos; are uninitialized.\n\nImprove the error message to report more detailed error\ninformation.(CVE-2025-37990)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: bcm: add missing rcu read protection for procfs content\n\nWhen the procfs content is generated for a bcm_op which is in the process\nto be removed the procfs output might show unreliable data (UAF).\n\nAs the removal of bcm_op\u0026apos;s is already implemented with rcu handling this\npatch adds the missing rcu_read_lock() and makes sure the list entries\nare properly removed under rcu protection.(CVE-2025-38003)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: bcm: add locking for bcm_op runtime updates\n\nThe CAN broadcast manager (CAN BCM) can send a sequence of CAN frames via\nhrtimer. The content and also the length of the sequence can be changed\nresp reduced at runtime where the \u0026apos;currframe\u0026apos; counter is then set to zero.\n\nAlthough this appeared to be a safe operation the updates of \u0026apos;currframe\u0026apos;\ncan be triggered from user space and hrtimer context in bcm_can_tx().\nAnderson Nascimento created a proof of concept that triggered a KASAN\nslab-out-of-bounds read access which can be prevented with a spin_lock_bh.\n\nAt the rework of bcm_can_tx() the \u0026apos;count\u0026apos; variable has been moved into\nthe protected section as this variable can be modified from both contexts\ntoo.(CVE-2025-38004)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nphy: tegra: xusb: Use a bitmask for UTMI pad power state tracking\n\nThe current implementation uses bias_pad_enable as a reference count to\nmanage the shared bias pad for all UTMI PHYs. However, during system\nsuspension with connected USB devices, multiple power-down requests for\nthe UTMI pad result in a mismatch in the reference count, which in turn\nproduces warnings such as:\n\n[ 237.762967] WARNING: CPU: 10 PID: 1618 at tegra186_utmi_pad_power_down+0x160/0x170\n[ 237.763103] Call trace:\n[ 237.763104] tegra186_utmi_pad_power_down+0x160/0x170\n[ 237.763107] tegra186_utmi_phy_power_off+0x10/0x30\n[ 237.763110] phy_power_off+0x48/0x100\n[ 237.763113] tegra_xusb_enter_elpg+0x204/0x500\n[ 237.763119] tegra_xusb_suspend+0x48/0x140\n[ 237.763122] platform_pm_suspend+0x2c/0xb0\n[ 237.763125] dpm_run_callback.isra.0+0x20/0xa0\n[ 237.763127] __device_suspend+0x118/0x330\n[ 237.763129] dpm_suspend+0x10c/0x1f0\n[ 237.763130] dpm_suspend_start+0x88/0xb0\n[ 237.763132] suspend_devices_and_enter+0x120/0x500\n[ 237.763135] pm_suspend+0x1ec/0x270\n\nThe root cause was traced back to the dynamic power-down changes\nintroduced in commit a30951d31b25 (\u0026quot;xhci: tegra: USB2 pad power controls\u0026quot;),\nwhere the UTMI pad was being powered down without verifying its current\nstate. This unbalanced behavior led to discrepancies in the reference\ncount.\n\nTo rectify this issue, this patch replaces the single reference counter\nwith a bitmask, renamed to utmi_pad_enabled. Each bit in the mask\ncorresponds to one of the four USB2 PHYs, allowing us to track each pad\u0026apos;s\nenablement status individually.\n\nWith this change:\n - The bias pad is powered on only when the mask is clear.\n - Each UTMI pad is powered on or down based on its corresponding bit\n in the mask, preventing redundant operations.\n - The overall power state of the shared bias pad is maintained\n correctly during suspend/resume cycles.\n\nThe mutex used to prevent race conditions during UTMI pad enable/disable\noperations has been moved from the tegra186_utmi_bias_pad_power_on/off\nfunctions to the parent functions tegra186_utmi_pad_power_on/down. This\nchange ensures that there are no race conditions when updating the bitmask.(CVE-2025-38010)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmlxsw: spectrum_router: Fix use-after-free when deleting GRE net devices\n\nThe driver only offloads neighbors that are constructed on top of net\ndevices registered by it or their uppers (which are all Ethernet). The\ndevice supports GRE encapsulation and decapsulation of forwarded\ntraffic, but the driver will not offload dummy neighbors constructed on\ntop of GRE net devices as they are not uppers of its net devices:\n\n # ip link add name gre1 up type gre tos inherit local 192.0.2.1 remote 198.51.100.1\n # ip neigh add 0.0.0.0 lladdr 0.0.0.0 nud noarp dev gre1\n $ ip neigh show dev gre1 nud noarp\n 0.0.0.0 lladdr 0.0.0.0 NOARP\n\n(Note that the neighbor is not marked with \u0026apos;offload\u0026apos;)\n\nWhen the driver is reloaded and the existing configuration is replayed,\nthe driver does not perform the same check regarding existing neighbors\nand offloads the previously added one:\n\n # devlink dev reload pci/0000:01:00.0\n $ ip neigh show dev gre1 nud noarp\n 0.0.0.0 lladdr 0.0.0.0 offload NOARP\n\nIf the neighbor is later deleted, the driver will ignore the\nnotification (given the GRE net device is not its upper) and will\ntherefore keep referencing freed memory, resulting in a use-after-free\n[1] when the net device is deleted:\n\n # ip neigh del 0.0.0.0 lladdr 0.0.0.0 dev gre1\n # ip link del dev gre1\n\nFix by skipping neighbor replay if the net device for which the replay\nis performed is not our upper.\n\n[1]\nBUG: KASAN: slab-use-after-free in mlxsw_sp_neigh_entry_update+0x1ea/0x200\nRead of size 8 at addr ffff888155b0e420 by task ip/2282\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x6f/0xa0\n print_address_description.constprop.0+0x6f/0x350\n print_report+0x108/0x205\n kasan_report+0xdf/0x110\n mlxsw_sp_neigh_entry_update+0x1ea/0x200\n mlxsw_sp_router_rif_gone_sync+0x2a8/0x440\n mlxsw_sp_rif_destroy+0x1e9/0x750\n mlxsw_sp_netdevice_ipip_ol_event+0x3c9/0xdc0\n mlxsw_sp_router_netdevice_event+0x3ac/0x15e0\n notifier_call_chain+0xca/0x150\n call_netdevice_notifiers_info+0x7f/0x100\n unregister_netdevice_many_notify+0xc8c/0x1d90\n rtnl_dellink+0x34e/0xa50\n rtnetlink_rcv_msg+0x6fb/0xb70\n netlink_rcv_skb+0x131/0x360\n netlink_unicast+0x426/0x710\n netlink_sendmsg+0x75a/0xc20\n __sock_sendmsg+0xc1/0x150\n ____sys_sendmsg+0x5aa/0x7b0\n ___sys_sendmsg+0xfc/0x180\n __sys_sendmsg+0x121/0x1b0\n do_syscall_64+0xbb/0x1d0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53(CVE-2025-38019)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Disable MACsec offload for uplink representor profile\n\nMACsec offload is not supported in switchdev mode for uplink\nrepresentors. When switching to the uplink representor profile, the\nMACsec offload feature must be cleared from the netdevice\u0026apos;s features.\n\nIf left enabled, attempts to add offloads result in a null pointer\ndereference, as the uplink representor does not support MACsec offload\neven though the feature bit remains set.\n\nClear NETIF_F_HW_MACSEC in mlx5e_fix_uplink_rep_features().\n\nKernel log:\n\nOops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN\nKASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f]\nCPU: 29 UID: 0 PID: 4714 Comm: ip Not tainted 6.14.0-rc4_for_upstream_debug_2025_03_02_17_35 #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nRIP: 0010:__mutex_lock+0x128/0x1dd0\nCode: d0 7c 08 84 d2 0f 85 ad 15 00 00 8b 35 91 5c fe 03 85 f6 75 29 49 8d 7e 60 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 \u0026lt;80\u0026gt; 3c 02 00 0f 85 a6 15 00 00 4d 3b 76 60 0f 85 fd 0b 00 00 65 ff\nRSP: 0018:ffff888147a4f160 EFLAGS: 00010206\nRAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000001\nRDX: 000000000000000f RSI: 0000000000000000 RDI: 0000000000000078\nRBP: ffff888147a4f2e0 R08: ffffffffa05d2c19 R09: 0000000000000000\nR10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000\nR13: dffffc0000000000 R14: 0000000000000018 R15: ffff888152de0000\nFS: 00007f855e27d800(0000) GS:ffff88881ee80000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00000000004e5768 CR3: 000000013ae7c005 CR4: 0000000000372eb0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? die_addr+0x3d/0xa0\n ? exc_general_protection+0x144/0x220\n ? asm_exc_general_protection+0x22/0x30\n ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core]\n ? __mutex_lock+0x128/0x1dd0\n ? lockdep_set_lock_cmp_fn+0x190/0x190\n ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core]\n ? mutex_lock_io_nested+0x1ae0/0x1ae0\n ? lock_acquire+0x1c2/0x530\n ? macsec_upd_offload+0x145/0x380\n ? lockdep_hardirqs_on_prepare+0x400/0x400\n ? kasan_save_stack+0x30/0x40\n ? kasan_save_stack+0x20/0x40\n ? kasan_save_track+0x10/0x30\n ? __kasan_kmalloc+0x77/0x90\n ? __kmalloc_noprof+0x249/0x6b0\n ? genl_family_rcv_msg_attrs_parse.constprop.0+0xb5/0x240\n ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core]\n mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core]\n ? mlx5e_macsec_add_rxsa+0x11a0/0x11a0 [mlx5_core]\n macsec_update_offload+0x26c/0x820\n ? macsec_set_mac_address+0x4b0/0x4b0\n ? lockdep_hardirqs_on_prepare+0x284/0x400\n ? _raw_spin_unlock_irqrestore+0x47/0x50\n macsec_upd_offload+0x2c8/0x380\n ? macsec_update_offload+0x820/0x820\n ? __nla_parse+0x22/0x30\n ? genl_family_rcv_msg_attrs_parse.constprop.0+0x15e/0x240\n genl_family_rcv_msg_doit+0x1cc/0x2a0\n ? genl_family_rcv_msg_attrs_parse.constprop.0+0x240/0x240\n ? cap_capable+0xd4/0x330\n genl_rcv_msg+0x3ea/0x670\n ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0\n ? lockdep_set_lock_cmp_fn+0x190/0x190\n ? macsec_update_offload+0x820/0x820\n netlink_rcv_skb+0x12b/0x390\n ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0\n ? netlink_ack+0xd80/0xd80\n ? rwsem_down_read_slowpath+0xf90/0xf90\n ? netlink_deliver_tap+0xcd/0xac0\n ? netlink_deliver_tap+0x155/0xac0\n ? _copy_from_iter+0x1bb/0x12c0\n genl_rcv+0x24/0x40\n netlink_unicast+0x440/0x700\n ? netlink_attachskb+0x760/0x760\n ? lock_acquire+0x1c2/0x530\n ? __might_fault+0xbb/0x170\n netlink_sendmsg+0x749/0xc10\n ? netlink_unicast+0x700/0x700\n ? __might_fault+0xbb/0x170\n ? netlink_unicast+0x700/0x700\n __sock_sendmsg+0xc5/0x190\n ____sys_sendmsg+0x53f/0x760\n ? import_iovec+0x7/0x10\n ? kernel_sendmsg+0x30/0x30\n ? __copy_msghdr+0x3c0/0x3c0\n ? filter_irq_stacks+0x90/0x90\n ? stack_depot_save_flags+0x28/0xa30\n ___sys_sen\n---truncated---(CVE-2025-38020)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/core: Fix \u0026quot;KASAN: slab-use-after-free Read in ib_register_device\u0026quot; problem\n\nCall Trace:\n\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:408 [inline]\n print_report+0xc3/0x670 mm/kasan/report.c:521\n kasan_report+0xe0/0x110 mm/kasan/report.c:634\n strlen+0x93/0xa0 lib/string.c:420\n __fortify_strlen include/linux/fortify-string.h:268 [inline]\n get_kobj_path_length lib/kobject.c:118 [inline]\n kobject_get_path+0x3f/0x2a0 lib/kobject.c:158\n kobject_uevent_env+0x289/0x1870 lib/kobject_uevent.c:545\n ib_register_device drivers/infiniband/core/device.c:1472 [inline]\n ib_register_device+0x8cf/0xe00 drivers/infiniband/core/device.c:1393\n rxe_register_device+0x275/0x320 drivers/infiniband/sw/rxe/rxe_verbs.c:1552\n rxe_net_add+0x8e/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:550\n rxe_newlink+0x70/0x190 drivers/infiniband/sw/rxe/rxe.c:225\n nldev_newlink+0x3a3/0x680 drivers/infiniband/core/nldev.c:1796\n rdma_nl_rcv_msg+0x387/0x6e0 drivers/infiniband/core/netlink.c:195\n rdma_nl_rcv_skb.constprop.0.isra.0+0x2e5/0x450\n netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]\n netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339\n netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883\n sock_sendmsg_nosec net/socket.c:712 [inline]\n __sock_sendmsg net/socket.c:727 [inline]\n ____sys_sendmsg+0xa95/0xc70 net/socket.c:2566\n ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620\n __sys_sendmsg+0x16d/0x220 net/socket.c:2652\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nThis problem is similar to the problem that the\ncommit 1d6a9e7449e2 (\u0026quot;RDMA/core: Fix use-after-free when rename device name\u0026quot;)\nfixes.\n\nThe root cause is: the function ib_device_rename() renames the name with\nlock. But in the function kobject_uevent(), this name is accessed without\nlock protection at the same time.\n\nThe solution is to add the lock protection when this name is accessed in\nthe function kobject_uevent().(CVE-2025-38022)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bug\n\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x7d/0xa0 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0xcf/0x610 mm/kasan/report.c:489\n kasan_report+0xb5/0xe0 mm/kasan/report.c:602\n rxe_queue_cleanup+0xd0/0xe0 drivers/infiniband/sw/rxe/rxe_queue.c:195\n rxe_cq_cleanup+0x3f/0x50 drivers/infiniband/sw/rxe/rxe_cq.c:132\n __rxe_cleanup+0x168/0x300 drivers/infiniband/sw/rxe/rxe_pool.c:232\n rxe_create_cq+0x22e/0x3a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1109\n create_cq+0x658/0xb90 drivers/infiniband/core/uverbs_cmd.c:1052\n ib_uverbs_create_cq+0xc7/0x120 drivers/infiniband/core/uverbs_cmd.c:1095\n ib_uverbs_write+0x969/0xc90 drivers/infiniband/core/uverbs_main.c:679\n vfs_write fs/read_write.c:677 [inline]\n vfs_write+0x26a/0xcc0 fs/read_write.c:659\n ksys_write+0x1b8/0x200 fs/read_write.c:731\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nIn the function rxe_create_cq, when rxe_cq_from_init fails, the function\nrxe_cleanup will be called to handle the allocated resources. In fact,\nsome memory resources have already been freed in the function\nrxe_cq_from_init. Thus, this problem will occur.\n\nThe solution is to let rxe_cleanup do all the work.(CVE-2025-38024)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Avoid WARN_ON when configuring MQPRIO with HTB offload enabled\n\nWhen attempting to enable MQPRIO while HTB offload is already\nconfigured, the driver currently returns `-EINVAL` and triggers a\n`WARN_ON`, leading to an unnecessary call trace.\n\nUpdate the code to handle this case more gracefully by returning\n`-EOPNOTSUPP` instead, while also providing a helpful user message.(CVE-2025-38039)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: ti: k3-udma-glue: Drop skip_fdq argument from k3_udma_glue_reset_rx_chn\n\nThe user of k3_udma_glue_reset_rx_chn() e.g. ti_am65_cpsw_nuss can\nrun on multiple platforms having different DMA architectures.\nOn some platforms there can be one FDQ for all flows in the RX channel\nwhile for others there is a separate FDQ for each flow in the RX channel.\n\nSo far we have been relying on the skip_fdq argument of\nk3_udma_glue_reset_rx_chn().\n\nInstead of relying on the user to provide this information, infer it\nbased on DMA architecture during k3_udma_glue_request_rx_chn() and save it\nin an internal flag \u0026apos;single_fdq\u0026apos;. Use that flag at\nk3_udma_glue_reset_rx_chn() to deicide if the FDQ needs\nto be cleared for every flow or just for flow 0.\n\nFixes the below issue on ti_am65_cpsw_nuss driver on AM62-SK.\n\n\u0026gt; ip link set eth1 down\n\u0026gt; ip link set eth0 down\n\u0026gt; ethtool -L eth0 rx 8\n\u0026gt; ip link set eth0 up\n\u0026gt; modprobe -r ti_am65_cpsw_nuss\n\n[ 103.045726] ------------[ cut here ]------------\n[ 103.050505] k3_knav_desc_pool size 512000 != avail 64000\n[ 103.050703] WARNING: CPU: 1 PID: 450 at drivers/net/ethernet/ti/k3-cppi-desc-pool.c:33 k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool]\n[ 103.068810] Modules linked in: ti_am65_cpsw_nuss(-) k3_cppi_desc_pool snd_soc_hdmi_codec crct10dif_ce snd_soc_simple_card snd_soc_simple_card_utils display_connector rtc_ti_k3 k3_j72xx_bandgap tidss drm_client_lib snd_soc_davinci_mcas\np drm_dma_helper tps6598x phylink snd_soc_ti_udma rti_wdt drm_display_helper snd_soc_tlv320aic3x_i2c typec at24 phy_gmii_sel snd_soc_ti_edma snd_soc_tlv320aic3x sii902x snd_soc_ti_sdma sa2ul omap_mailbox drm_kms_helper authenc cfg80211 r\nfkill fuse drm drm_panel_orientation_quirks backlight ip_tables x_tables ipv6 [last unloaded: k3_cppi_desc_pool]\n[ 103.119950] CPU: 1 UID: 0 PID: 450 Comm: modprobe Not tainted 6.13.0-rc7-00001-g9c5e3435fa66 #1011\n[ 103.119968] Hardware name: Texas Instruments AM625 SK (DT)\n[ 103.119974] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 103.119983] pc : k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool]\n[ 103.148007] lr : k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool]\n[ 103.154709] sp : ffff8000826ebbc0\n[ 103.158015] x29: ffff8000826ebbc0 x28: ffff0000090b6300 x27: 0000000000000000\n[ 103.165145] x26: 0000000000000000 x25: 0000000000000000 x24: ffff0000019df6b0\n[ 103.172271] x23: ffff0000019df6b8 x22: ffff0000019df410 x21: ffff8000826ebc88\n[ 103.179397] x20: 000000000007d000 x19: ffff00000a3b3000 x18: 0000000000000000\n[ 103.186522] x17: 0000000000000000 x16: 0000000000000000 x15: 000001e8c35e1cde\n[ 103.193647] x14: 0000000000000396 x13: 000000000000035c x12: 0000000000000000\n[ 103.200772] x11: 000000000000003a x10: 00000000000009c0 x9 : ffff8000826eba20\n[ 103.207897] x8 : ffff0000090b6d20 x7 : ffff00007728c180 x6 : ffff00007728c100\n[ 103.215022] x5 : 0000000000000001 x4 : ffff000000508a50 x3 : ffff7ffff6146000\n[ 103.222147] x2 : 0000000000000000 x1 : e300b4173ee6b200 x0 : 0000000000000000\n[ 103.229274] Call trace:\n[ 103.231714] k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool] (P)\n[ 103.238408] am65_cpsw_nuss_free_rx_chns+0x28/0x4c [ti_am65_cpsw_nuss]\n[ 103.244942] devm_action_release+0x14/0x20\n[ 103.249040] release_nodes+0x3c/0x68\n[ 103.252610] devres_release_all+0x8c/0xdc\n[ 103.256614] device_unbind_cleanup+0x18/0x60\n[ 103.260876] device_release_driver_internal+0xf8/0x178\n[ 103.266004] driver_detach+0x50/0x9c\n[ 103.269571] bus_remove_driver+0x6c/0xbc\n[ 103.273485] driver_unregister+0x30/0x60\n[ 103.277401] platform_driver_unregister+0x14/0x20\n[ 103.282096] am65_cpsw_nuss_driver_exit+0x18/0xff4 [ti_am65_cpsw_nuss]\n[ 103.288620] __arm64_sys_delete_module+0x17c/0x25c\n[ 103.293404] invoke_syscall+0x44/0x100\n[ 103.297149] el0_svc_common.constprop.0+0xc0/0xe0\n[ 103.301845] do_el0_svc+0x1c/0x28\n[ 103.305155] el0_svc+0x28/0x98\n---truncated---(CVE-2025-38042)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: cx231xx: set device_caps for 417\n\nThe video_device for the MPEG encoder did not set device_caps.\n\nAdd this, otherwise the video device can\u0026apos;t be registered (you get a\nWARN_ON instead).\n\nNot seen before since currently 417 support is disabled, but I found\nthis while experimenting with it.(CVE-2025-38044)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nespintcp: fix skb leaks\n\nA few error paths are missing a kfree_skb.(CVE-2025-38057)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm cache: prevent BUG_ON by blocking retries on failed device resumes\n\nA cache device failing to resume due to mapping errors should not be\nretried, as the failure leaves a partially initialized policy object.\nRepeating the resume operation risks triggering BUG_ON when reloading\ncache mappings into the incomplete policy object.\n\nReproduce steps:\n\n1. create a cache metadata consisting of 512 or more cache blocks,\n with some mappings stored in the first array block of the mapping\n array. Here we use cache_restore v1.0 to build the metadata.\n\ncat \u0026lt;\u0026lt;EOF \u0026gt;\u0026gt; cmeta.xml\n\u0026lt;superblock uuid=\u0026quot;\u0026quot; block_size=\u0026quot;128\u0026quot; nr_cache_blocks=\u0026quot;512\u0026quot; \\\npolicy=\u0026quot;smq\u0026quot; hint_width=\u0026quot;4\u0026quot;\u0026gt;\n \u0026lt;mappings\u0026gt;\n \u0026lt;mapping cache_block=\u0026quot;0\u0026quot; origin_block=\u0026quot;0\u0026quot; dirty=\u0026quot;false\u0026quot;/\u0026gt;\n \u0026lt;/mappings\u0026gt;\n\u0026lt;/superblock\u0026gt;\nEOF\ndmsetup create cmeta --table \u0026quot;0 8192 linear /dev/sdc 0\u0026quot;\ncache_restore -i cmeta.xml -o /dev/mapper/cmeta --metadata-version=2\ndmsetup remove cmeta\n\n2. wipe the second array block of the mapping array to simulate\n data degradations.\n\nmapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \\\n2\u0026gt;/dev/null | hexdump -e \u0026apos;1/8 \u0026quot;%u\\n\u0026quot;\u0026apos;)\nablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \\\n2\u0026gt;/dev/null | hexdump -e \u0026apos;1/8 \u0026quot;%u\\n\u0026quot;\u0026apos;)\ndd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock\n\n3. try bringing up the cache device. The resume is expected to fail\n due to the broken array block.\n\ndmsetup create cmeta --table \u0026quot;0 8192 linear /dev/sdc 0\u0026quot;\ndmsetup create cdata --table \u0026quot;0 65536 linear /dev/sdc 8192\u0026quot;\ndmsetup create corig --table \u0026quot;0 524288 linear /dev/sdc 262144\u0026quot;\ndmsetup create cache --notable\ndmsetup load cache --table \u0026quot;0 524288 cache /dev/mapper/cmeta \\\n/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\u0026quot;\ndmsetup resume cache\n\n4. try resuming the cache again. An unexpected BUG_ON is triggered\n while loading cache mappings.\n\ndmsetup resume cache\n\nKernel logs:\n\n(snip)\n------------[ cut here ]------------\nkernel BUG at drivers/md/dm-cache-policy-smq.c:752!\nOops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI\nCPU: 0 UID: 0 PID: 332 Comm: dmsetup Not tainted 6.13.4 #3\nRIP: 0010:smq_load_mapping+0x3e5/0x570\n\nFix by disallowing resume operations for devices that failed the\ninitial attempt.(CVE-2025-38066)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race\n\nhuge_pmd_unshare() drops a reference on a page table that may have\npreviously been shared across processes, potentially turning it into a\nnormal page table used in another process in which unrelated VMAs can\nafterwards be installed.\n\nIf this happens in the middle of a concurrent gup_fast(), gup_fast() could\nend up walking the page tables of another process. While I don\u0026apos;t see any\nway in which that immediately leads to kernel memory corruption, it is\nreally weird and unexpected.\n\nFix it with an explicit broadcast IPI through tlb_remove_table_sync_one(),\njust like we do in khugepaged when removing page tables for a THP\ncollapse.(CVE-2025-38085)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: fix use-after-free in taprio_dev_notifier\n\nSince taprio\u2019s taprio_dev_notifier() isn\u2019t protected by an\nRCU read-side critical section, a race with advance_sched()\ncan lead to a use-after-free.\n\nAdding rcu_read_lock() inside taprio_dev_notifier() prevents this.(CVE-2025-38087)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nespintcp: remove encap socket caching to avoid reference leak\n\nThe current scheme for caching the encap socket can lead to reference\nleaks when we try to delete the netns.\n\nThe reference chain is: xfrm_state -\u0026gt; enacp_sk -\u0026gt; netns\n\nSince the encap socket is a userspace socket, it holds a reference on\nthe netns. If we delete the espintcp state (through flush or\nindividual delete) before removing the netns, the reference on the\nsocket is dropped and the netns is correctly deleted. Otherwise, the\nnetns may not be reachable anymore (if all processes within the ns\nhave terminated), so we cannot delete the xfrm state to drop its\nreference on the socket.\n\nThis patch results in a small (~2% in my tests) performance\nregression.\n\nA GC-type mechanism could be added for the socket cache, to clear\nreferences if the state hasn\u0026apos;t been used \u0026quot;recently\u0026quot;, but it\u0026apos;s a lot\nmore complex than just not caching the socket.(CVE-2025-38097)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npage_pool: Fix use-after-free in page_pool_recycle_in_ring\n\nsyzbot reported a uaf in page_pool_recycle_in_ring:\n\nBUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862\nRead of size 8 at addr ffff8880286045a0 by task syz.0.284/6943\n\nCPU: 0 UID: 0 PID: 6943 Comm: syz.0.284 Not tainted 6.13.0-rc3-syzkaller-gdfa94ce54f41 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:489\n kasan_report+0x143/0x180 mm/kasan/report.c:602\n lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862\n __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:165 [inline]\n _raw_spin_unlock_bh+0x1b/0x40 kernel/locking/spinlock.c:210\n spin_unlock_bh include/linux/spinlock.h:396 [inline]\n ptr_ring_produce_bh include/linux/ptr_ring.h:164 [inline]\n page_pool_recycle_in_ring net/core/page_pool.c:707 [inline]\n page_pool_put_unrefed_netmem+0x748/0xb00 net/core/page_pool.c:826\n page_pool_put_netmem include/net/page_pool/helpers.h:323 [inline]\n page_pool_put_full_netmem include/net/page_pool/helpers.h:353 [inline]\n napi_pp_put_page+0x149/0x2b0 net/core/skbuff.c:1036\n skb_pp_recycle net/core/skbuff.c:1047 [inline]\n skb_free_head net/core/skbuff.c:1094 [inline]\n skb_release_data+0x6c4/0x8a0 net/core/skbuff.c:1125\n skb_release_all net/core/skbuff.c:1190 [inline]\n __kfree_skb net/core/skbuff.c:1204 [inline]\n sk_skb_reason_drop+0x1c9/0x380 net/core/skbuff.c:1242\n kfree_skb_reason include/linux/skbuff.h:1263 [inline]\n __skb_queue_purge_reason include/linux/skbuff.h:3343 [inline]\n\nroot cause is:\n\npage_pool_recycle_in_ring\n ptr_ring_produce\n spin_lock(\u0026amp;r-\u0026gt;producer_lock);\n WRITE_ONCE(r-\u0026gt;queue[r-\u0026gt;producer++], ptr)\n //recycle last page to pool\n\t\t\t\tpage_pool_release\n\t\t\t\t page_pool_scrub\n\t\t\t\t page_pool_empty_ring\n\t\t\t\t ptr_ring_consume\n\t\t\t\t page_pool_return_page //release all page\n\t\t\t\t __page_pool_destroy\n\t\t\t\t free_percpu(pool-\u0026gt;recycle_stats);\n\t\t\t\t free(pool) //free\n\n spin_unlock(\u0026amp;r-\u0026gt;producer_lock); //pool-\u0026gt;ring uaf read\n recycle_stat_inc(pool, ring);\n\npage_pool can be free while page pool recycle the last page in ring.\nAdd producer-lock barrier to page_pool_release to prevent the page\npool from being free before all pages have been recycled.\n\nrecycle_stat_inc() is empty when CONFIG_PAGE_POOL_STATS is not\nenabled, which will trigger Wempty-body build warning. Add definition\nfor pool stat macro to fix warning.(CVE-2025-38129)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Avoid using sk_socket after free when sending\n\nThe sk-\u0026gt;sk_socket is not locked or referenced in backlog thread, and\nduring the call to skb_send_sock(), there is a race condition with\nthe release of sk_socket. All types of sockets(tcp/udp/unix/vsock)\nwill be affected.\n\nRace conditions:\n\u0026apos;\u0026apos;\u0026apos;\nCPU0 CPU1\n\nbacklog::skb_send_sock\n sendmsg_unlocked\n sock_sendmsg\n sock_sendmsg_nosec\n close(fd):\n ...\n ops-\u0026gt;release() -\u0026gt; sock_map_close()\n sk_socket-\u0026gt;ops = NULL\n free(socket)\n sock-\u0026gt;ops-\u0026gt;sendmsg\n ^\n panic here\n\u0026apos;\u0026apos;\u0026apos;\n\nThe ref of psock become 0 after sock_map_close() executed.\n\u0026apos;\u0026apos;\u0026apos;\nvoid sock_map_close()\n{\n ...\n if (likely(psock)) {\n ...\n // !! here we remove psock and the ref of psock become 0\n sock_map_remove_links(sk, psock)\n psock = sk_psock_get(sk);\n if (unlikely(!psock))\n goto no_psock; \u0026lt;=== Control jumps here via goto\n ...\n cancel_delayed_work_sync(\u0026amp;psock-\u0026gt;work); \u0026lt;=== not executed\n sk_psock_put(sk, psock);\n ...\n}\n\u0026apos;\u0026apos;\u0026apos;\n\nBased on the fact that we already wait for the workqueue to finish in\nsock_map_close() if psock is held, we simply increase the psock\nreference count to avoid race conditions.\n\nWith this patch, if the backlog thread is running, sock_map_close() will\nwait for the backlog thread to complete and cancel all pending work.\n\nIf no backlog running, any pending work that hasn\u0026apos;t started by then will\nfail when invoked by sk_psock_get(), as the psock reference count have\nbeen zeroed, and sk_psock_drop() will cancel all jobs via\ncancel_delayed_work_sync().\n\nIn summary, we require synchronization to coordinate the backlog thread\nand close() thread.\n\nThe panic I catched:\n\u0026apos;\u0026apos;\u0026apos;\nWorkqueue: events sk_psock_backlog\nRIP: 0010:sock_sendmsg+0x21d/0x440\nRAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? die_addr+0x40/0xa0\n ? exc_general_protection+0x14c/0x230\n ? asm_exc_general_protection+0x26/0x30\n ? sock_sendmsg+0x21d/0x440\n ? sock_sendmsg+0x3e0/0x440\n ? __pfx_sock_sendmsg+0x10/0x10\n __skb_send_sock+0x543/0xb70\n sk_psock_backlog+0x247/0xb80\n...\n\u0026apos;\u0026apos;\u0026apos;(CVE-2025-38154)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Fix panic when calling skb_linearize\n\nThe panic can be reproduced by executing the command:\n./bench sockmap -c 2 -p 1 -a --rx-verdict-ingress --rx-strp 100000\n\nThen a kernel panic was captured:\n\u0026apos;\u0026apos;\u0026apos;\n[ 657.460555] kernel BUG at net/core/skbuff.c:2178!\n[ 657.462680] Tainted: [W]=WARN\n[ 657.463287] Workqueue: events sk_psock_backlog\n...\n[ 657.469610] \u0026lt;TASK\u0026gt;\n[ 657.469738] ? die+0x36/0x90\n[ 657.469916] ? do_trap+0x1d0/0x270\n[ 657.470118] ? pskb_expand_head+0x612/0xf40\n[ 657.470376] ? pskb_expand_head+0x612/0xf40\n[ 657.470620] ? do_error_trap+0xa3/0x170\n[ 657.470846] ? pskb_expand_head+0x612/0xf40\n[ 657.471092] ? handle_invalid_op+0x2c/0x40\n[ 657.471335] ? pskb_expand_head+0x612/0xf40\n[ 657.471579] ? exc_invalid_op+0x2d/0x40\n[ 657.471805] ? asm_exc_invalid_op+0x1a/0x20\n[ 657.472052] ? pskb_expand_head+0xd1/0xf40\n[ 657.472292] ? pskb_expand_head+0x612/0xf40\n[ 657.472540] ? lock_acquire+0x18f/0x4e0\n[ 657.472766] ? find_held_lock+0x2d/0x110\n[ 657.472999] ? __pfx_pskb_expand_head+0x10/0x10\n[ 657.473263] ? __kmalloc_cache_noprof+0x5b/0x470\n[ 657.473537] ? __pfx___lock_release.isra.0+0x10/0x10\n[ 657.473826] __pskb_pull_tail+0xfd/0x1d20\n[ 657.474062] ? __kasan_slab_alloc+0x4e/0x90\n[ 657.474707] sk_psock_skb_ingress_enqueue+0x3bf/0x510\n[ 657.475392] ? __kasan_kmalloc+0xaa/0xb0\n[ 657.476010] sk_psock_backlog+0x5cf/0xd70\n[ 657.476637] process_one_work+0x858/0x1a20\n\u0026apos;\u0026apos;\u0026apos;\n\nThe panic originates from the assertion BUG_ON(skb_shared(skb)) in\nskb_linearize(). A previous commit(see Fixes tag) introduced skb_get()\nto avoid race conditions between skb operations in the backlog and skb\nrelease in the recvmsg path. However, this caused the panic to always\noccur when skb_linearize is executed.\n\nThe \u0026quot;--rx-strp 100000\u0026quot; parameter forces the RX path to use the strparser\nmodule which aggregates data until it reaches 100KB before calling sockmap\nlogic. The 100KB payload exceeds MAX_MSG_FRAGS, triggering skb_linearize.\n\nTo fix this issue, just move skb_get into sk_psock_skb_ingress_enqueue.\n\n\u0026apos;\u0026apos;\u0026apos;\nsk_psock_backlog:\n sk_psock_handle_skb\n skb_get(skb) \u0026lt;== we move it into \u0026apos;sk_psock_skb_ingress_enqueue\u0026apos;\n sk_psock_skb_ingress____________\n \u2193\n |\n | \u2192 sk_psock_skb_ingress_self\n | sk_psock_skb_ingress_enqueue\nsk_psock_verdict_apply_________________\u2191 skb_linearize\n\u0026apos;\u0026apos;\u0026apos;\n\nNote that for verdict_apply path, the skb_get operation is unnecessary so\nwe add \u0026apos;take_ref\u0026apos; param to control it\u0026apos;s behavior.(CVE-2025-38165)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: fix ktls panic with sockmap\n\n[ 2172.936997] ------------[ cut here ]------------\n[ 2172.936999] kernel BUG at lib/iov_iter.c:629!\n......\n[ 2172.944996] PKRU: 55555554\n[ 2172.945155] Call Trace:\n[ 2172.945299] \u0026lt;TASK\u0026gt;\n[ 2172.945428] ? die+0x36/0x90\n[ 2172.945601] ? do_trap+0xdd/0x100\n[ 2172.945795] ? iov_iter_revert+0x178/0x180\n[ 2172.946031] ? iov_iter_revert+0x178/0x180\n[ 2172.946267] ? do_error_trap+0x7d/0x110\n[ 2172.946499] ? iov_iter_revert+0x178/0x180\n[ 2172.946736] ? exc_invalid_op+0x50/0x70\n[ 2172.946961] ? iov_iter_revert+0x178/0x180\n[ 2172.947197] ? asm_exc_invalid_op+0x1a/0x20\n[ 2172.947446] ? iov_iter_revert+0x178/0x180\n[ 2172.947683] ? iov_iter_revert+0x5c/0x180\n[ 2172.947913] tls_sw_sendmsg_locked.isra.0+0x794/0x840\n[ 2172.948206] tls_sw_sendmsg+0x52/0x80\n[ 2172.948420] ? inet_sendmsg+0x1f/0x70\n[ 2172.948634] __sys_sendto+0x1cd/0x200\n[ 2172.948848] ? find_held_lock+0x2b/0x80\n[ 2172.949072] ? syscall_trace_enter+0x140/0x270\n[ 2172.949330] ? __lock_release.isra.0+0x5e/0x170\n[ 2172.949595] ? find_held_lock+0x2b/0x80\n[ 2172.949817] ? syscall_trace_enter+0x140/0x270\n[ 2172.950211] ? lockdep_hardirqs_on_prepare+0xda/0x190\n[ 2172.950632] ? ktime_get_coarse_real_ts64+0xc2/0xd0\n[ 2172.951036] __x64_sys_sendto+0x24/0x30\n[ 2172.951382] do_syscall_64+0x90/0x170\n......\n\nAfter calling bpf_exec_tx_verdict(), the size of msg_pl-\u0026gt;sg may increase,\ne.g., when the BPF program executes bpf_msg_push_data().\n\nIf the BPF program sets cork_bytes and sg.size is smaller than cork_bytes,\nit will return -ENOSPC and attempt to roll back to the non-zero copy\nlogic. However, during rollback, msg-\u0026gt;msg_iter is reset, but since\nmsg_pl-\u0026gt;sg.size has been increased, subsequent executions will exceed the\nactual size of msg_iter.\n\u0026apos;\u0026apos;\u0026apos;\niov_iter_revert(\u0026amp;msg-\u0026gt;msg_iter, msg_pl-\u0026gt;sg.size - orig_size);\n\u0026apos;\u0026apos;\u0026apos;\n\nThe changes in this commit are based on the following considerations:\n\n1. When cork_bytes is set, rolling back to non-zero copy logic is\npointless and can directly go to zero-copy logic.\n\n2. We can not calculate the correct number of bytes to revert msg_iter.\n\nAssume the original data is \u0026quot;abcdefgh\u0026quot; (8 bytes), and after 3 pushes\nby the BPF program, it becomes 11-byte data: \u0026quot;abc?de?fgh?\u0026quot;.\nThen, we set cork_bytes to 6, which means the first 6 bytes have been\nprocessed, and the remaining 5 bytes \u0026quot;?fgh?\u0026quot; will be cached until the\nlength meets the cork_bytes requirement.\n\nHowever, some data in \u0026quot;?fgh?\u0026quot; is not within \u0026apos;sg-\u0026gt;msg_iter\u0026apos;\n(but in msg_pl instead), especially the data \u0026quot;?\u0026quot; we pushed.\n\nSo it doesn\u0026apos;t seem as simple as just reverting through an offset of\nmsg_iter.\n\n3. For non-TLS sockets in tcp_bpf_sendmsg, when a \u0026quot;cork\u0026quot; situation occurs,\nthe user-space send() doesn\u0026apos;t return an error, and the returned length is\nthe same as the input length parameter, even if some data is cached.\n\nAdditionally, I saw that the current non-zero-copy logic for handling\ncorking is written as:\n\u0026apos;\u0026apos;\u0026apos;\nline 1177\nelse if (ret != -EAGAIN) {\n\tif (ret == -ENOSPC)\n\t\tret = 0;\n\tgoto send_end;\n\u0026apos;\u0026apos;\u0026apos;\n\nSo it\u0026apos;s ok to just return \u0026apos;copied\u0026apos; without error when a \u0026quot;cork\u0026quot; situation\noccurs.(CVE-2025-38166)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsch_hfsc: make hfsc_qlen_notify() idempotent\n\nhfsc_qlen_notify() is not idempotent either and not friendly\nto its callers, like fq_codel_dequeue(). Let\u0026apos;s make it idempotent\nto ease qdisc_tree_reduce_backlog() callers\u0026apos; life:\n\n1. update_vf() decreases cl-\u0026gt;cl_nactive, so we can check whether it is\nnon-zero before calling it.\n\n2. eltree_remove() always removes RB node cl-\u0026gt;el_node, but we can use\n RB_EMPTY_NODE() + RB_CLEAR_NODE() to make it safe.(CVE-2025-38177)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAX\n\nOtherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof()\nwhen resizing hashtable because __GFP_NOWARN is unset.\n\nSimilar to:\n\n b541ba7d1f5a (\u0026quot;netfilter: conntrack: clamp maximum hashtable size to INT_MAX\u0026quot;)(CVE-2025-38201)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86/hyper-v: Skip non-canonical addresses during PV TLB flush\n\nIn KVM guests with Hyper-V hypercalls enabled, the hypercalls\nHVCALL_FLUSH_VIRTUAL_ADDRESS_LIST and HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX\nallow a guest to request invalidation of portions of a virtual TLB.\nFor this, the hypercall parameter includes a list of GVAs that are supposed\nto be invalidated.\n\nHowever, when non-canonical GVAs are passed, there is currently no\nfiltering in place and they are eventually passed to checked invocations of\nINVVPID on Intel / INVLPGA on AMD. While AMD\u0026apos;s INVLPGA silently ignores\nnon-canonical addresses (effectively a no-op), Intel\u0026apos;s INVVPID explicitly\nsignals VM-Fail and ultimately triggers the WARN_ONCE in invvpid_error():\n\n invvpid failed: ext=0x0 vpid=1 gva=0xaaaaaaaaaaaaa000\n WARNING: CPU: 6 PID: 326 at arch/x86/kvm/vmx/vmx.c:482\n invvpid_error+0x91/0xa0 [kvm_intel]\n Modules linked in: kvm_intel kvm 9pnet_virtio irqbypass fuse\n CPU: 6 UID: 0 PID: 326 Comm: kvm-vm Not tainted 6.15.0 #14 PREEMPT(voluntary)\n RIP: 0010:invvpid_error+0x91/0xa0 [kvm_intel]\n Call Trace:\n vmx_flush_tlb_gva+0x320/0x490 [kvm_intel]\n kvm_hv_vcpu_flush_tlb+0x24f/0x4f0 [kvm]\n kvm_arch_vcpu_ioctl_run+0x3013/0x5810 [kvm]\n\nHyper-V documents that invalid GVAs (those that are beyond a partition\u0026apos;s\nGVA space) are to be ignored. While not completely clear whether this\nruling also applies to non-canonical GVAs, it is likely fine to make that\nassumption, and manual testing on Azure confirms \u0026quot;real\u0026quot; Hyper-V interprets\nthe specification in the same way.\n\nSkip non-canonical GVAs when processing the list of address to avoid\ntripping the INVVPID failure. Alternatively, KVM could filter out \u0026quot;bad\u0026quot;\nGVAs before inserting into the FIFO, but practically speaking the only\ndownside of pushing validation to the final processing is that doing so\nis suboptimal for the guest, and no well-behaved guest will request TLB\nflushes for non-canonical addresses.(CVE-2025-38351)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nplatform/x86: dell-wmi-sysman: Fix WMI data block retrieval in sysfs callbacks\n\nAfter retrieving WMI data blocks in sysfs callbacks, check for the\nvalidity of them before dereferencing their content.(CVE-2025-38412)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: core: do not bypass hid_hw_raw_request\n\nhid_hw_raw_request() is actually useful to ensure the provided buffer\nand length are valid. Directly calling in the low level transport driver\nfunction bypassed those checks and allowed invalid paramto be used.(CVE-2025-38494)\n\nIn the Linux kernel, the collect_md property of xfrm interfaces can only be set during device creation. However, the xfrmi_changelink() function failed to properly validate this when called. This resulted in the erroneous placement of the special interface xi in the xfrmi_net-\u0026gt;xfrmi hash when attempting to modify a collect_md interface. Since it also exists in the xfrmi_net-\u0026gt;collect_md_xfrmi pointer, this led to a double free when the net namespace was taken down, causing a kernel crash.(CVE-2025-38500)\n\nIn the Linux kernel, the wx_rx_buffer structure contained two DMA address fields: \u0026apos;dma\u0026apos; and \u0026apos;page_dma\u0026apos;. However, only \u0026apos;page_dma\u0026apos; was actually initialized and used to program the Rx descriptor. But \u0026apos;dma\u0026apos; was uninitialized and used in some paths. This could lead to undefined behavior, including DMA errors or use-after-free, if the uninitialized \u0026apos;dma\u0026apos; was used. Although such error has not yet occurred, it is worth fixing in the code.(CVE-2025-38533)\n\nIn the Linux kernel, the following vulnerability has been resolved: HID: quirks: Add quirk for 2 Chicony Electronics HP 5MP Cameras. The Chicony Electronics HP 5MP Cameras (USB ID 04F2:B824 \u0026amp; 04F2:B82C) report a HID sensor interface that is not actually implemented. Attempting to access this non-functional sensor via iio_info causes system hangs as runtime PM tries to wake up an unresponsive sensor. Add these 2 devices to the HID ignore list since the sensor interface is non-functional by design and should not be exposed to userspace.(CVE-2025-38540)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf/core: Prevent VMA split of buffer mappings\n\nThe perf mmap code is careful about mmap()\u0026apos;ing the user page with the\nringbuffer and additionally the auxiliary buffer, when the event supports\nit. Once the first mapping is established, subsequent mapping have to use\nthe same offset and the same size in both cases. The reference counting for\nthe ringbuffer and the auxiliary buffer depends on this being correct.\n\nThough perf does not prevent that a related mapping is split via mmap(2),\nmunmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls,\nwhich take reference counts, but then the subsequent perf_mmap_close()\ncalls are not longer fulfilling the offset and size checks. This leads to\nreference count leaks.\n\nAs perf already has the requirement for subsequent mappings to match the\ninitial mapping, the obvious consequence is that VMA splits, caused by\nresizing of a mapping or partial unmapping, have to be prevented.\n\nImplement the vm_operations_struct::may_split() callback and return\nunconditionally -EINVAL.\n\nThat ensures that the mapping offsets and sizes cannot be changed after the\nfact. Remapping to a different fixed address with the same size is still\npossible as it takes the references for the new mapping and drops those of\nthe old mapping.(CVE-2025-38563)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbenet: fix BUG when creating VFs\n\nbenet crashes as soon as SRIOV VFs are created:\n\n kernel BUG at mm/vmalloc.c:3457!\n Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI\n CPU: 4 UID: 0 PID: 7408 Comm: test.sh Kdump: loaded Not tainted 6.16.0+ #1 PREEMPT(voluntary)\n [...]\n RIP: 0010:vunmap+0x5f/0x70\n [...]\n Call Trace:\n \u0026lt;TASK\u0026gt;\n __iommu_dma_free+0xe8/0x1c0\n be_cmd_set_mac_list+0x3fe/0x640 [be2net]\n be_cmd_set_mac+0xaf/0x110 [be2net]\n be_vf_eth_addr_config+0x19f/0x330 [be2net]\n be_vf_setup+0x4f7/0x990 [be2net]\n be_pci_sriov_configure+0x3a1/0x470 [be2net]\n sriov_numvfs_store+0x20b/0x380\n kernfs_fop_write_iter+0x354/0x530\n vfs_write+0x9b9/0xf60\n ksys_write+0xf3/0x1d0\n do_syscall_64+0x8c/0x3d0\n\nbe_cmd_set_mac_list() calls dma_free_coherent() under a spin_lock_bh.\nFix it by freeing only after the lock has been released.(CVE-2025-38569)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvmci: Prevent the dispatching of uninitialized payloads\n\nThe reproducer executes the host\u0026apos;s unlocked_ioctl call in two different\ntasks. When init_context fails, the struct vmci_event_ctx is not fully\ninitialized when executing vmci_datagram_dispatch() to send events to all\nvm contexts. This affects the datagram taken from the datagram queue of\nits context by another task, because the datagram payload is not initialized\naccording to the size payload_size, which causes the kernel data to leak\nto the user space.\n\nBefore dispatching the datagram, and before setting the payload content,\nexplicitly set the payload content to 0 to avoid data leakage caused by\nincomplete payload initialization.(CVE-2025-38611)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npinmux: fix race causing mux_owner NULL with active mux_usecount\n\ncommit 5a3e85c3c397 (\u0026quot;pinmux: Use sequential access to access\ndesc-\u0026gt;pinmux data\u0026quot;) tried to address the issue when two client of the\nsame gpio calls pinctrl_select_state() for the same functionality, was\nresulting in NULL pointer issue while accessing desc-\u0026gt;mux_owner.\nHowever, issue was not completely fixed due to the way it was handled\nand it can still result in the same NULL pointer.\n\nThe issue occurs due to the following interleaving:\n\n cpu0 (process A) cpu1 (process B)\n\n pin_request() { pin_free() {\n\n mutex_lock()\n desc-\u0026gt;mux_usecount--; //becomes 0\n ..\n mutex_unlock()\n\n mutex_lock(desc-\u0026gt;mux)\n desc-\u0026gt;mux_usecount++; // becomes 1\n desc-\u0026gt;mux_owner = owner;\n mutex_unlock(desc-\u0026gt;mux)\n\n mutex_lock(desc-\u0026gt;mux)\n desc-\u0026gt;mux_owner = NULL;\n mutex_unlock(desc-\u0026gt;mux)\n\nThis sequence leads to a state where the pin appears to be in use\n(`mux_usecount == 1`) but has no owner (`mux_owner == NULL`), which can\ncause NULL pointer on next pin_request on the same pin.\n\nEnsure that updates to mux_usecount and mux_owner are performed\natomically under the same lock. Only clear mux_owner when mux_usecount\nreaches zero and no new owner has been assigned.(CVE-2025-38632)\n\nIn the Linux kernel, a vulnerability has been resolved where checking proc_lseek in the same manner as proc_read_iter and others could lead to a Use-After-Free (UAF) scenario during rmmod. This was a gap in proc_reg_open() after commit 654b33ada4ab (proc: fix UAF in proc_get_inode()). Following AI Viro\u0026apos;s suggestion, it was fixed in the same manner.(CVE-2025-38653)\n\nIn the Linux kernel, a vulnerability was found in the i2c: qup driver where the original logic only sets the return value but does not break out of the loop when the bus remains active due to a client. This unexpected behavior could allow a malicious or faulty i2c client to hang the kernel. The issue was observed during long-term testing with a PCA953x GPIO extender. The fix modifies the logic to not only set the return value but also break out of the loop and return -ETIMEDOUT to the caller.(CVE-2025-38671)",
"id": "OESA-2025-2122",
"modified": "2026-08-06T11:09:12Z",
"published": "2025-09-05T11:09:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2122"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21678"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21723"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21864"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21955"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22007"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22021"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22056"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22057"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22063"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22064"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22086"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22089"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22106"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37749"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37752"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37772"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37789"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37794"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37829"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37834"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37859"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37875"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37879"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37885"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37909"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37911"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37912"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37932"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37945"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37959"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37960"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37961"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37989"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37990"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38003"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38004"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38010"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38019"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38020"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38022"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38024"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38039"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38042"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38044"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38057"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38066"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38085"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38087"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38097"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38129"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38154"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38165"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38166"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38177"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38201"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38351"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38412"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38494"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38500"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38533"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38540"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38563"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38569"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38611"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38632"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38653"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38671"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2025-21678",
"CVE-2025-21723",
"CVE-2025-21864",
"CVE-2025-21955",
"CVE-2025-22007",
"CVE-2025-22021",
"CVE-2025-22056",
"CVE-2025-22057",
"CVE-2025-22063",
"CVE-2025-22064",
"CVE-2025-22086",
"CVE-2025-22089",
"CVE-2025-22106",
"CVE-2025-37749",
"CVE-2025-37752",
"CVE-2025-37772",
"CVE-2025-37789",
"CVE-2025-37794",
"CVE-2025-37829",
"CVE-2025-37834",
"CVE-2025-37859",
"CVE-2025-37875",
"CVE-2025-37879",
"CVE-2025-37885",
"CVE-2025-37909",
"CVE-2025-37911",
"CVE-2025-37912",
"CVE-2025-37932",
"CVE-2025-37945",
"CVE-2025-37959",
"CVE-2025-37960",
"CVE-2025-37961",
"CVE-2025-37989",
"CVE-2025-37990",
"CVE-2025-38003",
"CVE-2025-38004",
"CVE-2025-38010",
"CVE-2025-38019",
"CVE-2025-38020",
"CVE-2025-38022",
"CVE-2025-38024",
"CVE-2025-38039",
"CVE-2025-38042",
"CVE-2025-38044",
"CVE-2025-38057",
"CVE-2025-38066",
"CVE-2025-38085",
"CVE-2025-38087",
"CVE-2025-38097",
"CVE-2025-38129",
"CVE-2025-38154",
"CVE-2025-38165",
"CVE-2025-38166",
"CVE-2025-38177",
"CVE-2025-38201",
"CVE-2025-38351",
"CVE-2025-38412",
"CVE-2025-38494",
"CVE-2025-38500",
"CVE-2025-38533",
"CVE-2025-38540",
"CVE-2025-38563",
"CVE-2025-38569",
"CVE-2025-38611",
"CVE-2025-38632",
"CVE-2025-38653",
"CVE-2025-38671"
]
}
OESA-2025-2800 (CVE-2023-53091)
Vulnerability from osv_openeuler – Published: 2025-12-12 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:
ext4: update s_journal_inum if it changes after journal replay
When mounting a crafted ext4 image, s_journal_inum may change after journal replay, which is obviously unreasonable because we have successfully loaded and replayed the journal through the old s_journal_inum. And the new s_journal_inum bypasses some of the checks in ext4_get_journal(), which may trigger a null pointer dereference problem. So if s_journal_inum changes after the journal replay, we ignore the change, and rewrite the current journal_inum to the superblock.(CVE-2023-53091)
In the Linux kernel, the following vulnerability has been resolved:
vxlan: Fix nexthop hash size
The nexthop code expects a 31 bit hash, such as what is returned by fib_multipath_hash() and rt6_multipath_hash(). Passing the 32 bit hash returned by skb_get_hash() can lead to problems related to the fact that 'int hash' is a negative number when the MSB is set.
In the case of hash threshold nexthop groups, nexthop_select_path_hthr() will disproportionately select the first nexthop group entry. In the case of resilient nexthop groups, nexthop_select_path_res() may do an out of bounds access in nh_buckets[], for example: hash = -912054133 num_nh_buckets = 2 bucket_index = 65535
which leads to the following panic:
BUG: unable to handle page fault for address: ffffc900025910c8 PGD 100000067 P4D 100000067 PUD 10026b067 PMD 0 Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI CPU: 4 PID: 856 Comm: kworker/4:3 Not tainted 6.5.0-rc2+ #34 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:nexthop_select_path+0x197/0xbf0 Code: c1 e4 05 be 08 00 00 00 4c 8b 35 a4 14 7e 01 4e 8d 6c 25 00 4a 8d 7c 25 08 48 01 dd e8 c2 25 15 ff 49 8d 7d 08 e8 39 13 15 ff <4d> 89 75 08 48 89 ef e8 7d 12 15 ff 48 8b 5d 00 e8 14 55 2f 00 85 RSP: 0018:ffff88810c36f260 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 00000000002000c0 RCX: ffffffffaf02dd77 RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffffc900025910c8 RBP: ffffc900025910c0 R08: 0000000000000001 R09: fffff520004b2219 R10: ffffc900025910cf R11: 31392d2068736168 R12: 00000000002000c0 R13: ffffc900025910c0 R14: 00000000fffef608 R15: ffff88811840e900 FS: 0000000000000000(0000) GS:ffff8881f7000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc900025910c8 CR3: 0000000129d00000 CR4: 0000000000750ee0 PKRU: 55555554 Call Trace: <TASK> ? __die+0x23/0x70 ? page_fault_oops+0x1ee/0x5c0 ? __pfx_is_prefetch.constprop.0+0x10/0x10 ? __pfx_page_fault_oops+0x10/0x10 ? search_bpf_extables+0xfe/0x1c0 ? fixup_exception+0x3b/0x470 ? exc_page_fault+0xf6/0x110 ? asm_exc_page_fault+0x26/0x30 ? nexthop_select_path+0x197/0xbf0 ? nexthop_select_path+0x197/0xbf0 ? lock_is_held_type+0xe7/0x140 vxlan_xmit+0x5b2/0x2340 ? __lock_acquire+0x92b/0x3370 ? __pfx_vxlan_xmit+0x10/0x10 ? __pfxlockacquire+0x10/0x10 ? pfx_register_lock_class+0x10/0x10 ? skb_network_protocol+0xce/0x2d0 ? dev_hard_start_xmit+0xca/0x350 ? __pfx_vxlan_xmit+0x10/0x10 dev_hard_start_xmit+0xca/0x350 __dev_queue_xmit+0x513/0x1e20 ? __pfxdevqueue_xmit+0x10/0x10 ? pfx_lock_release+0x10/0x10 ? mark_held_locks+0x44/0x90 ? skb_push+0x4c/0x80 ? eth_header+0x81/0xe0 ? __pfx_eth_header+0x10/0x10 ? neigh_resolve_output+0x215/0x310 ? ip6_finish_output2+0x2ba/0xc90 ip6_finish_output2+0x2ba/0xc90 ? lock_release+0x236/0x3e0 ? ip6_mtu+0xbb/0x240 ? __pfx_ip6_finish_output2+0x10/0x10 ? find_held_lock+0x83/0xa0 ? lock_is_held_type+0xe7/0x140 ip6_finish_output+0x1ee/0x780 ip6_output+0x138/0x460 ? __pfx_ip6_output+0x10/0x10 ? __pfxlockacquire+0x10/0x10 ? pfx_ip6_finish_output+0x10/0x10 NF_HOOK.constprop.0+0xc0/0x420 ? __pfx_NF_HOOK.constprop.0+0x10/0x10 ? ndisc_send_skb+0x2c0/0x960 ? __pfx_lock_release+0x10/0x10 ? __local_bh_enable_ip+0x93/0x110 ? lock_is_held_type+0xe7/0x140 ndisc_send_skb+0x4be/0x960 ? __pfx_ndisc_send_skb+0x10/0x10 ? mark_held_locks+0x65/0x90 ? find_held_lock+0x83/0xa0 ndisc_send_ns+0xb0/0x110 ? __pfx_ndisc_send_ns+0x10/0x10 addrconf_dad_work+0x631/0x8e0 ? lock_acquire+0x180/0x3f0 ? __pfx_addrconf_dad_work+0x10/0x10 ? mark_held_locks+0x24/0x90 process_one_work+0x582/0x9c0 ? __pfx_process_one_work+0x10/0x10 ? __pfx_do_raw_spin_lock+0x10/0x10 ? mark_held_locks+0x24/0x90 worker_thread+0x93/0x630 ? __kthread_parkme+0xdc/0x100 ? __pfx_worker_thread+0x10/0x10 kthread+0x1a5/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x60
---truncated---(CVE-2023-53192)
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix use-after-free KFENCE violation during sysfs firmware write
During the sysfs firmware write process, a use-after-free read warning is logged from the lpfc_wr_object() routine:
BUG: KFENCE: use-after-free read in lpfc_wr_object+0x235/0x310 [lpfc] Use-after-free read at 0x0000000000cf164d (in kfence-#111): lpfc_wr_object+0x235/0x310 [lpfc] lpfc_write_firmware.cold+0x206/0x30d [lpfc] lpfc_sli4_request_firmware_update+0xa6/0x100 [lpfc] lpfc_request_firmware_upgrade_store+0x66/0xb0 [lpfc] kernfs_fop_write_iter+0x121/0x1b0 new_sync_write+0x11c/0x1b0 vfs_write+0x1ef/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x59/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd
The driver accessed wr_object pointer data, which was initialized into mailbox payload memory, after the mailbox object was released back to the mailbox pool.
Fix by moving the mailbox free calls to the end of the routine ensuring that we don't reference internal mailbox memory after release.(CVE-2023-53282)
In the Linux kernel, the following vulnerability has been resolved:
start_kernel: Add __no_stack_protector function attribute
Back during the discussion of commit a9a3ed1eff36 ("x86: Fix early boot crash on gcc-10, third try") we discussed the need for a function attribute to control the omission of stack protectors on a per-function basis; at the time Clang had support for no_stack_protector but GCC did not. This was fixed in gcc-11. Now that the function attribute is available, let's start using it.
Callers of boot_init_stack_canary need to use this function attribute unless they're compiled with -fno-stack-protector, otherwise the canary stored in the stack slot of the caller will differ upon the call to boot_init_stack_canary. This will lead to a call to __stack_chk_fail() then panic.(CVE-2023-53491)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix hci_suspend_sync crash
If hci_unregister_dev() frees the hci_dev object but hci_suspend_notifier may still be accessing it, it can cause the program to crash. Here's the call trace: <4>[102152.653246] Call Trace: <4>[102152.653254] hci_suspend_sync+0x109/0x301 [bluetooth] <4>[102152.653259] hci_suspend_dev+0x78/0xcd [bluetooth] <4>[102152.653263] hci_suspend_notifier+0x42/0x7a [bluetooth] <4>[102152.653268] notifier_call_chain+0x43/0x6b <4>[102152.653271] __blocking_notifier_call_chain+0x48/0x69 <4>[102152.653273] __pm_notifier_call_chain+0x22/0x39 <4>[102152.653276] pm_suspend+0x287/0x57c <4>[102152.653278] state_store+0xae/0xe5 <4>[102152.653281] kernfs_fop_write+0x109/0x173 <4>[102152.653284] __vfs_write+0x16f/0x1a2 <4>[102152.653287] ? selinux_file_permission+0xca/0x16f <4>[102152.653289] ? security_file_permission+0x36/0x109 <4>[102152.653291] vfs_write+0x114/0x21d <4>[102152.653293] __x64_sys_write+0x7b/0xdb <4>[102152.653296] do_syscall_64+0x59/0x194 <4>[102152.653299] entry_SYSCALL_64_after_hwframe+0x5c/0xc1
This patch holds the reference count of the hci_dev object while processing it in hci_suspend_notifier to avoid potential crash caused by the race condition.(CVE-2023-53520)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_event: call disconnect callback before deleting conn
In hci_cs_disconnect, we do hci_conn_del even if disconnection failed.
ISO, L2CAP and SCO connections refer to the hci_conn without hci_conn_get, so disconn_cfm must be called so they can clean up their conn, otherwise use-after-free occurs.
ISO:
iso_sock_connect:880: sk 00000000eabd6557 iso_connect_cis:356: 70:1a:b8:98:ff:a2 -> 28:3d:c2:4a:7e:da ... iso_conn_add:140: hcon 000000001696f1fd conn 00000000b6251073 hci_dev_put:1487: hci0 orig refcnt 17 __iso_chan_add:214: conn 00000000b6251073 iso_sock_clear_timer:117: sock 00000000eabd6557 state 3 ... hci_rx_work:4085: hci0 Event packet hci_event_packet:7601: hci0: event 0x0f hci_cmd_status_evt:4346: hci0: opcode 0x0406 hci_cs_disconnect:2760: hci0: status 0x0c hci_sent_cmd_data:3107: hci0 opcode 0x0406 hci_conn_del:1151: hci0 hcon 000000001696f1fd handle 2560 hci_conn_unlink:1102: hci0: hcon 000000001696f1fd hci_conn_drop:1451: hcon 00000000d8521aaf orig refcnt 2 hci_chan_list_flush:2780: hcon 000000001696f1fd hci_dev_put:1487: hci0 orig refcnt 21 hci_dev_put:1487: hci0 orig refcnt 20 hci_req_cmd_complete:3978: opcode 0x0406 status 0x0c ... <no iso_* activity on sk/conn> ... iso_sock_sendmsg:1098: sock 00000000dea5e2e0, sk 00000000eabd6557 BUG: kernel NULL pointer dereference, address: 0000000000000668 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014 RIP: 0010:iso_sock_sendmsg (net/bluetooth/iso.c:1112) bluetooth ==========================================================
L2CAP:
hci_cmd_status_evt:4359: hci0: opcode 0x0406 hci_cs_disconnect:2760: hci0: status 0x0c hci_sent_cmd_data:3085: hci0 opcode 0x0406 hci_conn_del:1151: hci0 hcon ffff88800c999000 handle 3585 hci_conn_unlink:1102: hci0: hcon ffff88800c999000 hci_chan_list_flush:2780: hcon ffff88800c999000 hci_chan_del:2761: hci0 hcon ffff88800c999000 chan ffff888018ddd280 ... BUG: KASAN: slab-use-after-free in hci_send_acl+0x2d/0x540 [bluetooth] Read of size 8 at addr ffff888018ddd298 by task bluetoothd/1175
CPU: 0 PID: 1175 Comm: bluetoothd Tainted: G E 6.4.0-rc4+ #2 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x5b/0x90 print_report+0xcf/0x670 ? __virt_addr_valid+0xf8/0x180 ? hci_send_acl+0x2d/0x540 [bluetooth] kasan_report+0xa8/0xe0 ? hci_send_acl+0x2d/0x540 [bluetooth] hci_send_acl+0x2d/0x540 [bluetooth] ? __pfxlockacquire+0x10/0x10 l2cap_chan_send+0x1fd/0x1300 [bluetooth] ? l2cap_sock_sendmsg+0xf2/0x170 [bluetooth] ? pfx_l2cap_chan_send+0x10/0x10 [bluetooth] ? lock_release+0x1d5/0x3c0 ? mark_held_locks+0x1a/0x90 l2cap_sock_sendmsg+0x100/0x170 [bluetooth] sock_write_iter+0x275/0x280 ? __pfx_sock_write_iter+0x10/0x10 ? __pfxlockacquire+0x10/0x10 do_iter_readv_writev+0x176/0x220 ? pfx_do_iter_readv_writev+0x10/0x10 ? find_held_lock+0x83/0xa0 ? selinux_file_permission+0x13e/0x210 do_iter_write+0xda/0x340 vfs_writev+0x1b4/0x400 ? __pfx_vfs_writev+0x10/0x10 ? __seccomp_filter+0x112/0x750 ? populate_seccomp_data+0x182/0x220 ? __fget_light+0xdf/0x100 ? do_writev+0x19d/0x210 do_writev+0x19d/0x210 ? __pfx_do_writev+0x10/0x10 ? mark_held_locks+0x1a/0x90 do_syscall_64+0x60/0x90 ? lockdep_hardirqs_on_prepare+0x149/0x210 ? do_syscall_64+0x6c/0x90 ? lockdep_hardirqs_on_prepare+0x149/0x210 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7ff45cb23e64 Code: 15 d1 1f 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d 9d a7 0d 00 00 74 13 b8 14 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89 RSP: 002b:00007fff21ae09b8 EFLAGS: 00000202 ORIG_RAX: 0000000000000014 RAX: ffffffffffffffda RBX: ---truncated---(CVE-2023-53673)
In the Linux kernel, the following vulnerability has been resolved:bpf: Allow delete from sockmap/sockhash only if update is allowedWe have seen an influx of syzkaller reports where a BPF program attached toa tracepoint triggers a locking rule violation by performing a map_deleteon a sockmap/sockhash.We don t intend to support this artificial use scenario. Extend theexisting verifier allowed-program-type check for updating sockmap/sockhashto also cover deleting from a map.From now on only BPF programs which were previously allowed to updatesockmap/sockhash can delete from these map types.(CVE-2024-38662)
In the Linux kernel, the following vulnerability has been resolved:Revert mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again Patch series mm: Avoid possible overflows in dirty throttling .Dirty throttling logic assumes dirty limits in page units fit into32-bits. This patch series makes sure this is true (see patch 2/2 formore details).This patch (of 2):This reverts commit 9319b647902cbd5cc884ac08a8a6d54ce111fc78.The commit is broken in several ways. Firstly, the removed (u64) castfrom the multiplication will introduce a multiplication overflow on 32-bitarchs if wb_thresh * bg_thresh >= 1<<32 (which is actually common - thedefault settings with 4GB of RAM will trigger this). Secondly, thediv64_u64() is unnecessarily expensive on 32-bit archs. We havediv64_ul() in case we want to be safe & cheap. Thirdly, if dirtythresholds are larger than 1<<32 pages, then dirty balancing is going toblow up in many other spectacular ways anyway so trying to fix onepossible overflow is just moot.(CVE-2024-42102)
In the Linux kernel, the following vulnerability has been resolved:nfsd: map the EBADMSG to nfserr_io to avoid warningExt4 will throw -EBADMSG through ext4_readdir when a checksum erroroccurs, resulting in the following WARNING.Fix it by mapping EBADMSG to nfserr_io.nfsd_buffered_readdir iterate_dir // -EBADMSG -74 ext4_readdir // .iterate_shared ext4_dx_readdir ext4_htree_fill_tree htree_dirblock_to_tree ext4_read_dirblock __ext4_read_dirblock ext4_dirblock_csum_verify warn_no_space_for_csum __warn_no_space_for_csum return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // WARNING[ 161.115610] ------------[ cut here ]------------[ 161.116465] nfsd: non-standard errno: -74[ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0[ 161.118596] Modules linked in:[ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138[ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014[ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0[ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 <0f> 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33[ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286[ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000[ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a[ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827[ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021[ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8[ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000[ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0[ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 161.141519] PKRU: 55555554[ 161.142076] Call Trace:[ 161.142575] ? __warn+0x9b/0x140[ 161.143229] ? nfserrno+0x9d/0xd0[ 161.143872] ? report_bug+0x125/0x150[ 161.144595] ? handle_bug+0x41/0x90[ 161.145284] ? exc_invalid_op+0x14/0x70[ 161.146009] ? asm_exc_invalid_op+0x12/0x20[ 161.146816] ? nfserrno+0x9d/0xd0[ 161.147487] nfsd_buffered_readdir+0x28b/0x2b0[ 161.148333] ? nfsd4_encode_dirent_fattr+0x380/0x380[ 161.149258] ? nfsd_buffered_filldir+0xf0/0xf0[ 161.150093] ? wait_for_concurrent_writes+0x170/0x170[ 161.151004] ? generic_file_llseek_size+0x48/0x160[ 161.151895] nfsd_readdir+0x132/0x190[ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380[ 161.153516] ? nfsd_unlink+0x380/0x380[ 161.154256] ? override_creds+0x45/0x60[ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0[ 161.155850] ? nfsd4_encode_readlink+0x210/0x210[ 161.156731] ? write_bytes_to_xdr_buf+0x97/0xe0[ 161.157598] ? __write_bytes_to_xdr_buf+0xd0/0xd0[ 161.158494] ? lock_downgrade+0x90/0x90[ 161.159232] ? nfs4svc_decode_voidarg+0x10/0x10[ 161.160092] nfsd4_encode_operation+0x15a/0x440[ 161.160959] nfsd4_proc_compound+0x718/0xe90[ 161.161818] nfsd_dispatch+0x18e/0x2c0[ 161.162586] svc_process_common+0x786/0xc50[ 161.163403] ? nfsd_svc+0x380/0x380[ 161.164137] ? svc_printk+0x160/0x160[ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380[ 161.165808] ? nfsd_svc+0x380/0x380[ 161.166523] ? rcu_is_watching+0x23/0x40[ 161.167309] svc_process+0x1a5/0x200[ 161.168019] nfsd+0x1f5/0x380[ 161.168663] ? nfsd_shutdown_threads+0x260/0x260[ 161.169554] kthread+0x1c4/0x210[ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80[ 161.171246] ret_from_fork+0x1f/0x30(CVE-2024-49875)
In the Linux kernel, the following vulnerability has been resolved:
iio: adc: rockchip_saradc: fix information leak in triggered buffer
The 'data' local struct is used to push data to user space from a triggered buffer, but it does not set values for inactive channels, as it only uses iio_for_each_active_channel() to assign new values.
Initialize the struct to zero before using it to avoid pushing uninitialized information to userspace.(CVE-2024-57907)
In the Linux kernel, the following vulnerability has been resolved:
iio: dummy: iio_simply_dummy_buffer: fix information leak in triggered buffer
The 'data' array is allocated via kmalloc() and it is used to push data to user space from a triggered buffer, but it does not set values for inactive channels, as it only uses iio_for_each_active_channel() to assign new values.
Use kzalloc for the memory allocation to avoid pushing uninitialized information to userspace.(CVE-2024-57911)
In the Linux kernel, the following vulnerability has been resolved:
memory: tegra20-emc: fix an OF node reference bug in tegra_emc_find_node_by_ram_code()
As of_find_node_by_name() release the reference of the argument device node, tegra_emc_find_node_by_ram_code() releases some device nodes while still in use, resulting in possible UAFs. According to the bindings and the in-tree DTS files, the "emc-tables" node is always device's child node with the property "nvidia,use-ram-code", and the "lpddr2" node is a child of the "emc-tables" node. Thus utilize the for_each_child_of_node() macro and of_get_child_by_name() instead of of_find_node_by_name() to simplify the code.
This bug was found by an experimental verification tool that I am developing.
krzysztof: applied v1, adjust the commit msg to incorporate v2 parts
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: limit printed string from FW file
There's no guarantee here that the file is always with a NUL-termination, so reading the string may read beyond the end of the TLV. If that's the last TLV in the file, it can perhaps even read beyond the end of the file buffer.
Fix that by limiting the print format to the size of the buffer we have.(CVE-2025-21905)
In the Linux kernel, the following vulnerability has been resolved:
memstick: rtsx_usb_ms: Fix slab-use-after-free in rtsx_usb_ms_drv_remove
This fixes the following crash:
================================================================== BUG: KASAN: slab-use-after-free in rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] Read of size 8 at addr ffff888136335380 by task kworker/6:0/140241
CPU: 6 UID: 0 PID: 140241 Comm: kworker/6:0 Kdump: loaded Tainted: G E 6.14.0-rc6+ #1 Tainted: [E]=UNSIGNED_MODULE Hardware name: LENOVO 30FNA1V7CW/1057, BIOS S0EKT54A 07/01/2024 Workqueue: events rtsx_usb_ms_poll_card [rtsx_usb_ms] Call Trace: <TASK> dump_stack_lvl+0x51/0x70 print_address_description.constprop.0+0x27/0x320 ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] print_report+0x3e/0x70 kasan_report+0xab/0xe0 ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] ? __pfx_rtsx_usb_ms_poll_card+0x10/0x10 [rtsx_usb_ms] ? __pfxschedule+0x10/0x10 ? kickpool+0x3b/0x270 process_one_work+0x357/0x660 worker_thread+0x390/0x4c0 ? pfx_worker_thread+0x10/0x10 kthread+0x190/0x1d0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK>
Allocated by task 161446: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0x7b/0x90 __kmalloc_noprof+0x1a7/0x470 memstick_alloc_host+0x1f/0xe0 [memstick] rtsx_usb_ms_drv_probe+0x47/0x320 [rtsx_usb_ms] platform_probe+0x60/0xe0 call_driver_probe+0x35/0x120 really_probe+0x123/0x410 __driver_probe_device+0xc7/0x1e0 driver_probe_device+0x49/0xf0 __device_attach_driver+0xc6/0x160 bus_for_each_drv+0xe4/0x160 __device_attach+0x13a/0x2b0 bus_probe_device+0xbd/0xd0 device_add+0x4a5/0x760 platform_device_add+0x189/0x370 mfd_add_device+0x587/0x5e0 mfd_add_devices+0xb1/0x130 rtsx_usb_probe+0x28e/0x2e0 [rtsx_usb] usb_probe_interface+0x15c/0x460 call_driver_probe+0x35/0x120 really_probe+0x123/0x410 __driver_probe_device+0xc7/0x1e0 driver_probe_device+0x49/0xf0 __device_attach_driver+0xc6/0x160 bus_for_each_drv+0xe4/0x160 __device_attach+0x13a/0x2b0 rebind_marked_interfaces.isra.0+0xcc/0x110 usb_reset_device+0x352/0x410 usbdev_do_ioctl+0xe5c/0x1860 usbdev_ioctl+0xa/0x20 __x64_sys_ioctl+0xc5/0xf0 do_syscall_64+0x59/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Freed by task 161506: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x36/0x60 __kasan_slab_free+0x34/0x50 kfree+0x1fd/0x3b0 device_release+0x56/0xf0 kobject_cleanup+0x73/0x1c0 rtsx_usb_ms_drv_remove+0x13d/0x220 [rtsx_usb_ms] platform_remove+0x2f/0x50 device_release_driver_internal+0x24b/0x2e0 bus_remove_device+0x124/0x1d0 device_del+0x239/0x530 platform_device_del.part.0+0x19/0xe0 platform_device_unregister+0x1c/0x40 mfd_remove_devices_fn+0x167/0x170 device_for_each_child_reverse+0xc9/0x130 mfd_remove_devices+0x6e/0xa0 rtsx_usb_disconnect+0x2e/0xd0 [rtsx_usb] usb_unbind_interface+0xf3/0x3f0 device_release_driver_internal+0x24b/0x2e0 proc_disconnect_claim+0x13d/0x220 usbdev_do_ioctl+0xb5e/0x1860 usbdev_ioctl+0xa/0x20 __x64_sys_ioctl+0xc5/0xf0 do_syscall_64+0x59/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Last potentially related work creation: kasan_save_stack+0x20/0x40 kasan_record_aux_stack+0x85/0x90 insert_work+0x29/0x100 __queue_work+0x34a/0x540 call_timer_fn+0x2a/0x160 expire_timers+0x5f/0x1f0 __run_timer_base.part.0+0x1b6/0x1e0 run_timer_softirq+0x8b/0xe0 handle_softirqs+0xf9/0x360 __irq_exit_rcu+0x114/0x130 sysvec_apic_timer_interrupt+0x72/0x90 asm_sysvec_apic_timer_interrupt+0x16/0x20
Second to last potentially related work creation: kasan_save_stack+0x20/0x40 kasan_record_aux_stack+0x85/0x90 insert_work+0x29/0x100 __queue_work+0x34a/0x540 call_timer_fn+0x2a/0x160 expire_timers+0x5f/0x1f0 __run_timer_base.part.0+0x1b6/0x1e0 run_timer_softirq+0x8b/0xe0 handle_softirqs+0xf9/0x ---truncated---(CVE-2025-22020)
In the Linux kernel, the following vulnerability has been resolved:
usb: xhci: Apply the link chain quirk on NEC isoc endpoints
Two clearly different specimens of NEC uPD720200 (one with start/stop bug, one without) were seen to cause IOMMU faults after some Missed Service Errors. Faulting address is immediately after a transfer ring segment and patched dynamic debug messages revealed that the MSE was received when waiting for a TD near the end of that segment:
[ 1.041954] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0 [ 1.042120] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09000 flags=0x0000] [ 1.042146] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09040 flags=0x0000]
It gets even funnier if the next page is a ring segment accessible to the HC. Below, it reports MSE in segment at ff1e8000, plows through a zero-filled page at ff1e9000 and starts reporting events for TRBs in page at ff1ea000 every microframe, instead of jumping to seg ff1e6000.
[ 7.041671] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0 [ 7.041999] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0 [ 7.042011] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042028] xhci_hcd: All TDs skipped for slot 1 ep 2. Clear skip flag. [ 7.042134] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042138] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31 [ 7.042144] xhci_hcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.042259] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042262] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31 [ 7.042266] xhci_hcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820
At some point completion events change from Isoch Buffer Overrun to Short Packet and the HC finally finds cycle bit mismatch in ff1ec000.
[ 7.098130] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13 [ 7.098132] xhci_hcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.098254] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13 [ 7.098256] xhci_hcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.098379] xhci_hcd: Overrun event on slot 1 ep 2
It's possible that data from the isochronous device were written to random buffers of pending TDs on other endpoints (either IN or OUT), other devices or even other HCs in the same IOMMU domain.
Lastly, an error from a different USB device on another HC. Was it caused by the above? I don't know, but it may have been. The disk was working without any other issues and generated PCIe traffic to starve the NEC of upstream BW and trigger those MSEs. The two HCs shared one x1 slot by means of a commercial "PCIe splitter" board.
[ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhci_hcd [ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s [ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00 [ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0
Fortunately, it appears that this ridiculous bug is avoided by setting the chain bit of Link TRBs on isochronous rings. Other ancient HCs are known which also expect the bit to be set and they ignore Link TRBs if it's not. Reportedly, 0.95 spec guaranteed that the bit is set.
The bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reports tens of MSEs per second and runs into the bug within seconds. Chaining Link TRBs allows the same workload to run for many minutes, many times.
No ne ---truncated---(CVE-2025-22022)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix overflow in dacloffset bounds check
The dacloffset field was originally typed as int and used in an unchecked addition, which could overflow and bypass the existing bounds check in both smb_check_perm_dacl() and smb_inherit_dacl().
This could result in out-of-bounds memory access and a kernel crash when dereferencing the DACL pointer.
This patch converts dacloffset to unsigned int and uses check_add_overflow() to validate access to the DACL.(CVE-2025-22039)
In the Linux kernel, the following vulnerability has been resolved:
vhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpoint
If vhost_scsi_set_endpoint is called multiple times without a vhost_scsi_clear_endpoint between them, we can hit multiple bugs found by Haoran Zhang:
- Use-after-free when no tpgs are found:
This fixes a use after free that occurs when vhost_scsi_set_endpoint is called more than once and calls after the first call do not find any tpgs to add to the vs_tpg. When vhost_scsi_set_endpoint first finds tpgs to add to the vs_tpg array match=true, so we will do:
vhost_vq_set_backend(vq, vs_tpg); ...
kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg;
If vhost_scsi_set_endpoint is called again and no tpgs are found match=false so we skip the vhost_vq_set_backend call leaving the pointer to the vs_tpg we then free via:
kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg;
If a scsi request is then sent we do:
vhost_scsi_handle_vq -> vhost_scsi_get_req -> vhost_vq_get_backend
which sees the vs_tpg we just did a kfree on.
- Tpg dir removal hang:
This patch fixes an issue where we cannot remove a LIO/target layer tpg (and structs above it like the target) dir due to the refcount dropping to -1.
The problem is that if vhost_scsi_set_endpoint detects a tpg is already in the vs->vs_tpg array or if the tpg has been removed so target_depend_item fails, the undepend goto handler will do target_undepend_item on all tpgs in the vs_tpg array dropping their refcount to 0. At this time vs_tpg contains both the tpgs we have added in the current vhost_scsi_set_endpoint call as well as tpgs we added in previous calls which are also in vs->vs_tpg.
Later, when vhost_scsi_clear_endpoint runs it will do target_undepend_item on all the tpgs in the vs->vs_tpg which will drop their refcount to -1. Userspace will then not be able to remove the tpg and will hang when it tries to do rmdir on the tpg dir.
- Tpg leak:
This fixes a bug where we can leak tpgs and cause them to be un-removable because the target name is overwritten when vhost_scsi_set_endpoint is called multiple times but with different target names.
The bug occurs if a user has called VHOST_SCSI_SET_ENDPOINT and setup a vhost-scsi device to target/tpg mapping, then calls VHOST_SCSI_SET_ENDPOINT again with a new target name that has tpgs we haven't seen before (target1 has tpg1 but target2 has tpg2). When this happens we don't teardown the old target tpg mapping and just overwrite the target name and the vs->vs_tpg array. Later when we do vhost_scsi_clear_endpoint, we are passed in either target1 or target2's name and we will only match that target's tpgs when we loop over the vs->vs_tpg. We will then return from the function without doing target_undepend_item on the tpgs.
Because of all these bugs, it looks like being able to call vhost_scsi_set_endpoint multiple times was never supported. The major user, QEMU, already has checks to prevent this use case. So to fix the issues, this patch prevents vhost_scsi_set_endpoint from being called if it's already successfully added tpgs. To add, remove or change the tpg config or target name, you must do a vhost_scsi_clear_endpoint first.(CVE-2025-22083)
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix off-by-one error in do_split
Syzkaller detected a use-after-free issue in ext4_insert_dentry that was caused by out-of-bounds access due to incorrect splitting in do_split.
BUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 Write of size 251 at addr ffff888074572f14 by task syz-executor335/5847
CPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106 ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154 make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455 ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796 ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431 vfs_symlink+0x137/0x2e0 fs/namei.c:4615 do_symlinkat+0x222/0x3a0 fs/namei.c:4641 __do_sys_symlink fs/namei.c:4662 [inline] __se_sys_symlink fs/namei.c:4660 [inline] __x64_sys_symlink+0x7a/0x90 fs/namei.c:4660 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK>
The following loop is located right above 'if' statement.
for (i = count-1; i >= 0; i--) { / is more than half of this entry in 2nd half of the block? / if (size + map[i].size/2 > blocksize/2) break; size += map[i].size; move++; }
'i' in this case could go down to -1, in which case sum of active entries wouldn't exceed half the block size, but previous behaviour would also do split in half if sum would exceed at the very last block, which in case of having too many long name files in a single block could lead to out-of-bounds access and following use-after-free.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-23150)
In the Linux kernel, the following vulnerability has been resolved:
media: venus: hfi: add check to handle incorrect queue size
qsize represents size of shared queued between driver and video firmware. Firmware can modify this value to an invalid large value. In such situation, empty_space will be bigger than the space actually available. Since new_wr_idx is not checked, so the following code will result in an OOB write. ... qsize = qhdr->q_size
if (wr_idx >= rd_idx) empty_space = qsize - (wr_idx - rd_idx) .... if (new_wr_idx < qsize) { memcpy(wr_ptr, packet, dwords << 2) --> OOB write
Add check to ensure qsize is within the allocated size while reading and writing packets into the queue.(CVE-2025-23158)
In the Linux kernel, the following vulnerability has been resolved:net: ppp: Add bound checking for skb data on ppp_sync_txmungEnsure we have enough data in linear buffer from skb before accessinginitial bytes. This prevents potential out-of-bounds accesseswhen processing short packets.When ppp_sync_txmung receives an incoming package with an emptypayload:(remote) gef➤ p (struct pppoe_hdr ) (skb->head + skb->network_header)$18 = { type = 0x1, ver = 0x1, code = 0x0, sid = 0x2, length = 0x0, tag = 0xffff8880371cdb96}from the skb struct (trimmed) tail = 0x16, end = 0x140, head = 0xffff88803346f400 4 , data = 0xffff88803346f416 : 377 , truesize = 0x380, len = 0x0, data_len = 0x0, mac_len = 0xe, hdr_len = 0x0,it is not safe to access data[2].[(CVE-2025-37749)
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix OOB read when checking dotdot dir
Mounting a corrupted filesystem with directory which contains '.' dir entry with rec_len == block size results in out-of-bounds read (later on, when the corrupted directory is removed).
ext4_empty_dir() assumes every ext4 directory contains at least '.' and '..' as directory entries in the first data block. It first loads the '.' dir entry, performs sanity checks by calling ext4_check_dir_entry() and then uses its rec_len member to compute the location of '..' dir entry (in ext4_next_entry). It assumes the '..' dir entry fits into the same data block.
If the rec_len of '.' is precisely one block (4KB), it slips through the sanity checks (it is considered the last directory entry in the data block) and leaves "struct ext4_dir_entry_2 *de" point exactly past the memory slot allocated to the data block. The following call to ext4_check_dir_entry() on new value of de then dereferences this pointer which results in out-of-bounds mem access.
Fix this by extending __ext4_check_dir_entry() to check for '.' dir entries that reach the end of data block. Make sure to ignore the phony dir entries for checksum (by checking name_len for non-zero).
Note: This is reported by KASAN as use-after-free in case another structure was recently freed from the slot past the bound, but it is really an OOB read.
This issue was found by syzkaller tool.
Call Trace: [ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710 [ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375 [ 38.595158] [ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1 [ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 38.595304] Call Trace: [ 38.595308] <TASK> [ 38.595311] dump_stack_lvl+0xa7/0xd0 [ 38.595325] print_address_description.constprop.0+0x2c/0x3f0 [ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595349] print_report+0xaa/0x250 [ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595368] ? kasan_addr_to_slab+0x9/0x90 [ 38.595378] kasan_report+0xab/0xe0 [ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595400] __ext4_check_dir_entry+0x67e/0x710 [ 38.595410] ext4_empty_dir+0x465/0x990 [ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10 [ 38.595432] ext4_rmdir.part.0+0x29a/0xd10 [ 38.595441] ? __dquot_initialize+0x2a7/0xbf0 [ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10 [ 38.595464] ? __pfxdquotinitialize+0x10/0x10 [ 38.595478] ? down_write+0xdb/0x140 [ 38.595487] ? pfx_down_write+0x10/0x10 [ 38.595497] ext4_rmdir+0xee/0x140 [ 38.595506] vfs_rmdir+0x209/0x670 [ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190 [ 38.595529] do_rmdir+0x363/0x3c0 [ 38.595537] ? __pfx_do_rmdir+0x10/0x10 [ 38.595544] ? strncpy_from_user+0x1ff/0x2e0 [ 38.595561] __x64_sys_unlinkat+0xf0/0x130 [ 38.595570] do_syscall_64+0x5b/0x180 [ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-37785)
In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: fix nested key length validation in the set() actionIt s not safe to access nla_len(ovs_key) if the data is smaller thanthe netlink header. Check that the attribute is OK first.(CVE-2025-37789)
In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid
There is a string parsing logic error which can lead to an overflow of hid or uid buffers. Comparing ACPIID_LEN against a total string length doesn't take into account the lengths of individual hid and uid buffers so the check is insufficient in some cases. For example if the length of hid string is 4 and the length of the uid string is 260, the length of str will be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer which size is 256.
The same applies to the hid string with length 13 and uid string with length 250.
Check the length of hid and uid strings separately to prevent buffer overflow.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37927)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAX
Otherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof() when resizing hashtable because __GFP_NOWARN is unset.
Similar to:
b541ba7d1f5a ("netfilter: conntrack: clamp maximum hashtable size to INT_MAX")(CVE-2025-38201)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix WARN() in get_bpf_raw_tp_regs
syzkaller reported an issue:
WARNING: CPU: 3 PID: 5971 at kernel/trace/bpf_trace.c:1861 get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861 Modules linked in: CPU: 3 UID: 0 PID: 5971 Comm: syz-executor205 Not tainted 6.15.0-rc5-syzkaller-00038-g707df3375124 #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861 RSP: 0018:ffffc90003636fa8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000003 RCX: ffffffff81c6bc4c RDX: ffff888032efc880 RSI: ffffffff81c6bc83 RDI: 0000000000000005 RBP: ffff88806a730860 R08: 0000000000000005 R09: 0000000000000003 R10: 0000000000000004 R11: 0000000000000000 R12: 0000000000000004 R13: 0000000000000001 R14: ffffc90003637008 R15: 0000000000000900 FS: 0000000000000000(0000) GS:ffff8880d6cdf000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7baee09130 CR3: 0000000029f5a000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> _bpfget_stack_raw_tp kernel/trace/bpf_trace.c:1934 [inline] bpf_get_stack_raw_tp+0x24/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47 bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline] bpf_prog_run include/linux/filter.h:718 [inline] bpf_prog_run include/linux/filter.h:725 [inline] __bpf_trace_run kernel/trace/bpf_trace.c:2363 [inline] bpf_trace_run3+0x23f/0x5a0 kernel/trace/bpf_trace.c:2405 __bpf_trace_mmap_lock_acquire_returned+0xfc/0x140 include/trace/events/mmap_lock.h:47 __traceiter_mmap_lock_acquire_returned+0x79/0xc0 include/trace/events/mmap_lock.h:47 __do_trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] __mmap_lock_do_trace_acquire_returned+0x138/0x1f0 mm/mmap_lock.c:35 __mmap_lock_trace_acquire_returned include/linux/mmap_lock.h:36 [inline] mmap_read_trylock include/linux/mmap_lock.h:204 [inline] stack_map_get_build_id_offset+0x535/0x6f0 kernel/bpf/stackmap.c:157 __bpf_get_stack+0x307/0xa10 kernel/bpf/stackmap.c:483 _bpfget_stack kernel/bpf/stackmap.c:499 [inline] bpf_get_stack+0x32/0x40 kernel/bpf/stackmap.c:496 __bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1941 [inline] bpf_get_stack_raw_tp+0x124/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47
Tracepoint like trace_mmap_lock_acquire_returned may cause nested call as the corner case show above, which will be resolved with more general method in the future. As a result, WARN_ON_ONCE will be triggered. As Alexei suggested, remove the WARN_ON_ONCE first.(CVE-2025-38285)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: Always pass notifications when child class becomes empty
Certain classful qdiscs may invoke their classes' dequeue handler on an enqueue operation. This may unexpectedly empty the child qdisc and thus make an in-flight class passive via qlen_notify(). Most qdiscs do not expect such behaviour at this point in time and may re-activate the class eventually anyways which will lead to a use-after-free.
The referenced fix commit attempted to fix this behavior for the HFSC case by moving the backlog accounting around, though this turned out to be incomplete since the parent's parent may run into the issue too. The following reproducer demonstrates this use-after-free:
tc qdisc add dev lo root handle 1: drr
tc filter add dev lo parent 1: basic classid 1:1
tc class add dev lo parent 1: classid 1:1 drr
tc qdisc add dev lo parent 1:1 handle 2: hfsc def 1
tc class add dev lo parent 2: classid 2:1 hfsc rt m1 8 d 1 m2 0
tc qdisc add dev lo parent 2:1 handle 3: netem
tc qdisc add dev lo parent 3:1 handle 4: blackhole
echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888
tc class delete dev lo classid 1:1
echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888
Since backlog accounting issues leading to a use-after-frees on stale class pointers is a recurring pattern at this point, this patch takes a different approach. Instead of trying to fix the accounting, the patch ensures that qdisc_tree_reduce_backlog always calls qlen_notify when the child qdisc is empty. This solves the problem because deletion of qdiscs always involves a call to qdisc_reset() and / or qdisc_purge_queue() which ultimately resets its qlen to 0 thus causing the following qdisc_tree_reduce_backlog() to report to the parent. Note that this may call qlen_notify on passive classes multiple times. This is not a problem after the recent patch series that made all the classful qdiscs qlen_notify() handlers idempotent.(CVE-2025-38350)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix use-after-free in cifs_oplock_break
A race condition can occur in cifs_oplock_break() leading to a use-after-free of the cinode structure when unmounting:
cifs_oplock_break() _cifsFileInfo_put(cfile) cifsFileInfo_put_final() cifs_sb_deactive() [last ref, start releasing sb] kill_sb() kill_anon_super() generic_shutdown_super() evict_inodes() dispose_list() evict() destroy_inode() call_rcu(&inode->i_rcu, i_callback) spin_lock(&cinode->open_file_lock) <- OK [later] i_callback() cifs_free_inode() kmem_cache_free(cinode) spin_unlock(&cinode->open_file_lock) <- UAF cifs_done_oplock_break(cinode) <- UAF
The issue occurs when umount has already released its reference to the superblock. When _cifsFileInfo_put() calls cifs_sb_deactive(), this releases the last reference, triggering the immediate cleanup of all inodes under RCU. However, cifs_oplock_break() continues to access the cinode after this point, resulting in use-after-free.
Fix this by holding an extra reference to the superblock during the entire oplock break operation. This ensures that the superblock and its inodes remain valid until the oplock break completes.(CVE-2025-38527)
In the Linux kernel, the following vulnerability has been resolved:
net/packet: fix a race in packet_set_ring() and packet_notifier()
When packet_set_ring() releases po->bind_lock, another thread can run packet_notifier() and process an NETDEV_UP event.
This race and the fix are both similar to that of commit 15fe076edea7 ("net/packet: fix a race in packet_bind() and packet_notifier()").
There too the packet_notifier NETDEV_UP event managed to run while a po->bind_lock critical section had to be temporarily released. And the fix was similarly to temporarily set po->num to zero to keep the socket unhooked until the lock is retaken.
The po->bind_lock in packet_set_ring and packet_notifier precede the introduction of git history.(CVE-2025-38617)
In the Linux kernel, the following vulnerability has been resolved:
ice: Fix a null pointer dereference in ice_copy_and_init_pkg()
Add check for the return value of devm_kmemdup() to prevent potential null pointer dereference.(CVE-2025-38664)
In the Linux kernel, the following vulnerability has been resolved:
ASoC: core: Check for rtd == NULL in snd_soc_remove_pcm_runtime()
snd_soc_remove_pcm_runtime() might be called with rtd == NULL which will leads to null pointer dereference. This was reproduced with topology loading and marking a link as ignore due to missing hardware component on the system. On module removal the soc_tplg_remove_link() would call snd_soc_remove_pcm_runtime() with rtd == NULL since the link was ignored, no runtime was created.(CVE-2025-38706)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: Validate UAC3 power domain descriptors, too
UAC3 power domain descriptors need to be verified with its variable bLength for avoiding the unexpected OOB accesses by malicious firmware, too.(CVE-2025-38729)
In the Linux kernel, the following vulnerability has been resolved:
vxlan: Fix NPD when refreshing an FDB entry with a nexthop object
VXLAN FDB entries can point to either a remote destination or an FDB nexthop group. The latter is usually used in EVPN deployments where learning is disabled.
However, when learning is enabled, an incoming packet might try to refresh an FDB entry that points to an FDB nexthop group and therefore does not have a remote. Such packets should be dropped, but they are only dropped after dereferencing the non-existent remote, resulting in a NPD [1] which can be reproduced using [2].
Fix by dropping such packets earlier. Remove the misleading comment from first_remote_rcu().
[1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_snoop+0x98/0x1e0 [...] Call Trace: <TASK> vxlan_encap_bypass+0x209/0x240 encap_bypass_if_local+0xb1/0x100 vxlan_xmit_one+0x1375/0x17e0 vxlan_xmit+0x6b4/0x15f0 dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53
[2] #!/bin/bash
ip address add 192.0.2.1/32 dev lo ip address add 192.0.2.2/32 dev lo
ip nexthop add id 1 via 192.0.2.3 fdb ip nexthop add id 10 group 1 fdb
ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning
bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020 bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10
mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q(CVE-2025-39851)
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Prevent access to vCPU events before init
Another day, another syzkaller bug. KVM erroneously allows userspace to pend vCPU events for a vCPU that hasn't been initialized yet, leading to KVM interpreting a bunch of uninitialized garbage for routing / injecting the exception.
In one case the injection code and the hyp disagree on whether the vCPU has a 32bit EL1 and put the vCPU into an illegal mode for AArch64, tripping the BUG() in exception_target_el() during the next injection:
kernel BUG at arch/arm64/kvm/inject_fault.c:40! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT Hardware name: linux,dummy-virt (DT) pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : exception_target_el+0x88/0x8c lr : pend_serror_exception+0x18/0x13c sp : ffff800082f03a10 x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000 x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000 x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004 x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20 Call trace: exception_target_el+0x88/0x8c (P) kvm_inject_serror_esr+0x40/0x3b4 __kvm_arm_vcpu_set_events+0xf0/0x100 kvm_arch_vcpu_ioctl+0x180/0x9d4 kvm_vcpu_ioctl+0x60c/0x9f4 __arm64_sys_ioctl+0xac/0x104 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000)
Reject the ioctls outright as no sane VMM would call these before KVM_ARM_VCPU_INIT anyway. Even if it did the exception would've been thrown away by the eventual reset of the vCPU's state.(CVE-2025-40102)
In the Linux kernel, the following vulnerability has been resolved:
smc: Use __sk_dst_get() and dst_dev_rcu() in in smc_clc_prfx_set().
smc_clc_prfx_set() is called during connect() and not under RCU nor RTNL.
Using sk_dst_get(sk)->dev could trigger UAF.
Let's use __sk_dst_get() and dev_dst_rcu() under rcu_read_lock() after kernel_getsockname().
Note that the returned value of smc_clc_prfx_set() is not used in the caller.
While at it, we change the 1st arg of smc_clc_prfx_set[46]_rcu() not to touch dst there.(CVE-2025-40139)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"kernel-debuginfo-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"kernel-debugsource-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"kernel-devel-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"kernel-headers-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"kernel-source-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"kernel-tools-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"kernel-tools-devel-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"perf-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"perf-debuginfo-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"python3-perf-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm"
],
"src": [
"kernel-5.10.0-294.0.0.196.oe2203sp3.src.rpm"
],
"x86_64": [
"kernel-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"kernel-debuginfo-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"kernel-debugsource-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"kernel-devel-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"kernel-headers-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"kernel-source-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"kernel-tools-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"kernel-tools-devel-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"perf-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"perf-debuginfo-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"python3-perf-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP3",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-294.0.0.196.oe2203sp3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: update s_journal_inum if it changes after journal replay\n\nWhen mounting a crafted ext4 image, s_journal_inum may change after journal\nreplay, which is obviously unreasonable because we have successfully loaded\nand replayed the journal through the old s_journal_inum. And the new\ns_journal_inum bypasses some of the checks in ext4_get_journal(), which\nmay trigger a null pointer dereference problem. So if s_journal_inum\nchanges after the journal replay, we ignore the change, and rewrite the\ncurrent journal_inum to the superblock.(CVE-2023-53091)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix nexthop hash size\n\nThe nexthop code expects a 31 bit hash, such as what is returned by\nfib_multipath_hash() and rt6_multipath_hash(). Passing the 32 bit hash\nreturned by skb_get_hash() can lead to problems related to the fact that\n\u0026apos;int hash\u0026apos; is a negative number when the MSB is set.\n\nIn the case of hash threshold nexthop groups, nexthop_select_path_hthr()\nwill disproportionately select the first nexthop group entry. In the case\nof resilient nexthop groups, nexthop_select_path_res() may do an out of\nbounds access in nh_buckets[], for example:\n hash = -912054133\n num_nh_buckets = 2\n bucket_index = 65535\n\nwhich leads to the following panic:\n\nBUG: unable to handle page fault for address: ffffc900025910c8\nPGD 100000067 P4D 100000067 PUD 10026b067 PMD 0\nOops: 0002 [#1] PREEMPT SMP KASAN NOPTI\nCPU: 4 PID: 856 Comm: kworker/4:3 Not tainted 6.5.0-rc2+ #34\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014\nWorkqueue: ipv6_addrconf addrconf_dad_work\nRIP: 0010:nexthop_select_path+0x197/0xbf0\nCode: c1 e4 05 be 08 00 00 00 4c 8b 35 a4 14 7e 01 4e 8d 6c 25 00 4a 8d 7c 25 08 48 01 dd e8 c2 25 15 ff 49 8d 7d 08 e8 39 13 15 ff \u0026lt;4d\u0026gt; 89 75 08 48 89 ef e8 7d 12 15 ff 48 8b 5d 00 e8 14 55 2f 00 85\nRSP: 0018:ffff88810c36f260 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 00000000002000c0 RCX: ffffffffaf02dd77\nRDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffffc900025910c8\nRBP: ffffc900025910c0 R08: 0000000000000001 R09: fffff520004b2219\nR10: ffffc900025910cf R11: 31392d2068736168 R12: 00000000002000c0\nR13: ffffc900025910c0 R14: 00000000fffef608 R15: ffff88811840e900\nFS: 0000000000000000(0000) GS:ffff8881f7000000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffc900025910c8 CR3: 0000000129d00000 CR4: 0000000000750ee0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __die+0x23/0x70\n ? page_fault_oops+0x1ee/0x5c0\n ? __pfx_is_prefetch.constprop.0+0x10/0x10\n ? __pfx_page_fault_oops+0x10/0x10\n ? search_bpf_extables+0xfe/0x1c0\n ? fixup_exception+0x3b/0x470\n ? exc_page_fault+0xf6/0x110\n ? asm_exc_page_fault+0x26/0x30\n ? nexthop_select_path+0x197/0xbf0\n ? nexthop_select_path+0x197/0xbf0\n ? lock_is_held_type+0xe7/0x140\n vxlan_xmit+0x5b2/0x2340\n ? __lock_acquire+0x92b/0x3370\n ? __pfx_vxlan_xmit+0x10/0x10\n ? __pfx___lock_acquire+0x10/0x10\n ? __pfx_register_lock_class+0x10/0x10\n ? skb_network_protocol+0xce/0x2d0\n ? dev_hard_start_xmit+0xca/0x350\n ? __pfx_vxlan_xmit+0x10/0x10\n dev_hard_start_xmit+0xca/0x350\n __dev_queue_xmit+0x513/0x1e20\n ? __pfx___dev_queue_xmit+0x10/0x10\n ? __pfx_lock_release+0x10/0x10\n ? mark_held_locks+0x44/0x90\n ? skb_push+0x4c/0x80\n ? eth_header+0x81/0xe0\n ? __pfx_eth_header+0x10/0x10\n ? neigh_resolve_output+0x215/0x310\n ? ip6_finish_output2+0x2ba/0xc90\n ip6_finish_output2+0x2ba/0xc90\n ? lock_release+0x236/0x3e0\n ? ip6_mtu+0xbb/0x240\n ? __pfx_ip6_finish_output2+0x10/0x10\n ? find_held_lock+0x83/0xa0\n ? lock_is_held_type+0xe7/0x140\n ip6_finish_output+0x1ee/0x780\n ip6_output+0x138/0x460\n ? __pfx_ip6_output+0x10/0x10\n ? __pfx___lock_acquire+0x10/0x10\n ? __pfx_ip6_finish_output+0x10/0x10\n NF_HOOK.constprop.0+0xc0/0x420\n ? __pfx_NF_HOOK.constprop.0+0x10/0x10\n ? ndisc_send_skb+0x2c0/0x960\n ? __pfx_lock_release+0x10/0x10\n ? __local_bh_enable_ip+0x93/0x110\n ? lock_is_held_type+0xe7/0x140\n ndisc_send_skb+0x4be/0x960\n ? __pfx_ndisc_send_skb+0x10/0x10\n ? mark_held_locks+0x65/0x90\n ? find_held_lock+0x83/0xa0\n ndisc_send_ns+0xb0/0x110\n ? __pfx_ndisc_send_ns+0x10/0x10\n addrconf_dad_work+0x631/0x8e0\n ? lock_acquire+0x180/0x3f0\n ? __pfx_addrconf_dad_work+0x10/0x10\n ? mark_held_locks+0x24/0x90\n process_one_work+0x582/0x9c0\n ? __pfx_process_one_work+0x10/0x10\n ? __pfx_do_raw_spin_lock+0x10/0x10\n ? mark_held_locks+0x24/0x90\n worker_thread+0x93/0x630\n ? __kthread_parkme+0xdc/0x100\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x1a5/0x1e0\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x34/0x60\n \n---truncated---(CVE-2023-53192)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: lpfc: Fix use-after-free KFENCE violation during sysfs firmware write\n\nDuring the sysfs firmware write process, a use-after-free read warning is\nlogged from the lpfc_wr_object() routine:\n\n BUG: KFENCE: use-after-free read in lpfc_wr_object+0x235/0x310 [lpfc]\n Use-after-free read at 0x0000000000cf164d (in kfence-#111):\n lpfc_wr_object+0x235/0x310 [lpfc]\n lpfc_write_firmware.cold+0x206/0x30d [lpfc]\n lpfc_sli4_request_firmware_update+0xa6/0x100 [lpfc]\n lpfc_request_firmware_upgrade_store+0x66/0xb0 [lpfc]\n kernfs_fop_write_iter+0x121/0x1b0\n new_sync_write+0x11c/0x1b0\n vfs_write+0x1ef/0x280\n ksys_write+0x5f/0xe0\n do_syscall_64+0x59/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nThe driver accessed wr_object pointer data, which was initialized into\nmailbox payload memory, after the mailbox object was released back to the\nmailbox pool.\n\nFix by moving the mailbox free calls to the end of the routine ensuring\nthat we don\u0026apos;t reference internal mailbox memory after release.(CVE-2023-53282)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nstart_kernel: Add __no_stack_protector function attribute\n\nBack during the discussion of\ncommit a9a3ed1eff36 (\u0026quot;x86: Fix early boot crash on gcc-10, third try\u0026quot;)\nwe discussed the need for a function attribute to control the omission\nof stack protectors on a per-function basis; at the time Clang had\nsupport for no_stack_protector but GCC did not. This was fixed in\ngcc-11. Now that the function attribute is available, let\u0026apos;s start using\nit.\n\nCallers of boot_init_stack_canary need to use this function attribute\nunless they\u0026apos;re compiled with -fno-stack-protector, otherwise the canary\nstored in the stack slot of the caller will differ upon the call to\nboot_init_stack_canary. This will lead to a call to __stack_chk_fail()\nthen panic.(CVE-2023-53491)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: Fix hci_suspend_sync crash\n\nIf hci_unregister_dev() frees the hci_dev object but hci_suspend_notifier\nmay still be accessing it, it can cause the program to crash.\nHere\u0026apos;s the call trace:\n \u0026lt;4\u0026gt;[102152.653246] Call Trace:\n \u0026lt;4\u0026gt;[102152.653254] hci_suspend_sync+0x109/0x301 [bluetooth]\n \u0026lt;4\u0026gt;[102152.653259] hci_suspend_dev+0x78/0xcd [bluetooth]\n \u0026lt;4\u0026gt;[102152.653263] hci_suspend_notifier+0x42/0x7a [bluetooth]\n \u0026lt;4\u0026gt;[102152.653268] notifier_call_chain+0x43/0x6b\n \u0026lt;4\u0026gt;[102152.653271] __blocking_notifier_call_chain+0x48/0x69\n \u0026lt;4\u0026gt;[102152.653273] __pm_notifier_call_chain+0x22/0x39\n \u0026lt;4\u0026gt;[102152.653276] pm_suspend+0x287/0x57c\n \u0026lt;4\u0026gt;[102152.653278] state_store+0xae/0xe5\n \u0026lt;4\u0026gt;[102152.653281] kernfs_fop_write+0x109/0x173\n \u0026lt;4\u0026gt;[102152.653284] __vfs_write+0x16f/0x1a2\n \u0026lt;4\u0026gt;[102152.653287] ? selinux_file_permission+0xca/0x16f\n \u0026lt;4\u0026gt;[102152.653289] ? security_file_permission+0x36/0x109\n \u0026lt;4\u0026gt;[102152.653291] vfs_write+0x114/0x21d\n \u0026lt;4\u0026gt;[102152.653293] __x64_sys_write+0x7b/0xdb\n \u0026lt;4\u0026gt;[102152.653296] do_syscall_64+0x59/0x194\n \u0026lt;4\u0026gt;[102152.653299] entry_SYSCALL_64_after_hwframe+0x5c/0xc1\n\nThis patch holds the reference count of the hci_dev object while\nprocessing it in hci_suspend_notifier to avoid potential crash\ncaused by the race condition.(CVE-2023-53520)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_event: call disconnect callback before deleting conn\n\nIn hci_cs_disconnect, we do hci_conn_del even if disconnection failed.\n\nISO, L2CAP and SCO connections refer to the hci_conn without\nhci_conn_get, so disconn_cfm must be called so they can clean up their\nconn, otherwise use-after-free occurs.\n\nISO:\n==========================================================\niso_sock_connect:880: sk 00000000eabd6557\niso_connect_cis:356: 70:1a:b8:98:ff:a2 -\u0026gt; 28:3d:c2:4a:7e:da\n...\niso_conn_add:140: hcon 000000001696f1fd conn 00000000b6251073\nhci_dev_put:1487: hci0 orig refcnt 17\n__iso_chan_add:214: conn 00000000b6251073\niso_sock_clear_timer:117: sock 00000000eabd6557 state 3\n...\nhci_rx_work:4085: hci0 Event packet\nhci_event_packet:7601: hci0: event 0x0f\nhci_cmd_status_evt:4346: hci0: opcode 0x0406\nhci_cs_disconnect:2760: hci0: status 0x0c\nhci_sent_cmd_data:3107: hci0 opcode 0x0406\nhci_conn_del:1151: hci0 hcon 000000001696f1fd handle 2560\nhci_conn_unlink:1102: hci0: hcon 000000001696f1fd\nhci_conn_drop:1451: hcon 00000000d8521aaf orig refcnt 2\nhci_chan_list_flush:2780: hcon 000000001696f1fd\nhci_dev_put:1487: hci0 orig refcnt 21\nhci_dev_put:1487: hci0 orig refcnt 20\nhci_req_cmd_complete:3978: opcode 0x0406 status 0x0c\n... \u0026lt;no iso_* activity on sk/conn\u0026gt; ...\niso_sock_sendmsg:1098: sock 00000000dea5e2e0, sk 00000000eabd6557\nBUG: kernel NULL pointer dereference, address: 0000000000000668\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP PTI\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014\nRIP: 0010:iso_sock_sendmsg (net/bluetooth/iso.c:1112) bluetooth\n==========================================================\n\nL2CAP:\n==================================================================\nhci_cmd_status_evt:4359: hci0: opcode 0x0406\nhci_cs_disconnect:2760: hci0: status 0x0c\nhci_sent_cmd_data:3085: hci0 opcode 0x0406\nhci_conn_del:1151: hci0 hcon ffff88800c999000 handle 3585\nhci_conn_unlink:1102: hci0: hcon ffff88800c999000\nhci_chan_list_flush:2780: hcon ffff88800c999000\nhci_chan_del:2761: hci0 hcon ffff88800c999000 chan ffff888018ddd280\n...\nBUG: KASAN: slab-use-after-free in hci_send_acl+0x2d/0x540 [bluetooth]\nRead of size 8 at addr ffff888018ddd298 by task bluetoothd/1175\n\nCPU: 0 PID: 1175 Comm: bluetoothd Tainted: G E 6.4.0-rc4+ #2\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x5b/0x90\n print_report+0xcf/0x670\n ? __virt_addr_valid+0xf8/0x180\n ? hci_send_acl+0x2d/0x540 [bluetooth]\n kasan_report+0xa8/0xe0\n ? hci_send_acl+0x2d/0x540 [bluetooth]\n hci_send_acl+0x2d/0x540 [bluetooth]\n ? __pfx___lock_acquire+0x10/0x10\n l2cap_chan_send+0x1fd/0x1300 [bluetooth]\n ? l2cap_sock_sendmsg+0xf2/0x170 [bluetooth]\n ? __pfx_l2cap_chan_send+0x10/0x10 [bluetooth]\n ? lock_release+0x1d5/0x3c0\n ? mark_held_locks+0x1a/0x90\n l2cap_sock_sendmsg+0x100/0x170 [bluetooth]\n sock_write_iter+0x275/0x280\n ? __pfx_sock_write_iter+0x10/0x10\n ? __pfx___lock_acquire+0x10/0x10\n do_iter_readv_writev+0x176/0x220\n ? __pfx_do_iter_readv_writev+0x10/0x10\n ? find_held_lock+0x83/0xa0\n ? selinux_file_permission+0x13e/0x210\n do_iter_write+0xda/0x340\n vfs_writev+0x1b4/0x400\n ? __pfx_vfs_writev+0x10/0x10\n ? __seccomp_filter+0x112/0x750\n ? populate_seccomp_data+0x182/0x220\n ? __fget_light+0xdf/0x100\n ? do_writev+0x19d/0x210\n do_writev+0x19d/0x210\n ? __pfx_do_writev+0x10/0x10\n ? mark_held_locks+0x1a/0x90\n do_syscall_64+0x60/0x90\n ? lockdep_hardirqs_on_prepare+0x149/0x210\n ? do_syscall_64+0x6c/0x90\n ? lockdep_hardirqs_on_prepare+0x149/0x210\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\nRIP: 0033:0x7ff45cb23e64\nCode: 15 d1 1f 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d 9d a7 0d 00 00 74 13 b8 14 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89\nRSP: 002b:00007fff21ae09b8 EFLAGS: 00000202 ORIG_RAX: 0000000000000014\nRAX: ffffffffffffffda RBX: \n---truncated---(CVE-2023-53673)\n\nIn the Linux kernel, the following vulnerability has been resolved:bpf: Allow delete from sockmap/sockhash only if update is allowedWe have seen an influx of syzkaller reports where a BPF program attached toa tracepoint triggers a locking rule violation by performing a map_deleteon a sockmap/sockhash.We don t intend to support this artificial use scenario. Extend theexisting verifier allowed-program-type check for updating sockmap/sockhashto also cover deleting from a map.From now on only BPF programs which were previously allowed to updatesockmap/sockhash can delete from these map types.(CVE-2024-38662)\n\nIn the Linux kernel, the following vulnerability has been resolved:Revert mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again Patch series mm: Avoid possible overflows in dirty throttling .Dirty throttling logic assumes dirty limits in page units fit into32-bits. This patch series makes sure this is true (see patch 2/2 formore details).This patch (of 2):This reverts commit 9319b647902cbd5cc884ac08a8a6d54ce111fc78.The commit is broken in several ways. Firstly, the removed (u64) castfrom the multiplication will introduce a multiplication overflow on 32-bitarchs if wb_thresh * bg_thresh \u0026gt;= 1\u0026lt;\u0026lt;32 (which is actually common - thedefault settings with 4GB of RAM will trigger this). Secondly, thediv64_u64() is unnecessarily expensive on 32-bit archs. We havediv64_ul() in case we want to be safe \u0026amp; cheap. Thirdly, if dirtythresholds are larger than 1\u0026lt;\u0026lt;32 pages, then dirty balancing is going toblow up in many other spectacular ways anyway so trying to fix onepossible overflow is just moot.(CVE-2024-42102)\n\nIn the Linux kernel, the following vulnerability has been resolved:nfsd: map the EBADMSG to nfserr_io to avoid warningExt4 will throw -EBADMSG through ext4_readdir when a checksum erroroccurs, resulting in the following WARNING.Fix it by mapping EBADMSG to nfserr_io.nfsd_buffered_readdir iterate_dir // -EBADMSG -74 ext4_readdir // .iterate_shared ext4_dx_readdir ext4_htree_fill_tree htree_dirblock_to_tree ext4_read_dirblock __ext4_read_dirblock ext4_dirblock_csum_verify warn_no_space_for_csum __warn_no_space_for_csum return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // WARNING[ 161.115610] ------------[ cut here ]------------[ 161.116465] nfsd: non-standard errno: -74[ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0[ 161.118596] Modules linked in:[ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138[ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014[ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0[ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 \u0026lt;0f\u0026gt; 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33[ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286[ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000[ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a[ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827[ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021[ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8[ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000[ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0[ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 161.141519] PKRU: 55555554[ 161.142076] Call Trace:[ 161.142575] ? __warn+0x9b/0x140[ 161.143229] ? nfserrno+0x9d/0xd0[ 161.143872] ? report_bug+0x125/0x150[ 161.144595] ? handle_bug+0x41/0x90[ 161.145284] ? exc_invalid_op+0x14/0x70[ 161.146009] ? asm_exc_invalid_op+0x12/0x20[ 161.146816] ? nfserrno+0x9d/0xd0[ 161.147487] nfsd_buffered_readdir+0x28b/0x2b0[ 161.148333] ? nfsd4_encode_dirent_fattr+0x380/0x380[ 161.149258] ? nfsd_buffered_filldir+0xf0/0xf0[ 161.150093] ? wait_for_concurrent_writes+0x170/0x170[ 161.151004] ? generic_file_llseek_size+0x48/0x160[ 161.151895] nfsd_readdir+0x132/0x190[ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380[ 161.153516] ? nfsd_unlink+0x380/0x380[ 161.154256] ? override_creds+0x45/0x60[ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0[ 161.155850] ? nfsd4_encode_readlink+0x210/0x210[ 161.156731] ? write_bytes_to_xdr_buf+0x97/0xe0[ 161.157598] ? __write_bytes_to_xdr_buf+0xd0/0xd0[ 161.158494] ? lock_downgrade+0x90/0x90[ 161.159232] ? nfs4svc_decode_voidarg+0x10/0x10[ 161.160092] nfsd4_encode_operation+0x15a/0x440[ 161.160959] nfsd4_proc_compound+0x718/0xe90[ 161.161818] nfsd_dispatch+0x18e/0x2c0[ 161.162586] svc_process_common+0x786/0xc50[ 161.163403] ? nfsd_svc+0x380/0x380[ 161.164137] ? svc_printk+0x160/0x160[ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380[ 161.165808] ? nfsd_svc+0x380/0x380[ 161.166523] ? rcu_is_watching+0x23/0x40[ 161.167309] svc_process+0x1a5/0x200[ 161.168019] nfsd+0x1f5/0x380[ 161.168663] ? nfsd_shutdown_threads+0x260/0x260[ 161.169554] kthread+0x1c4/0x210[ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80[ 161.171246] ret_from_fork+0x1f/0x30(CVE-2024-49875)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: adc: rockchip_saradc: fix information leak in triggered buffer\n\nThe \u0026apos;data\u0026apos; local struct is used to push data to user space from a\ntriggered buffer, but it does not set values for inactive channels, as\nit only uses iio_for_each_active_channel() to assign new values.\n\nInitialize the struct to zero before using it to avoid pushing\nuninitialized information to userspace.(CVE-2024-57907)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: dummy: iio_simply_dummy_buffer: fix information leak in triggered buffer\n\nThe \u0026apos;data\u0026apos; array is allocated via kmalloc() and it is used to push data\nto user space from a triggered buffer, but it does not set values for\ninactive channels, as it only uses iio_for_each_active_channel()\nto assign new values.\n\nUse kzalloc for the memory allocation to avoid pushing uninitialized\ninformation to userspace.(CVE-2024-57911)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmemory: tegra20-emc: fix an OF node reference bug in tegra_emc_find_node_by_ram_code()\n\nAs of_find_node_by_name() release the reference of the argument device\nnode, tegra_emc_find_node_by_ram_code() releases some device nodes while\nstill in use, resulting in possible UAFs. According to the bindings and\nthe in-tree DTS files, the \u0026quot;emc-tables\u0026quot; node is always device\u0026apos;s child\nnode with the property \u0026quot;nvidia,use-ram-code\u0026quot;, and the \u0026quot;lpddr2\u0026quot; node is a\nchild of the \u0026quot;emc-tables\u0026quot; node. Thus utilize the\nfor_each_child_of_node() macro and of_get_child_by_name() instead of\nof_find_node_by_name() to simplify the code.\n\nThis bug was found by an experimental verification tool that I am\ndeveloping.\n\n[krzysztof: applied v1, adjust the commit msg to incorporate v2 parts](CVE-2024-58034)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: limit printed string from FW file\n\nThere\u0026apos;s no guarantee here that the file is always with a\nNUL-termination, so reading the string may read beyond the\nend of the TLV. If that\u0026apos;s the last TLV in the file, it can\nperhaps even read beyond the end of the file buffer.\n\nFix that by limiting the print format to the size of the\nbuffer we have.(CVE-2025-21905)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmemstick: rtsx_usb_ms: Fix slab-use-after-free in rtsx_usb_ms_drv_remove\n\nThis fixes the following crash:\n\n==================================================================\nBUG: KASAN: slab-use-after-free in rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\nRead of size 8 at addr ffff888136335380 by task kworker/6:0/140241\n\nCPU: 6 UID: 0 PID: 140241 Comm: kworker/6:0 Kdump: loaded Tainted: G E 6.14.0-rc6+ #1\nTainted: [E]=UNSIGNED_MODULE\nHardware name: LENOVO 30FNA1V7CW/1057, BIOS S0EKT54A 07/01/2024\nWorkqueue: events rtsx_usb_ms_poll_card [rtsx_usb_ms]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x51/0x70\n print_address_description.constprop.0+0x27/0x320\n ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\n print_report+0x3e/0x70\n kasan_report+0xab/0xe0\n ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\n rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\n ? __pfx_rtsx_usb_ms_poll_card+0x10/0x10 [rtsx_usb_ms]\n ? __pfx___schedule+0x10/0x10\n ? kick_pool+0x3b/0x270\n process_one_work+0x357/0x660\n worker_thread+0x390/0x4c0\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x190/0x1d0\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x2d/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 161446:\n kasan_save_stack+0x20/0x40\n kasan_save_track+0x10/0x30\n __kasan_kmalloc+0x7b/0x90\n __kmalloc_noprof+0x1a7/0x470\n memstick_alloc_host+0x1f/0xe0 [memstick]\n rtsx_usb_ms_drv_probe+0x47/0x320 [rtsx_usb_ms]\n platform_probe+0x60/0xe0\n call_driver_probe+0x35/0x120\n really_probe+0x123/0x410\n __driver_probe_device+0xc7/0x1e0\n driver_probe_device+0x49/0xf0\n __device_attach_driver+0xc6/0x160\n bus_for_each_drv+0xe4/0x160\n __device_attach+0x13a/0x2b0\n bus_probe_device+0xbd/0xd0\n device_add+0x4a5/0x760\n platform_device_add+0x189/0x370\n mfd_add_device+0x587/0x5e0\n mfd_add_devices+0xb1/0x130\n rtsx_usb_probe+0x28e/0x2e0 [rtsx_usb]\n usb_probe_interface+0x15c/0x460\n call_driver_probe+0x35/0x120\n really_probe+0x123/0x410\n __driver_probe_device+0xc7/0x1e0\n driver_probe_device+0x49/0xf0\n __device_attach_driver+0xc6/0x160\n bus_for_each_drv+0xe4/0x160\n __device_attach+0x13a/0x2b0\n rebind_marked_interfaces.isra.0+0xcc/0x110\n usb_reset_device+0x352/0x410\n usbdev_do_ioctl+0xe5c/0x1860\n usbdev_ioctl+0xa/0x20\n __x64_sys_ioctl+0xc5/0xf0\n do_syscall_64+0x59/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nFreed by task 161506:\n kasan_save_stack+0x20/0x40\n kasan_save_track+0x10/0x30\n kasan_save_free_info+0x36/0x60\n __kasan_slab_free+0x34/0x50\n kfree+0x1fd/0x3b0\n device_release+0x56/0xf0\n kobject_cleanup+0x73/0x1c0\n rtsx_usb_ms_drv_remove+0x13d/0x220 [rtsx_usb_ms]\n platform_remove+0x2f/0x50\n device_release_driver_internal+0x24b/0x2e0\n bus_remove_device+0x124/0x1d0\n device_del+0x239/0x530\n platform_device_del.part.0+0x19/0xe0\n platform_device_unregister+0x1c/0x40\n mfd_remove_devices_fn+0x167/0x170\n device_for_each_child_reverse+0xc9/0x130\n mfd_remove_devices+0x6e/0xa0\n rtsx_usb_disconnect+0x2e/0xd0 [rtsx_usb]\n usb_unbind_interface+0xf3/0x3f0\n device_release_driver_internal+0x24b/0x2e0\n proc_disconnect_claim+0x13d/0x220\n usbdev_do_ioctl+0xb5e/0x1860\n usbdev_ioctl+0xa/0x20\n __x64_sys_ioctl+0xc5/0xf0\n do_syscall_64+0x59/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nLast potentially related work creation:\n kasan_save_stack+0x20/0x40\n kasan_record_aux_stack+0x85/0x90\n insert_work+0x29/0x100\n __queue_work+0x34a/0x540\n call_timer_fn+0x2a/0x160\n expire_timers+0x5f/0x1f0\n __run_timer_base.part.0+0x1b6/0x1e0\n run_timer_softirq+0x8b/0xe0\n handle_softirqs+0xf9/0x360\n __irq_exit_rcu+0x114/0x130\n sysvec_apic_timer_interrupt+0x72/0x90\n asm_sysvec_apic_timer_interrupt+0x16/0x20\n\nSecond to last potentially related work creation:\n kasan_save_stack+0x20/0x40\n kasan_record_aux_stack+0x85/0x90\n insert_work+0x29/0x100\n __queue_work+0x34a/0x540\n call_timer_fn+0x2a/0x160\n expire_timers+0x5f/0x1f0\n __run_timer_base.part.0+0x1b6/0x1e0\n run_timer_softirq+0x8b/0xe0\n handle_softirqs+0xf9/0x\n---truncated---(CVE-2025-22020)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: xhci: Apply the link chain quirk on NEC isoc endpoints\n\nTwo clearly different specimens of NEC uPD720200 (one with start/stop\nbug, one without) were seen to cause IOMMU faults after some Missed\nService Errors. Faulting address is immediately after a transfer ring\nsegment and patched dynamic debug messages revealed that the MSE was\nreceived when waiting for a TD near the end of that segment:\n\n[ 1.041954] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0\n[ 1.042120] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09000 flags=0x0000]\n[ 1.042146] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09040 flags=0x0000]\n\nIt gets even funnier if the next page is a ring segment accessible to\nthe HC. Below, it reports MSE in segment at ff1e8000, plows through a\nzero-filled page at ff1e9000 and starts reporting events for TRBs in\npage at ff1ea000 every microframe, instead of jumping to seg ff1e6000.\n\n[ 7.041671] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0\n[ 7.041999] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0\n[ 7.042011] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint\n[ 7.042028] xhci_hcd: All TDs skipped for slot 1 ep 2. Clear skip flag.\n[ 7.042134] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint\n[ 7.042138] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31\n[ 7.042144] xhci_hcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820\n[ 7.042259] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint\n[ 7.042262] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31\n[ 7.042266] xhci_hcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820\n\nAt some point completion events change from Isoch Buffer Overrun to\nShort Packet and the HC finally finds cycle bit mismatch in ff1ec000.\n\n[ 7.098130] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13\n[ 7.098132] xhci_hcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820\n[ 7.098254] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13\n[ 7.098256] xhci_hcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820\n[ 7.098379] xhci_hcd: Overrun event on slot 1 ep 2\n\nIt\u0026apos;s possible that data from the isochronous device were written to\nrandom buffers of pending TDs on other endpoints (either IN or OUT),\nother devices or even other HCs in the same IOMMU domain.\n\nLastly, an error from a different USB device on another HC. Was it\ncaused by the above? I don\u0026apos;t know, but it may have been. The disk\nwas working without any other issues and generated PCIe traffic to\nstarve the NEC of upstream BW and trigger those MSEs. The two HCs\nshared one x1 slot by means of a commercial \u0026quot;PCIe splitter\u0026quot; board.\n\n[ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhci_hcd\n[ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s\n[ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00\n[ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0\n\nFortunately, it appears that this ridiculous bug is avoided by setting\nthe chain bit of Link TRBs on isochronous rings. Other ancient HCs are\nknown which also expect the bit to be set and they ignore Link TRBs if\nit\u0026apos;s not. Reportedly, 0.95 spec guaranteed that the bit is set.\n\nThe bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reports\ntens of MSEs per second and runs into the bug within seconds. Chaining\nLink TRBs allows the same workload to run for many minutes, many times.\n\nNo ne\n---truncated---(CVE-2025-22022)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix overflow in dacloffset bounds check\n\nThe dacloffset field was originally typed as int and used in an\nunchecked addition, which could overflow and bypass the existing\nbounds check in both smb_check_perm_dacl() and smb_inherit_dacl().\n\nThis could result in out-of-bounds memory access and a kernel crash\nwhen dereferencing the DACL pointer.\n\nThis patch converts dacloffset to unsigned int and uses\ncheck_add_overflow() to validate access to the DACL.(CVE-2025-22039)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpoint\n\nIf vhost_scsi_set_endpoint is called multiple times without a\nvhost_scsi_clear_endpoint between them, we can hit multiple bugs\nfound by Haoran Zhang:\n\n1. Use-after-free when no tpgs are found:\n\nThis fixes a use after free that occurs when vhost_scsi_set_endpoint is\ncalled more than once and calls after the first call do not find any\ntpgs to add to the vs_tpg. When vhost_scsi_set_endpoint first finds\ntpgs to add to the vs_tpg array match=true, so we will do:\n\nvhost_vq_set_backend(vq, vs_tpg);\n...\n\nkfree(vs-\u0026gt;vs_tpg);\nvs-\u0026gt;vs_tpg = vs_tpg;\n\nIf vhost_scsi_set_endpoint is called again and no tpgs are found\nmatch=false so we skip the vhost_vq_set_backend call leaving the\npointer to the vs_tpg we then free via:\n\nkfree(vs-\u0026gt;vs_tpg);\nvs-\u0026gt;vs_tpg = vs_tpg;\n\nIf a scsi request is then sent we do:\n\nvhost_scsi_handle_vq -\u0026gt; vhost_scsi_get_req -\u0026gt; vhost_vq_get_backend\n\nwhich sees the vs_tpg we just did a kfree on.\n\n2. Tpg dir removal hang:\n\nThis patch fixes an issue where we cannot remove a LIO/target layer\ntpg (and structs above it like the target) dir due to the refcount\ndropping to -1.\n\nThe problem is that if vhost_scsi_set_endpoint detects a tpg is already\nin the vs-\u0026gt;vs_tpg array or if the tpg has been removed so\ntarget_depend_item fails, the undepend goto handler will do\ntarget_undepend_item on all tpgs in the vs_tpg array dropping their\nrefcount to 0. At this time vs_tpg contains both the tpgs we have added\nin the current vhost_scsi_set_endpoint call as well as tpgs we added in\nprevious calls which are also in vs-\u0026gt;vs_tpg.\n\nLater, when vhost_scsi_clear_endpoint runs it will do\ntarget_undepend_item on all the tpgs in the vs-\u0026gt;vs_tpg which will drop\ntheir refcount to -1. Userspace will then not be able to remove the tpg\nand will hang when it tries to do rmdir on the tpg dir.\n\n3. Tpg leak:\n\nThis fixes a bug where we can leak tpgs and cause them to be\nun-removable because the target name is overwritten when\nvhost_scsi_set_endpoint is called multiple times but with different\ntarget names.\n\nThe bug occurs if a user has called VHOST_SCSI_SET_ENDPOINT and setup\na vhost-scsi device to target/tpg mapping, then calls\nVHOST_SCSI_SET_ENDPOINT again with a new target name that has tpgs we\nhaven\u0026apos;t seen before (target1 has tpg1 but target2 has tpg2). When this\nhappens we don\u0026apos;t teardown the old target tpg mapping and just overwrite\nthe target name and the vs-\u0026gt;vs_tpg array. Later when we do\nvhost_scsi_clear_endpoint, we are passed in either target1 or target2\u0026apos;s\nname and we will only match that target\u0026apos;s tpgs when we loop over the\nvs-\u0026gt;vs_tpg. We will then return from the function without doing\ntarget_undepend_item on the tpgs.\n\nBecause of all these bugs, it looks like being able to call\nvhost_scsi_set_endpoint multiple times was never supported. The major\nuser, QEMU, already has checks to prevent this use case. So to fix the\nissues, this patch prevents vhost_scsi_set_endpoint from being called\nif it\u0026apos;s already successfully added tpgs. To add, remove or change the\ntpg config or target name, you must do a vhost_scsi_clear_endpoint\nfirst.(CVE-2025-22083)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix off-by-one error in do_split\n\nSyzkaller detected a use-after-free issue in ext4_insert_dentry that was\ncaused by out-of-bounds access due to incorrect splitting in do_split.\n\nBUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109\nWrite of size 251 at addr ffff888074572f14 by task syz-executor335/5847\n\nCPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:488\n kasan_report+0x143/0x180 mm/kasan/report.c:601\n kasan_check_range+0x282/0x290 mm/kasan/generic.c:189\n __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106\n ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109\n add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154\n make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351\n ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455\n ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796\n ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431\n vfs_symlink+0x137/0x2e0 fs/namei.c:4615\n do_symlinkat+0x222/0x3a0 fs/namei.c:4641\n __do_sys_symlink fs/namei.c:4662 [inline]\n __se_sys_symlink fs/namei.c:4660 [inline]\n __x64_sys_symlink+0x7a/0x90 fs/namei.c:4660\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n \u0026lt;/TASK\u0026gt;\n\nThe following loop is located right above \u0026apos;if\u0026apos; statement.\n\nfor (i = count-1; i \u0026gt;= 0; i--) {\n\t/* is more than half of this entry in 2nd half of the block? */\n\tif (size + map[i].size/2 \u0026gt; blocksize/2)\n\t\tbreak;\n\tsize += map[i].size;\n\tmove++;\n}\n\n\u0026apos;i\u0026apos; in this case could go down to -1, in which case sum of active entries\nwouldn\u0026apos;t exceed half the block size, but previous behaviour would also do\nsplit in half if sum would exceed at the very last block, which in case of\nhaving too many long name files in a single block could lead to\nout-of-bounds access and following use-after-free.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-23150)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: venus: hfi: add check to handle incorrect queue size\n\nqsize represents size of shared queued between driver and video\nfirmware. Firmware can modify this value to an invalid large value. In\nsuch situation, empty_space will be bigger than the space actually\navailable. Since new_wr_idx is not checked, so the following code will\nresult in an OOB write.\n...\nqsize = qhdr-\u0026gt;q_size\n\nif (wr_idx \u0026gt;= rd_idx)\n empty_space = qsize - (wr_idx - rd_idx)\n....\nif (new_wr_idx \u0026lt; qsize) {\n memcpy(wr_ptr, packet, dwords \u0026lt;\u0026lt; 2) --\u0026gt; OOB write\n\nAdd check to ensure qsize is within the allocated size while\nreading and writing packets into the queue.(CVE-2025-23158)\n\nIn the Linux kernel, the following vulnerability has been resolved:net: ppp: Add bound checking for skb data on ppp_sync_txmungEnsure we have enough data in linear buffer from skb before accessinginitial bytes. This prevents potential out-of-bounds accesseswhen processing short packets.When ppp_sync_txmung receives an incoming package with an emptypayload:(remote) gef\u27a4 p *(struct pppoe_hdr *) (skb-\u0026gt;head + skb-\u0026gt;network_header)$18 = { type = 0x1, ver = 0x1, code = 0x0, sid = 0x2, length = 0x0, tag = 0xffff8880371cdb96}from the skb struct (trimmed) tail = 0x16, end = 0x140, head = 0xffff88803346f400 4 , data = 0xffff88803346f416 : 377 , truesize = 0x380, len = 0x0, data_len = 0x0, mac_len = 0xe, hdr_len = 0x0,it is not safe to access data[2].[(CVE-2025-37749)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix OOB read when checking dotdot dir\n\nMounting a corrupted filesystem with directory which contains \u0026apos;.\u0026apos; dir\nentry with rec_len == block size results in out-of-bounds read (later\non, when the corrupted directory is removed).\n\next4_empty_dir() assumes every ext4 directory contains at least \u0026apos;.\u0026apos;\nand \u0026apos;..\u0026apos; as directory entries in the first data block. It first loads\nthe \u0026apos;.\u0026apos; dir entry, performs sanity checks by calling ext4_check_dir_entry()\nand then uses its rec_len member to compute the location of \u0026apos;..\u0026apos; dir\nentry (in ext4_next_entry). It assumes the \u0026apos;..\u0026apos; dir entry fits into the\nsame data block.\n\nIf the rec_len of \u0026apos;.\u0026apos; is precisely one block (4KB), it slips through the\nsanity checks (it is considered the last directory entry in the data\nblock) and leaves \u0026quot;struct ext4_dir_entry_2 *de\u0026quot; point exactly past the\nmemory slot allocated to the data block. The following call to\next4_check_dir_entry() on new value of de then dereferences this pointer\nwhich results in out-of-bounds mem access.\n\nFix this by extending __ext4_check_dir_entry() to check for \u0026apos;.\u0026apos; dir\nentries that reach the end of data block. Make sure to ignore the phony\ndir entries for checksum (by checking name_len for non-zero).\n\nNote: This is reported by KASAN as use-after-free in case another\nstructure was recently freed from the slot past the bound, but it is\nreally an OOB read.\n\nThis issue was found by syzkaller tool.\n\nCall Trace:\n[ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710\n[ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375\n[ 38.595158]\n[ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1\n[ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n[ 38.595304] Call Trace:\n[ 38.595308] \u0026lt;TASK\u0026gt;\n[ 38.595311] dump_stack_lvl+0xa7/0xd0\n[ 38.595325] print_address_description.constprop.0+0x2c/0x3f0\n[ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595349] print_report+0xaa/0x250\n[ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595368] ? kasan_addr_to_slab+0x9/0x90\n[ 38.595378] kasan_report+0xab/0xe0\n[ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595400] __ext4_check_dir_entry+0x67e/0x710\n[ 38.595410] ext4_empty_dir+0x465/0x990\n[ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10\n[ 38.595432] ext4_rmdir.part.0+0x29a/0xd10\n[ 38.595441] ? __dquot_initialize+0x2a7/0xbf0\n[ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10\n[ 38.595464] ? __pfx___dquot_initialize+0x10/0x10\n[ 38.595478] ? down_write+0xdb/0x140\n[ 38.595487] ? __pfx_down_write+0x10/0x10\n[ 38.595497] ext4_rmdir+0xee/0x140\n[ 38.595506] vfs_rmdir+0x209/0x670\n[ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190\n[ 38.595529] do_rmdir+0x363/0x3c0\n[ 38.595537] ? __pfx_do_rmdir+0x10/0x10\n[ 38.595544] ? strncpy_from_user+0x1ff/0x2e0\n[ 38.595561] __x64_sys_unlinkat+0xf0/0x130\n[ 38.595570] do_syscall_64+0x5b/0x180\n[ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-37785)\n\nIn the Linux kernel, the following vulnerability has been resolved:net: openvswitch: fix nested key length validation in the set() actionIt s not safe to access nla_len(ovs_key) if the data is smaller thanthe netlink header. Check that the attribute is OK first.(CVE-2025-37789)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid\n\nThere is a string parsing logic error which can lead to an overflow of hid\nor uid buffers. Comparing ACPIID_LEN against a total string length doesn\u0026apos;t\ntake into account the lengths of individual hid and uid buffers so the\ncheck is insufficient in some cases. For example if the length of hid\nstring is 4 and the length of the uid string is 260, the length of str\nwill be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer\nwhich size is 256.\n\nThe same applies to the hid string with length 13 and uid string with\nlength 250.\n\nCheck the length of hid and uid strings separately to prevent\nbuffer overflow.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37927)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAX\n\nOtherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof()\nwhen resizing hashtable because __GFP_NOWARN is unset.\n\nSimilar to:\n\n b541ba7d1f5a (\u0026quot;netfilter: conntrack: clamp maximum hashtable size to INT_MAX\u0026quot;)(CVE-2025-38201)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix WARN() in get_bpf_raw_tp_regs\n\nsyzkaller reported an issue:\n\nWARNING: CPU: 3 PID: 5971 at kernel/trace/bpf_trace.c:1861 get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861\nModules linked in:\nCPU: 3 UID: 0 PID: 5971 Comm: syz-executor205 Not tainted 6.15.0-rc5-syzkaller-00038-g707df3375124 #0 PREEMPT(full)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nRIP: 0010:get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861\nRSP: 0018:ffffc90003636fa8 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: 0000000000000003 RCX: ffffffff81c6bc4c\nRDX: ffff888032efc880 RSI: ffffffff81c6bc83 RDI: 0000000000000005\nRBP: ffff88806a730860 R08: 0000000000000005 R09: 0000000000000003\nR10: 0000000000000004 R11: 0000000000000000 R12: 0000000000000004\nR13: 0000000000000001 R14: ffffc90003637008 R15: 0000000000000900\nFS: 0000000000000000(0000) GS:ffff8880d6cdf000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f7baee09130 CR3: 0000000029f5a000 CR4: 0000000000352ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1934 [inline]\n bpf_get_stack_raw_tp+0x24/0x160 kernel/trace/bpf_trace.c:1931\n bpf_prog_ec3b2eefa702d8d3+0x43/0x47\n bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline]\n __bpf_prog_run include/linux/filter.h:718 [inline]\n bpf_prog_run include/linux/filter.h:725 [inline]\n __bpf_trace_run kernel/trace/bpf_trace.c:2363 [inline]\n bpf_trace_run3+0x23f/0x5a0 kernel/trace/bpf_trace.c:2405\n __bpf_trace_mmap_lock_acquire_returned+0xfc/0x140 include/trace/events/mmap_lock.h:47\n __traceiter_mmap_lock_acquire_returned+0x79/0xc0 include/trace/events/mmap_lock.h:47\n __do_trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline]\n trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline]\n __mmap_lock_do_trace_acquire_returned+0x138/0x1f0 mm/mmap_lock.c:35\n __mmap_lock_trace_acquire_returned include/linux/mmap_lock.h:36 [inline]\n mmap_read_trylock include/linux/mmap_lock.h:204 [inline]\n stack_map_get_build_id_offset+0x535/0x6f0 kernel/bpf/stackmap.c:157\n __bpf_get_stack+0x307/0xa10 kernel/bpf/stackmap.c:483\n ____bpf_get_stack kernel/bpf/stackmap.c:499 [inline]\n bpf_get_stack+0x32/0x40 kernel/bpf/stackmap.c:496\n ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1941 [inline]\n bpf_get_stack_raw_tp+0x124/0x160 kernel/trace/bpf_trace.c:1931\n bpf_prog_ec3b2eefa702d8d3+0x43/0x47\n\nTracepoint like trace_mmap_lock_acquire_returned may cause nested call\nas the corner case show above, which will be resolved with more general\nmethod in the future. As a result, WARN_ON_ONCE will be triggered. As\nAlexei suggested, remove the WARN_ON_ONCE first.(CVE-2025-38285)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: Always pass notifications when child class becomes empty\n\nCertain classful qdiscs may invoke their classes\u0026apos; dequeue handler on an\nenqueue operation. This may unexpectedly empty the child qdisc and thus\nmake an in-flight class passive via qlen_notify(). Most qdiscs do not\nexpect such behaviour at this point in time and may re-activate the\nclass eventually anyways which will lead to a use-after-free.\n\nThe referenced fix commit attempted to fix this behavior for the HFSC\ncase by moving the backlog accounting around, though this turned out to\nbe incomplete since the parent\u0026apos;s parent may run into the issue too.\nThe following reproducer demonstrates this use-after-free:\n\n tc qdisc add dev lo root handle 1: drr\n tc filter add dev lo parent 1: basic classid 1:1\n tc class add dev lo parent 1: classid 1:1 drr\n tc qdisc add dev lo parent 1:1 handle 2: hfsc def 1\n tc class add dev lo parent 2: classid 2:1 hfsc rt m1 8 d 1 m2 0\n tc qdisc add dev lo parent 2:1 handle 3: netem\n tc qdisc add dev lo parent 3:1 handle 4: blackhole\n\n echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888\n tc class delete dev lo classid 1:1\n echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888\n\nSince backlog accounting issues leading to a use-after-frees on stale\nclass pointers is a recurring pattern at this point, this patch takes\na different approach. Instead of trying to fix the accounting, the patch\nensures that qdisc_tree_reduce_backlog always calls qlen_notify when\nthe child qdisc is empty. This solves the problem because deletion of\nqdiscs always involves a call to qdisc_reset() and / or\nqdisc_purge_queue() which ultimately resets its qlen to 0 thus causing\nthe following qdisc_tree_reduce_backlog() to report to the parent. Note\nthat this may call qlen_notify on passive classes multiple times. This\nis not a problem after the recent patch series that made all the\nclassful qdiscs qlen_notify() handlers idempotent.(CVE-2025-38350)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix use-after-free in cifs_oplock_break\n\nA race condition can occur in cifs_oplock_break() leading to a\nuse-after-free of the cinode structure when unmounting:\n\n cifs_oplock_break()\n _cifsFileInfo_put(cfile)\n cifsFileInfo_put_final()\n cifs_sb_deactive()\n [last ref, start releasing sb]\n kill_sb()\n kill_anon_super()\n generic_shutdown_super()\n evict_inodes()\n dispose_list()\n evict()\n destroy_inode()\n call_rcu(\u0026amp;inode-\u0026gt;i_rcu, i_callback)\n spin_lock(\u0026amp;cinode-\u0026gt;open_file_lock) \u0026lt;- OK\n [later] i_callback()\n cifs_free_inode()\n kmem_cache_free(cinode)\n spin_unlock(\u0026amp;cinode-\u0026gt;open_file_lock) \u0026lt;- UAF\n cifs_done_oplock_break(cinode) \u0026lt;- UAF\n\nThe issue occurs when umount has already released its reference to the\nsuperblock. When _cifsFileInfo_put() calls cifs_sb_deactive(), this\nreleases the last reference, triggering the immediate cleanup of all\ninodes under RCU. However, cifs_oplock_break() continues to access the\ncinode after this point, resulting in use-after-free.\n\nFix this by holding an extra reference to the superblock during the\nentire oplock break operation. This ensures that the superblock and\nits inodes remain valid until the oplock break completes.(CVE-2025-38527)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/packet: fix a race in packet_set_ring() and packet_notifier()\n\nWhen packet_set_ring() releases po-\u0026gt;bind_lock, another thread can\nrun packet_notifier() and process an NETDEV_UP event.\n\nThis race and the fix are both similar to that of commit 15fe076edea7\n(\u0026quot;net/packet: fix a race in packet_bind() and packet_notifier()\u0026quot;).\n\nThere too the packet_notifier NETDEV_UP event managed to run while a\npo-\u0026gt;bind_lock critical section had to be temporarily released. And\nthe fix was similarly to temporarily set po-\u0026gt;num to zero to keep\nthe socket unhooked until the lock is retaken.\n\nThe po-\u0026gt;bind_lock in packet_set_ring and packet_notifier precede the\nintroduction of git history.(CVE-2025-38617)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nice: Fix a null pointer dereference in ice_copy_and_init_pkg()\n\nAdd check for the return value of devm_kmemdup()\nto prevent potential null pointer dereference.(CVE-2025-38664)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: core: Check for rtd == NULL in snd_soc_remove_pcm_runtime()\n\nsnd_soc_remove_pcm_runtime() might be called with rtd == NULL which will\nleads to null pointer dereference.\nThis was reproduced with topology loading and marking a link as ignore\ndue to missing hardware component on the system.\nOn module removal the soc_tplg_remove_link() would call\nsnd_soc_remove_pcm_runtime() with rtd == NULL since the link was ignored,\nno runtime was created.(CVE-2025-38706)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: Validate UAC3 power domain descriptors, too\n\nUAC3 power domain descriptors need to be verified with its variable\nbLength for avoiding the unexpected OOB accesses by malicious\nfirmware, too.(CVE-2025-38729)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix NPD when refreshing an FDB entry with a nexthop object\n\nVXLAN FDB entries can point to either a remote destination or an FDB\nnexthop group. The latter is usually used in EVPN deployments where\nlearning is disabled.\n\nHowever, when learning is enabled, an incoming packet might try to\nrefresh an FDB entry that points to an FDB nexthop group and therefore\ndoes not have a remote. Such packets should be dropped, but they are\nonly dropped after dereferencing the non-existent remote, resulting in a\nNPD [1] which can be reproduced using [2].\n\nFix by dropping such packets earlier. Remove the misleading comment from\nfirst_remote_rcu().\n\n[1]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n[...]\nCPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014\nRIP: 0010:vxlan_snoop+0x98/0x1e0\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n vxlan_encap_bypass+0x209/0x240\n encap_bypass_if_local+0xb1/0x100\n vxlan_xmit_one+0x1375/0x17e0\n vxlan_xmit+0x6b4/0x15f0\n dev_hard_start_xmit+0x5d/0x1c0\n __dev_queue_xmit+0x246/0xfd0\n packet_sendmsg+0x113a/0x1850\n __sock_sendmsg+0x38/0x70\n __sys_sendto+0x126/0x180\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n[2]\n #!/bin/bash\n\n ip address add 192.0.2.1/32 dev lo\n ip address add 192.0.2.2/32 dev lo\n\n ip nexthop add id 1 via 192.0.2.3 fdb\n ip nexthop add id 10 group 1 fdb\n\n ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass\n ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning\n\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020\n bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10\n\n mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q(CVE-2025-39851)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: arm64: Prevent access to vCPU events before init\n\nAnother day, another syzkaller bug. KVM erroneously allows userspace to\npend vCPU events for a vCPU that hasn\u0026apos;t been initialized yet, leading to\nKVM interpreting a bunch of uninitialized garbage for routing /\ninjecting the exception.\n\nIn one case the injection code and the hyp disagree on whether the vCPU\nhas a 32bit EL1 and put the vCPU into an illegal mode for AArch64,\ntripping the BUG() in exception_target_el() during the next injection:\n\n kernel BUG at arch/arm64/kvm/inject_fault.c:40!\n Internal error: Oops - BUG: 00000000f2000800 [#1] SMP\n CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT\n Hardware name: linux,dummy-virt (DT)\n pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n pc : exception_target_el+0x88/0x8c\n lr : pend_serror_exception+0x18/0x13c\n sp : ffff800082f03a10\n x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000\n x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000\n x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004\n x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000\n x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0\n x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000\n x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000\n x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000\n x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000\n x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20\n Call trace:\n exception_target_el+0x88/0x8c (P)\n kvm_inject_serror_esr+0x40/0x3b4\n __kvm_arm_vcpu_set_events+0xf0/0x100\n kvm_arch_vcpu_ioctl+0x180/0x9d4\n kvm_vcpu_ioctl+0x60c/0x9f4\n __arm64_sys_ioctl+0xac/0x104\n invoke_syscall+0x48/0x110\n el0_svc_common.constprop.0+0x40/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x34/0xf0\n el0t_64_sync_handler+0xa0/0xe4\n el0t_64_sync+0x198/0x19c\n Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000)\n\nReject the ioctls outright as no sane VMM would call these before\nKVM_ARM_VCPU_INIT anyway. Even if it did the exception would\u0026apos;ve been\nthrown away by the eventual reset of the vCPU\u0026apos;s state.(CVE-2025-40102)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmc: Use __sk_dst_get() and dst_dev_rcu() in in smc_clc_prfx_set().\n\nsmc_clc_prfx_set() is called during connect() and not under RCU\nnor RTNL.\n\nUsing sk_dst_get(sk)-\u0026gt;dev could trigger UAF.\n\nLet\u0026apos;s use __sk_dst_get() and dev_dst_rcu() under rcu_read_lock()\nafter kernel_getsockname().\n\nNote that the returned value of smc_clc_prfx_set() is not used\nin the caller.\n\nWhile at it, we change the 1st arg of smc_clc_prfx_set[46]_rcu()\nnot to touch dst there.(CVE-2025-40139)",
"id": "OESA-2025-2800",
"modified": "2026-08-06T11:09:55Z",
"published": "2025-12-12T11:09:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2800"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53091"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53192"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53282"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53491"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53520"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53673"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38662"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42102"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49875"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57907"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57911"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58034"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21905"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22020"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22022"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22039"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22083"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23150"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23158"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37749"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37785"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37789"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37927"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38201"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38285"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38350"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38527"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38617"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38664"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38706"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38729"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39851"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40102"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40139"
}
],
"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-2023-53091",
"CVE-2023-53192",
"CVE-2023-53282",
"CVE-2023-53491",
"CVE-2023-53520",
"CVE-2023-53673",
"CVE-2024-38662",
"CVE-2024-42102",
"CVE-2024-49875",
"CVE-2024-57907",
"CVE-2024-57911",
"CVE-2024-58034",
"CVE-2025-21905",
"CVE-2025-22020",
"CVE-2025-22022",
"CVE-2025-22039",
"CVE-2025-22083",
"CVE-2025-23150",
"CVE-2025-23158",
"CVE-2025-37749",
"CVE-2025-37785",
"CVE-2025-37789",
"CVE-2025-37927",
"CVE-2025-38201",
"CVE-2025-38285",
"CVE-2025-38350",
"CVE-2025-38527",
"CVE-2025-38617",
"CVE-2025-38664",
"CVE-2025-38706",
"CVE-2025-38729",
"CVE-2025-39851",
"CVE-2025-40102",
"CVE-2025-40139"
]
}
OESA-2025-2801 (CVE-2023-53091)
Vulnerability from osv_openeuler – Published: 2025-12-12 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:
ext4: update s_journal_inum if it changes after journal replay
When mounting a crafted ext4 image, s_journal_inum may change after journal replay, which is obviously unreasonable because we have successfully loaded and replayed the journal through the old s_journal_inum. And the new s_journal_inum bypasses some of the checks in ext4_get_journal(), which may trigger a null pointer dereference problem. So if s_journal_inum changes after the journal replay, we ignore the change, and rewrite the current journal_inum to the superblock.(CVE-2023-53091)
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix use-after-free KFENCE violation during sysfs firmware write
During the sysfs firmware write process, a use-after-free read warning is logged from the lpfc_wr_object() routine:
BUG: KFENCE: use-after-free read in lpfc_wr_object+0x235/0x310 [lpfc] Use-after-free read at 0x0000000000cf164d (in kfence-#111): lpfc_wr_object+0x235/0x310 [lpfc] lpfc_write_firmware.cold+0x206/0x30d [lpfc] lpfc_sli4_request_firmware_update+0xa6/0x100 [lpfc] lpfc_request_firmware_upgrade_store+0x66/0xb0 [lpfc] kernfs_fop_write_iter+0x121/0x1b0 new_sync_write+0x11c/0x1b0 vfs_write+0x1ef/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x59/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd
The driver accessed wr_object pointer data, which was initialized into mailbox payload memory, after the mailbox object was released back to the mailbox pool.
Fix by moving the mailbox free calls to the end of the routine ensuring that we don't reference internal mailbox memory after release.(CVE-2023-53282)
In the Linux kernel, the following vulnerability has been resolved:
start_kernel: Add __no_stack_protector function attribute
Back during the discussion of commit a9a3ed1eff36 ("x86: Fix early boot crash on gcc-10, third try") we discussed the need for a function attribute to control the omission of stack protectors on a per-function basis; at the time Clang had support for no_stack_protector but GCC did not. This was fixed in gcc-11. Now that the function attribute is available, let's start using it.
Callers of boot_init_stack_canary need to use this function attribute unless they're compiled with -fno-stack-protector, otherwise the canary stored in the stack slot of the caller will differ upon the call to boot_init_stack_canary. This will lead to a call to __stack_chk_fail() then panic.(CVE-2023-53491)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix hci_suspend_sync crash
If hci_unregister_dev() frees the hci_dev object but hci_suspend_notifier may still be accessing it, it can cause the program to crash. Here's the call trace: <4>[102152.653246] Call Trace: <4>[102152.653254] hci_suspend_sync+0x109/0x301 [bluetooth] <4>[102152.653259] hci_suspend_dev+0x78/0xcd [bluetooth] <4>[102152.653263] hci_suspend_notifier+0x42/0x7a [bluetooth] <4>[102152.653268] notifier_call_chain+0x43/0x6b <4>[102152.653271] __blocking_notifier_call_chain+0x48/0x69 <4>[102152.653273] __pm_notifier_call_chain+0x22/0x39 <4>[102152.653276] pm_suspend+0x287/0x57c <4>[102152.653278] state_store+0xae/0xe5 <4>[102152.653281] kernfs_fop_write+0x109/0x173 <4>[102152.653284] __vfs_write+0x16f/0x1a2 <4>[102152.653287] ? selinux_file_permission+0xca/0x16f <4>[102152.653289] ? security_file_permission+0x36/0x109 <4>[102152.653291] vfs_write+0x114/0x21d <4>[102152.653293] __x64_sys_write+0x7b/0xdb <4>[102152.653296] do_syscall_64+0x59/0x194 <4>[102152.653299] entry_SYSCALL_64_after_hwframe+0x5c/0xc1
This patch holds the reference count of the hci_dev object while processing it in hci_suspend_notifier to avoid potential crash caused by the race condition.(CVE-2023-53520)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_event: call disconnect callback before deleting conn
In hci_cs_disconnect, we do hci_conn_del even if disconnection failed.
ISO, L2CAP and SCO connections refer to the hci_conn without hci_conn_get, so disconn_cfm must be called so they can clean up their conn, otherwise use-after-free occurs.
ISO:
iso_sock_connect:880: sk 00000000eabd6557 iso_connect_cis:356: 70:1a:b8:98:ff:a2 -> 28:3d:c2:4a:7e:da ... iso_conn_add:140: hcon 000000001696f1fd conn 00000000b6251073 hci_dev_put:1487: hci0 orig refcnt 17 __iso_chan_add:214: conn 00000000b6251073 iso_sock_clear_timer:117: sock 00000000eabd6557 state 3 ... hci_rx_work:4085: hci0 Event packet hci_event_packet:7601: hci0: event 0x0f hci_cmd_status_evt:4346: hci0: opcode 0x0406 hci_cs_disconnect:2760: hci0: status 0x0c hci_sent_cmd_data:3107: hci0 opcode 0x0406 hci_conn_del:1151: hci0 hcon 000000001696f1fd handle 2560 hci_conn_unlink:1102: hci0: hcon 000000001696f1fd hci_conn_drop:1451: hcon 00000000d8521aaf orig refcnt 2 hci_chan_list_flush:2780: hcon 000000001696f1fd hci_dev_put:1487: hci0 orig refcnt 21 hci_dev_put:1487: hci0 orig refcnt 20 hci_req_cmd_complete:3978: opcode 0x0406 status 0x0c ... <no iso_* activity on sk/conn> ... iso_sock_sendmsg:1098: sock 00000000dea5e2e0, sk 00000000eabd6557 BUG: kernel NULL pointer dereference, address: 0000000000000668 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014 RIP: 0010:iso_sock_sendmsg (net/bluetooth/iso.c:1112) bluetooth ==========================================================
L2CAP:
hci_cmd_status_evt:4359: hci0: opcode 0x0406 hci_cs_disconnect:2760: hci0: status 0x0c hci_sent_cmd_data:3085: hci0 opcode 0x0406 hci_conn_del:1151: hci0 hcon ffff88800c999000 handle 3585 hci_conn_unlink:1102: hci0: hcon ffff88800c999000 hci_chan_list_flush:2780: hcon ffff88800c999000 hci_chan_del:2761: hci0 hcon ffff88800c999000 chan ffff888018ddd280 ... BUG: KASAN: slab-use-after-free in hci_send_acl+0x2d/0x540 [bluetooth] Read of size 8 at addr ffff888018ddd298 by task bluetoothd/1175
CPU: 0 PID: 1175 Comm: bluetoothd Tainted: G E 6.4.0-rc4+ #2 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x5b/0x90 print_report+0xcf/0x670 ? __virt_addr_valid+0xf8/0x180 ? hci_send_acl+0x2d/0x540 [bluetooth] kasan_report+0xa8/0xe0 ? hci_send_acl+0x2d/0x540 [bluetooth] hci_send_acl+0x2d/0x540 [bluetooth] ? __pfxlockacquire+0x10/0x10 l2cap_chan_send+0x1fd/0x1300 [bluetooth] ? l2cap_sock_sendmsg+0xf2/0x170 [bluetooth] ? pfx_l2cap_chan_send+0x10/0x10 [bluetooth] ? lock_release+0x1d5/0x3c0 ? mark_held_locks+0x1a/0x90 l2cap_sock_sendmsg+0x100/0x170 [bluetooth] sock_write_iter+0x275/0x280 ? __pfx_sock_write_iter+0x10/0x10 ? __pfxlockacquire+0x10/0x10 do_iter_readv_writev+0x176/0x220 ? pfx_do_iter_readv_writev+0x10/0x10 ? find_held_lock+0x83/0xa0 ? selinux_file_permission+0x13e/0x210 do_iter_write+0xda/0x340 vfs_writev+0x1b4/0x400 ? __pfx_vfs_writev+0x10/0x10 ? __seccomp_filter+0x112/0x750 ? populate_seccomp_data+0x182/0x220 ? __fget_light+0xdf/0x100 ? do_writev+0x19d/0x210 do_writev+0x19d/0x210 ? __pfx_do_writev+0x10/0x10 ? mark_held_locks+0x1a/0x90 do_syscall_64+0x60/0x90 ? lockdep_hardirqs_on_prepare+0x149/0x210 ? do_syscall_64+0x6c/0x90 ? lockdep_hardirqs_on_prepare+0x149/0x210 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7ff45cb23e64 Code: 15 d1 1f 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d 9d a7 0d 00 00 74 13 b8 14 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89 RSP: 002b:00007fff21ae09b8 EFLAGS: 00000202 ORIG_RAX: 0000000000000014 RAX: ffffffffffffffda RBX: ---truncated---(CVE-2023-53673)
In the Linux kernel, the following vulnerability has been resolved:
iio: adc: rockchip_saradc: fix information leak in triggered buffer
The 'data' local struct is used to push data to user space from a triggered buffer, but it does not set values for inactive channels, as it only uses iio_for_each_active_channel() to assign new values.
Initialize the struct to zero before using it to avoid pushing uninitialized information to userspace.(CVE-2024-57907)
In the Linux kernel, the following vulnerability has been resolved:
iio: dummy: iio_simply_dummy_buffer: fix information leak in triggered buffer
The 'data' array is allocated via kmalloc() and it is used to push data to user space from a triggered buffer, but it does not set values for inactive channels, as it only uses iio_for_each_active_channel() to assign new values.
Use kzalloc for the memory allocation to avoid pushing uninitialized information to userspace.(CVE-2024-57911)
In the Linux kernel, the following vulnerability has been resolved:
memory: tegra20-emc: fix an OF node reference bug in tegra_emc_find_node_by_ram_code()
As of_find_node_by_name() release the reference of the argument device node, tegra_emc_find_node_by_ram_code() releases some device nodes while still in use, resulting in possible UAFs. According to the bindings and the in-tree DTS files, the "emc-tables" node is always device's child node with the property "nvidia,use-ram-code", and the "lpddr2" node is a child of the "emc-tables" node. Thus utilize the for_each_child_of_node() macro and of_get_child_by_name() instead of of_find_node_by_name() to simplify the code.
This bug was found by an experimental verification tool that I am developing.
krzysztof: applied v1, adjust the commit msg to incorporate v2 parts
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: limit printed string from FW file
There's no guarantee here that the file is always with a NUL-termination, so reading the string may read beyond the end of the TLV. If that's the last TLV in the file, it can perhaps even read beyond the end of the file buffer.
Fix that by limiting the print format to the size of the buffer we have.(CVE-2025-21905)
In the Linux kernel, the following vulnerability has been resolved:
memstick: rtsx_usb_ms: Fix slab-use-after-free in rtsx_usb_ms_drv_remove
This fixes the following crash:
================================================================== BUG: KASAN: slab-use-after-free in rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] Read of size 8 at addr ffff888136335380 by task kworker/6:0/140241
CPU: 6 UID: 0 PID: 140241 Comm: kworker/6:0 Kdump: loaded Tainted: G E 6.14.0-rc6+ #1 Tainted: [E]=UNSIGNED_MODULE Hardware name: LENOVO 30FNA1V7CW/1057, BIOS S0EKT54A 07/01/2024 Workqueue: events rtsx_usb_ms_poll_card [rtsx_usb_ms] Call Trace: <TASK> dump_stack_lvl+0x51/0x70 print_address_description.constprop.0+0x27/0x320 ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] print_report+0x3e/0x70 kasan_report+0xab/0xe0 ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] ? __pfx_rtsx_usb_ms_poll_card+0x10/0x10 [rtsx_usb_ms] ? __pfxschedule+0x10/0x10 ? kickpool+0x3b/0x270 process_one_work+0x357/0x660 worker_thread+0x390/0x4c0 ? pfx_worker_thread+0x10/0x10 kthread+0x190/0x1d0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK>
Allocated by task 161446: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0x7b/0x90 __kmalloc_noprof+0x1a7/0x470 memstick_alloc_host+0x1f/0xe0 [memstick] rtsx_usb_ms_drv_probe+0x47/0x320 [rtsx_usb_ms] platform_probe+0x60/0xe0 call_driver_probe+0x35/0x120 really_probe+0x123/0x410 __driver_probe_device+0xc7/0x1e0 driver_probe_device+0x49/0xf0 __device_attach_driver+0xc6/0x160 bus_for_each_drv+0xe4/0x160 __device_attach+0x13a/0x2b0 bus_probe_device+0xbd/0xd0 device_add+0x4a5/0x760 platform_device_add+0x189/0x370 mfd_add_device+0x587/0x5e0 mfd_add_devices+0xb1/0x130 rtsx_usb_probe+0x28e/0x2e0 [rtsx_usb] usb_probe_interface+0x15c/0x460 call_driver_probe+0x35/0x120 really_probe+0x123/0x410 __driver_probe_device+0xc7/0x1e0 driver_probe_device+0x49/0xf0 __device_attach_driver+0xc6/0x160 bus_for_each_drv+0xe4/0x160 __device_attach+0x13a/0x2b0 rebind_marked_interfaces.isra.0+0xcc/0x110 usb_reset_device+0x352/0x410 usbdev_do_ioctl+0xe5c/0x1860 usbdev_ioctl+0xa/0x20 __x64_sys_ioctl+0xc5/0xf0 do_syscall_64+0x59/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Freed by task 161506: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x36/0x60 __kasan_slab_free+0x34/0x50 kfree+0x1fd/0x3b0 device_release+0x56/0xf0 kobject_cleanup+0x73/0x1c0 rtsx_usb_ms_drv_remove+0x13d/0x220 [rtsx_usb_ms] platform_remove+0x2f/0x50 device_release_driver_internal+0x24b/0x2e0 bus_remove_device+0x124/0x1d0 device_del+0x239/0x530 platform_device_del.part.0+0x19/0xe0 platform_device_unregister+0x1c/0x40 mfd_remove_devices_fn+0x167/0x170 device_for_each_child_reverse+0xc9/0x130 mfd_remove_devices+0x6e/0xa0 rtsx_usb_disconnect+0x2e/0xd0 [rtsx_usb] usb_unbind_interface+0xf3/0x3f0 device_release_driver_internal+0x24b/0x2e0 proc_disconnect_claim+0x13d/0x220 usbdev_do_ioctl+0xb5e/0x1860 usbdev_ioctl+0xa/0x20 __x64_sys_ioctl+0xc5/0xf0 do_syscall_64+0x59/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Last potentially related work creation: kasan_save_stack+0x20/0x40 kasan_record_aux_stack+0x85/0x90 insert_work+0x29/0x100 __queue_work+0x34a/0x540 call_timer_fn+0x2a/0x160 expire_timers+0x5f/0x1f0 __run_timer_base.part.0+0x1b6/0x1e0 run_timer_softirq+0x8b/0xe0 handle_softirqs+0xf9/0x360 __irq_exit_rcu+0x114/0x130 sysvec_apic_timer_interrupt+0x72/0x90 asm_sysvec_apic_timer_interrupt+0x16/0x20
Second to last potentially related work creation: kasan_save_stack+0x20/0x40 kasan_record_aux_stack+0x85/0x90 insert_work+0x29/0x100 __queue_work+0x34a/0x540 call_timer_fn+0x2a/0x160 expire_timers+0x5f/0x1f0 __run_timer_base.part.0+0x1b6/0x1e0 run_timer_softirq+0x8b/0xe0 handle_softirqs+0xf9/0x ---truncated---(CVE-2025-22020)
In the Linux kernel, the following vulnerability has been resolved:
usb: xhci: Apply the link chain quirk on NEC isoc endpoints
Two clearly different specimens of NEC uPD720200 (one with start/stop bug, one without) were seen to cause IOMMU faults after some Missed Service Errors. Faulting address is immediately after a transfer ring segment and patched dynamic debug messages revealed that the MSE was received when waiting for a TD near the end of that segment:
[ 1.041954] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0 [ 1.042120] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09000 flags=0x0000] [ 1.042146] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09040 flags=0x0000]
It gets even funnier if the next page is a ring segment accessible to the HC. Below, it reports MSE in segment at ff1e8000, plows through a zero-filled page at ff1e9000 and starts reporting events for TRBs in page at ff1ea000 every microframe, instead of jumping to seg ff1e6000.
[ 7.041671] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0 [ 7.041999] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0 [ 7.042011] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042028] xhci_hcd: All TDs skipped for slot 1 ep 2. Clear skip flag. [ 7.042134] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042138] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31 [ 7.042144] xhci_hcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.042259] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042262] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31 [ 7.042266] xhci_hcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820
At some point completion events change from Isoch Buffer Overrun to Short Packet and the HC finally finds cycle bit mismatch in ff1ec000.
[ 7.098130] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13 [ 7.098132] xhci_hcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.098254] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13 [ 7.098256] xhci_hcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.098379] xhci_hcd: Overrun event on slot 1 ep 2
It's possible that data from the isochronous device were written to random buffers of pending TDs on other endpoints (either IN or OUT), other devices or even other HCs in the same IOMMU domain.
Lastly, an error from a different USB device on another HC. Was it caused by the above? I don't know, but it may have been. The disk was working without any other issues and generated PCIe traffic to starve the NEC of upstream BW and trigger those MSEs. The two HCs shared one x1 slot by means of a commercial "PCIe splitter" board.
[ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhci_hcd [ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s [ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00 [ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0
Fortunately, it appears that this ridiculous bug is avoided by setting the chain bit of Link TRBs on isochronous rings. Other ancient HCs are known which also expect the bit to be set and they ignore Link TRBs if it's not. Reportedly, 0.95 spec guaranteed that the bit is set.
The bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reports tens of MSEs per second and runs into the bug within seconds. Chaining Link TRBs allows the same workload to run for many minutes, many times.
No ne ---truncated---(CVE-2025-22022)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix overflow in dacloffset bounds check
The dacloffset field was originally typed as int and used in an unchecked addition, which could overflow and bypass the existing bounds check in both smb_check_perm_dacl() and smb_inherit_dacl().
This could result in out-of-bounds memory access and a kernel crash when dereferencing the DACL pointer.
This patch converts dacloffset to unsigned int and uses check_add_overflow() to validate access to the DACL.(CVE-2025-22039)
In the Linux kernel, the following vulnerability has been resolved:
vhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpoint
If vhost_scsi_set_endpoint is called multiple times without a vhost_scsi_clear_endpoint between them, we can hit multiple bugs found by Haoran Zhang:
- Use-after-free when no tpgs are found:
This fixes a use after free that occurs when vhost_scsi_set_endpoint is called more than once and calls after the first call do not find any tpgs to add to the vs_tpg. When vhost_scsi_set_endpoint first finds tpgs to add to the vs_tpg array match=true, so we will do:
vhost_vq_set_backend(vq, vs_tpg); ...
kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg;
If vhost_scsi_set_endpoint is called again and no tpgs are found match=false so we skip the vhost_vq_set_backend call leaving the pointer to the vs_tpg we then free via:
kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg;
If a scsi request is then sent we do:
vhost_scsi_handle_vq -> vhost_scsi_get_req -> vhost_vq_get_backend
which sees the vs_tpg we just did a kfree on.
- Tpg dir removal hang:
This patch fixes an issue where we cannot remove a LIO/target layer tpg (and structs above it like the target) dir due to the refcount dropping to -1.
The problem is that if vhost_scsi_set_endpoint detects a tpg is already in the vs->vs_tpg array or if the tpg has been removed so target_depend_item fails, the undepend goto handler will do target_undepend_item on all tpgs in the vs_tpg array dropping their refcount to 0. At this time vs_tpg contains both the tpgs we have added in the current vhost_scsi_set_endpoint call as well as tpgs we added in previous calls which are also in vs->vs_tpg.
Later, when vhost_scsi_clear_endpoint runs it will do target_undepend_item on all the tpgs in the vs->vs_tpg which will drop their refcount to -1. Userspace will then not be able to remove the tpg and will hang when it tries to do rmdir on the tpg dir.
- Tpg leak:
This fixes a bug where we can leak tpgs and cause them to be un-removable because the target name is overwritten when vhost_scsi_set_endpoint is called multiple times but with different target names.
The bug occurs if a user has called VHOST_SCSI_SET_ENDPOINT and setup a vhost-scsi device to target/tpg mapping, then calls VHOST_SCSI_SET_ENDPOINT again with a new target name that has tpgs we haven't seen before (target1 has tpg1 but target2 has tpg2). When this happens we don't teardown the old target tpg mapping and just overwrite the target name and the vs->vs_tpg array. Later when we do vhost_scsi_clear_endpoint, we are passed in either target1 or target2's name and we will only match that target's tpgs when we loop over the vs->vs_tpg. We will then return from the function without doing target_undepend_item on the tpgs.
Because of all these bugs, it looks like being able to call vhost_scsi_set_endpoint multiple times was never supported. The major user, QEMU, already has checks to prevent this use case. So to fix the issues, this patch prevents vhost_scsi_set_endpoint from being called if it's already successfully added tpgs. To add, remove or change the tpg config or target name, you must do a vhost_scsi_clear_endpoint first.(CVE-2025-22083)
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix off-by-one error in do_split
Syzkaller detected a use-after-free issue in ext4_insert_dentry that was caused by out-of-bounds access due to incorrect splitting in do_split.
BUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 Write of size 251 at addr ffff888074572f14 by task syz-executor335/5847
CPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106 ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154 make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455 ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796 ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431 vfs_symlink+0x137/0x2e0 fs/namei.c:4615 do_symlinkat+0x222/0x3a0 fs/namei.c:4641 __do_sys_symlink fs/namei.c:4662 [inline] __se_sys_symlink fs/namei.c:4660 [inline] __x64_sys_symlink+0x7a/0x90 fs/namei.c:4660 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK>
The following loop is located right above 'if' statement.
for (i = count-1; i >= 0; i--) { / is more than half of this entry in 2nd half of the block? / if (size + map[i].size/2 > blocksize/2) break; size += map[i].size; move++; }
'i' in this case could go down to -1, in which case sum of active entries wouldn't exceed half the block size, but previous behaviour would also do split in half if sum would exceed at the very last block, which in case of having too many long name files in a single block could lead to out-of-bounds access and following use-after-free.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-23150)
In the Linux kernel, the following vulnerability has been resolved:
media: venus: hfi: add check to handle incorrect queue size
qsize represents size of shared queued between driver and video firmware. Firmware can modify this value to an invalid large value. In such situation, empty_space will be bigger than the space actually available. Since new_wr_idx is not checked, so the following code will result in an OOB write. ... qsize = qhdr->q_size
if (wr_idx >= rd_idx) empty_space = qsize - (wr_idx - rd_idx) .... if (new_wr_idx < qsize) { memcpy(wr_ptr, packet, dwords << 2) --> OOB write
Add check to ensure qsize is within the allocated size while reading and writing packets into the queue.(CVE-2025-23158)
In the Linux kernel, the following vulnerability has been resolved:net: ppp: Add bound checking for skb data on ppp_sync_txmungEnsure we have enough data in linear buffer from skb before accessinginitial bytes. This prevents potential out-of-bounds accesseswhen processing short packets.When ppp_sync_txmung receives an incoming package with an emptypayload:(remote) gef➤ p (struct pppoe_hdr ) (skb->head + skb->network_header)$18 = { type = 0x1, ver = 0x1, code = 0x0, sid = 0x2, length = 0x0, tag = 0xffff8880371cdb96}from the skb struct (trimmed) tail = 0x16, end = 0x140, head = 0xffff88803346f400 4 , data = 0xffff88803346f416 : 377 , truesize = 0x380, len = 0x0, data_len = 0x0, mac_len = 0xe, hdr_len = 0x0,it is not safe to access data[2].[(CVE-2025-37749)
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix OOB read when checking dotdot dir
Mounting a corrupted filesystem with directory which contains '.' dir entry with rec_len == block size results in out-of-bounds read (later on, when the corrupted directory is removed).
ext4_empty_dir() assumes every ext4 directory contains at least '.' and '..' as directory entries in the first data block. It first loads the '.' dir entry, performs sanity checks by calling ext4_check_dir_entry() and then uses its rec_len member to compute the location of '..' dir entry (in ext4_next_entry). It assumes the '..' dir entry fits into the same data block.
If the rec_len of '.' is precisely one block (4KB), it slips through the sanity checks (it is considered the last directory entry in the data block) and leaves "struct ext4_dir_entry_2 *de" point exactly past the memory slot allocated to the data block. The following call to ext4_check_dir_entry() on new value of de then dereferences this pointer which results in out-of-bounds mem access.
Fix this by extending __ext4_check_dir_entry() to check for '.' dir entries that reach the end of data block. Make sure to ignore the phony dir entries for checksum (by checking name_len for non-zero).
Note: This is reported by KASAN as use-after-free in case another structure was recently freed from the slot past the bound, but it is really an OOB read.
This issue was found by syzkaller tool.
Call Trace: [ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710 [ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375 [ 38.595158] [ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1 [ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 38.595304] Call Trace: [ 38.595308] <TASK> [ 38.595311] dump_stack_lvl+0xa7/0xd0 [ 38.595325] print_address_description.constprop.0+0x2c/0x3f0 [ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595349] print_report+0xaa/0x250 [ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595368] ? kasan_addr_to_slab+0x9/0x90 [ 38.595378] kasan_report+0xab/0xe0 [ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595400] __ext4_check_dir_entry+0x67e/0x710 [ 38.595410] ext4_empty_dir+0x465/0x990 [ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10 [ 38.595432] ext4_rmdir.part.0+0x29a/0xd10 [ 38.595441] ? __dquot_initialize+0x2a7/0xbf0 [ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10 [ 38.595464] ? __pfxdquotinitialize+0x10/0x10 [ 38.595478] ? down_write+0xdb/0x140 [ 38.595487] ? pfx_down_write+0x10/0x10 [ 38.595497] ext4_rmdir+0xee/0x140 [ 38.595506] vfs_rmdir+0x209/0x670 [ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190 [ 38.595529] do_rmdir+0x363/0x3c0 [ 38.595537] ? __pfx_do_rmdir+0x10/0x10 [ 38.595544] ? strncpy_from_user+0x1ff/0x2e0 [ 38.595561] __x64_sys_unlinkat+0xf0/0x130 [ 38.595570] do_syscall_64+0x5b/0x180 [ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-37785)
In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: fix nested key length validation in the set() actionIt s not safe to access nla_len(ovs_key) if the data is smaller thanthe netlink header. Check that the attribute is OK first.(CVE-2025-37789)
In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid
There is a string parsing logic error which can lead to an overflow of hid or uid buffers. Comparing ACPIID_LEN against a total string length doesn't take into account the lengths of individual hid and uid buffers so the check is insufficient in some cases. For example if the length of hid string is 4 and the length of the uid string is 260, the length of str will be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer which size is 256.
The same applies to the hid string with length 13 and uid string with length 250.
Check the length of hid and uid strings separately to prevent buffer overflow.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37927)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAX
Otherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof() when resizing hashtable because __GFP_NOWARN is unset.
Similar to:
b541ba7d1f5a ("netfilter: conntrack: clamp maximum hashtable size to INT_MAX")(CVE-2025-38201)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix WARN() in get_bpf_raw_tp_regs
syzkaller reported an issue:
WARNING: CPU: 3 PID: 5971 at kernel/trace/bpf_trace.c:1861 get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861 Modules linked in: CPU: 3 UID: 0 PID: 5971 Comm: syz-executor205 Not tainted 6.15.0-rc5-syzkaller-00038-g707df3375124 #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861 RSP: 0018:ffffc90003636fa8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000003 RCX: ffffffff81c6bc4c RDX: ffff888032efc880 RSI: ffffffff81c6bc83 RDI: 0000000000000005 RBP: ffff88806a730860 R08: 0000000000000005 R09: 0000000000000003 R10: 0000000000000004 R11: 0000000000000000 R12: 0000000000000004 R13: 0000000000000001 R14: ffffc90003637008 R15: 0000000000000900 FS: 0000000000000000(0000) GS:ffff8880d6cdf000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7baee09130 CR3: 0000000029f5a000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> _bpfget_stack_raw_tp kernel/trace/bpf_trace.c:1934 [inline] bpf_get_stack_raw_tp+0x24/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47 bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline] bpf_prog_run include/linux/filter.h:718 [inline] bpf_prog_run include/linux/filter.h:725 [inline] __bpf_trace_run kernel/trace/bpf_trace.c:2363 [inline] bpf_trace_run3+0x23f/0x5a0 kernel/trace/bpf_trace.c:2405 __bpf_trace_mmap_lock_acquire_returned+0xfc/0x140 include/trace/events/mmap_lock.h:47 __traceiter_mmap_lock_acquire_returned+0x79/0xc0 include/trace/events/mmap_lock.h:47 __do_trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] __mmap_lock_do_trace_acquire_returned+0x138/0x1f0 mm/mmap_lock.c:35 __mmap_lock_trace_acquire_returned include/linux/mmap_lock.h:36 [inline] mmap_read_trylock include/linux/mmap_lock.h:204 [inline] stack_map_get_build_id_offset+0x535/0x6f0 kernel/bpf/stackmap.c:157 __bpf_get_stack+0x307/0xa10 kernel/bpf/stackmap.c:483 _bpfget_stack kernel/bpf/stackmap.c:499 [inline] bpf_get_stack+0x32/0x40 kernel/bpf/stackmap.c:496 __bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1941 [inline] bpf_get_stack_raw_tp+0x124/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47
Tracepoint like trace_mmap_lock_acquire_returned may cause nested call as the corner case show above, which will be resolved with more general method in the future. As a result, WARN_ON_ONCE will be triggered. As Alexei suggested, remove the WARN_ON_ONCE first.(CVE-2025-38285)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: Always pass notifications when child class becomes empty
Certain classful qdiscs may invoke their classes' dequeue handler on an enqueue operation. This may unexpectedly empty the child qdisc and thus make an in-flight class passive via qlen_notify(). Most qdiscs do not expect such behaviour at this point in time and may re-activate the class eventually anyways which will lead to a use-after-free.
The referenced fix commit attempted to fix this behavior for the HFSC case by moving the backlog accounting around, though this turned out to be incomplete since the parent's parent may run into the issue too. The following reproducer demonstrates this use-after-free:
tc qdisc add dev lo root handle 1: drr
tc filter add dev lo parent 1: basic classid 1:1
tc class add dev lo parent 1: classid 1:1 drr
tc qdisc add dev lo parent 1:1 handle 2: hfsc def 1
tc class add dev lo parent 2: classid 2:1 hfsc rt m1 8 d 1 m2 0
tc qdisc add dev lo parent 2:1 handle 3: netem
tc qdisc add dev lo parent 3:1 handle 4: blackhole
echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888
tc class delete dev lo classid 1:1
echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888
Since backlog accounting issues leading to a use-after-frees on stale class pointers is a recurring pattern at this point, this patch takes a different approach. Instead of trying to fix the accounting, the patch ensures that qdisc_tree_reduce_backlog always calls qlen_notify when the child qdisc is empty. This solves the problem because deletion of qdiscs always involves a call to qdisc_reset() and / or qdisc_purge_queue() which ultimately resets its qlen to 0 thus causing the following qdisc_tree_reduce_backlog() to report to the parent. Note that this may call qlen_notify on passive classes multiple times. This is not a problem after the recent patch series that made all the classful qdiscs qlen_notify() handlers idempotent.(CVE-2025-38350)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix use-after-free in cifs_oplock_break
A race condition can occur in cifs_oplock_break() leading to a use-after-free of the cinode structure when unmounting:
cifs_oplock_break() _cifsFileInfo_put(cfile) cifsFileInfo_put_final() cifs_sb_deactive() [last ref, start releasing sb] kill_sb() kill_anon_super() generic_shutdown_super() evict_inodes() dispose_list() evict() destroy_inode() call_rcu(&inode->i_rcu, i_callback) spin_lock(&cinode->open_file_lock) <- OK [later] i_callback() cifs_free_inode() kmem_cache_free(cinode) spin_unlock(&cinode->open_file_lock) <- UAF cifs_done_oplock_break(cinode) <- UAF
The issue occurs when umount has already released its reference to the superblock. When _cifsFileInfo_put() calls cifs_sb_deactive(), this releases the last reference, triggering the immediate cleanup of all inodes under RCU. However, cifs_oplock_break() continues to access the cinode after this point, resulting in use-after-free.
Fix this by holding an extra reference to the superblock during the entire oplock break operation. This ensures that the superblock and its inodes remain valid until the oplock break completes.(CVE-2025-38527)
In the Linux kernel, the following vulnerability has been resolved:
net/packet: fix a race in packet_set_ring() and packet_notifier()
When packet_set_ring() releases po->bind_lock, another thread can run packet_notifier() and process an NETDEV_UP event.
This race and the fix are both similar to that of commit 15fe076edea7 ("net/packet: fix a race in packet_bind() and packet_notifier()").
There too the packet_notifier NETDEV_UP event managed to run while a po->bind_lock critical section had to be temporarily released. And the fix was similarly to temporarily set po->num to zero to keep the socket unhooked until the lock is retaken.
The po->bind_lock in packet_set_ring and packet_notifier precede the introduction of git history.(CVE-2025-38617)
In the Linux kernel, the following vulnerability has been resolved:
ice: Fix a null pointer dereference in ice_copy_and_init_pkg()
Add check for the return value of devm_kmemdup() to prevent potential null pointer dereference.(CVE-2025-38664)
In the Linux kernel, the following vulnerability has been resolved:
ASoC: core: Check for rtd == NULL in snd_soc_remove_pcm_runtime()
snd_soc_remove_pcm_runtime() might be called with rtd == NULL which will leads to null pointer dereference. This was reproduced with topology loading and marking a link as ignore due to missing hardware component on the system. On module removal the soc_tplg_remove_link() would call snd_soc_remove_pcm_runtime() with rtd == NULL since the link was ignored, no runtime was created.(CVE-2025-38706)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: Validate UAC3 power domain descriptors, too
UAC3 power domain descriptors need to be verified with its variable bLength for avoiding the unexpected OOB accesses by malicious firmware, too.(CVE-2025-38729)
In the Linux kernel, the following vulnerability has been resolved:
vxlan: Fix NPD when refreshing an FDB entry with a nexthop object
VXLAN FDB entries can point to either a remote destination or an FDB nexthop group. The latter is usually used in EVPN deployments where learning is disabled.
However, when learning is enabled, an incoming packet might try to refresh an FDB entry that points to an FDB nexthop group and therefore does not have a remote. Such packets should be dropped, but they are only dropped after dereferencing the non-existent remote, resulting in a NPD [1] which can be reproduced using [2].
Fix by dropping such packets earlier. Remove the misleading comment from first_remote_rcu().
[1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_snoop+0x98/0x1e0 [...] Call Trace: <TASK> vxlan_encap_bypass+0x209/0x240 encap_bypass_if_local+0xb1/0x100 vxlan_xmit_one+0x1375/0x17e0 vxlan_xmit+0x6b4/0x15f0 dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53
[2] #!/bin/bash
ip address add 192.0.2.1/32 dev lo ip address add 192.0.2.2/32 dev lo
ip nexthop add id 1 via 192.0.2.3 fdb ip nexthop add id 10 group 1 fdb
ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning
bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020 bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10
mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q(CVE-2025-39851)
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Prevent access to vCPU events before init
Another day, another syzkaller bug. KVM erroneously allows userspace to pend vCPU events for a vCPU that hasn't been initialized yet, leading to KVM interpreting a bunch of uninitialized garbage for routing / injecting the exception.
In one case the injection code and the hyp disagree on whether the vCPU has a 32bit EL1 and put the vCPU into an illegal mode for AArch64, tripping the BUG() in exception_target_el() during the next injection:
kernel BUG at arch/arm64/kvm/inject_fault.c:40! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT Hardware name: linux,dummy-virt (DT) pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : exception_target_el+0x88/0x8c lr : pend_serror_exception+0x18/0x13c sp : ffff800082f03a10 x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000 x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000 x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004 x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20 Call trace: exception_target_el+0x88/0x8c (P) kvm_inject_serror_esr+0x40/0x3b4 __kvm_arm_vcpu_set_events+0xf0/0x100 kvm_arch_vcpu_ioctl+0x180/0x9d4 kvm_vcpu_ioctl+0x60c/0x9f4 __arm64_sys_ioctl+0xac/0x104 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000)
Reject the ioctls outright as no sane VMM would call these before KVM_ARM_VCPU_INIT anyway. Even if it did the exception would've been thrown away by the eventual reset of the vCPU's state.(CVE-2025-40102)
In the Linux kernel, the following vulnerability has been resolved:
smc: Use __sk_dst_get() and dst_dev_rcu() in in smc_clc_prfx_set().
smc_clc_prfx_set() is called during connect() and not under RCU nor RTNL.
Using sk_dst_get(sk)->dev could trigger UAF.
Let's use __sk_dst_get() and dev_dst_rcu() under rcu_read_lock() after kernel_getsockname().
Note that the returned value of smc_clc_prfx_set() is not used in the caller.
While at it, we change the 1st arg of smc_clc_prfx_set[46]_rcu() not to touch dst there.(CVE-2025-40139)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"bpftool-debuginfo-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"kernel-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"kernel-debuginfo-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"kernel-debugsource-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"kernel-devel-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"kernel-headers-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"kernel-source-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"kernel-tools-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"kernel-tools-devel-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"perf-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"perf-debuginfo-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"python3-perf-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm"
],
"src": [
"kernel-5.10.0-294.0.0.197.oe2203sp4.src.rpm"
],
"x86_64": [
"bpftool-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"bpftool-debuginfo-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"kernel-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"kernel-debuginfo-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"kernel-debugsource-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"kernel-devel-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"kernel-headers-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"kernel-source-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"kernel-tools-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"kernel-tools-devel-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"perf-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"perf-debuginfo-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"python3-perf-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-294.0.0.197.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-294.0.0.197.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\next4: update s_journal_inum if it changes after journal replay\n\nWhen mounting a crafted ext4 image, s_journal_inum may change after journal\nreplay, which is obviously unreasonable because we have successfully loaded\nand replayed the journal through the old s_journal_inum. And the new\ns_journal_inum bypasses some of the checks in ext4_get_journal(), which\nmay trigger a null pointer dereference problem. So if s_journal_inum\nchanges after the journal replay, we ignore the change, and rewrite the\ncurrent journal_inum to the superblock.(CVE-2023-53091)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: lpfc: Fix use-after-free KFENCE violation during sysfs firmware write\n\nDuring the sysfs firmware write process, a use-after-free read warning is\nlogged from the lpfc_wr_object() routine:\n\n BUG: KFENCE: use-after-free read in lpfc_wr_object+0x235/0x310 [lpfc]\n Use-after-free read at 0x0000000000cf164d (in kfence-#111):\n lpfc_wr_object+0x235/0x310 [lpfc]\n lpfc_write_firmware.cold+0x206/0x30d [lpfc]\n lpfc_sli4_request_firmware_update+0xa6/0x100 [lpfc]\n lpfc_request_firmware_upgrade_store+0x66/0xb0 [lpfc]\n kernfs_fop_write_iter+0x121/0x1b0\n new_sync_write+0x11c/0x1b0\n vfs_write+0x1ef/0x280\n ksys_write+0x5f/0xe0\n do_syscall_64+0x59/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nThe driver accessed wr_object pointer data, which was initialized into\nmailbox payload memory, after the mailbox object was released back to the\nmailbox pool.\n\nFix by moving the mailbox free calls to the end of the routine ensuring\nthat we don\u0026apos;t reference internal mailbox memory after release.(CVE-2023-53282)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nstart_kernel: Add __no_stack_protector function attribute\n\nBack during the discussion of\ncommit a9a3ed1eff36 (\u0026quot;x86: Fix early boot crash on gcc-10, third try\u0026quot;)\nwe discussed the need for a function attribute to control the omission\nof stack protectors on a per-function basis; at the time Clang had\nsupport for no_stack_protector but GCC did not. This was fixed in\ngcc-11. Now that the function attribute is available, let\u0026apos;s start using\nit.\n\nCallers of boot_init_stack_canary need to use this function attribute\nunless they\u0026apos;re compiled with -fno-stack-protector, otherwise the canary\nstored in the stack slot of the caller will differ upon the call to\nboot_init_stack_canary. This will lead to a call to __stack_chk_fail()\nthen panic.(CVE-2023-53491)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: Fix hci_suspend_sync crash\n\nIf hci_unregister_dev() frees the hci_dev object but hci_suspend_notifier\nmay still be accessing it, it can cause the program to crash.\nHere\u0026apos;s the call trace:\n \u0026lt;4\u0026gt;[102152.653246] Call Trace:\n \u0026lt;4\u0026gt;[102152.653254] hci_suspend_sync+0x109/0x301 [bluetooth]\n \u0026lt;4\u0026gt;[102152.653259] hci_suspend_dev+0x78/0xcd [bluetooth]\n \u0026lt;4\u0026gt;[102152.653263] hci_suspend_notifier+0x42/0x7a [bluetooth]\n \u0026lt;4\u0026gt;[102152.653268] notifier_call_chain+0x43/0x6b\n \u0026lt;4\u0026gt;[102152.653271] __blocking_notifier_call_chain+0x48/0x69\n \u0026lt;4\u0026gt;[102152.653273] __pm_notifier_call_chain+0x22/0x39\n \u0026lt;4\u0026gt;[102152.653276] pm_suspend+0x287/0x57c\n \u0026lt;4\u0026gt;[102152.653278] state_store+0xae/0xe5\n \u0026lt;4\u0026gt;[102152.653281] kernfs_fop_write+0x109/0x173\n \u0026lt;4\u0026gt;[102152.653284] __vfs_write+0x16f/0x1a2\n \u0026lt;4\u0026gt;[102152.653287] ? selinux_file_permission+0xca/0x16f\n \u0026lt;4\u0026gt;[102152.653289] ? security_file_permission+0x36/0x109\n \u0026lt;4\u0026gt;[102152.653291] vfs_write+0x114/0x21d\n \u0026lt;4\u0026gt;[102152.653293] __x64_sys_write+0x7b/0xdb\n \u0026lt;4\u0026gt;[102152.653296] do_syscall_64+0x59/0x194\n \u0026lt;4\u0026gt;[102152.653299] entry_SYSCALL_64_after_hwframe+0x5c/0xc1\n\nThis patch holds the reference count of the hci_dev object while\nprocessing it in hci_suspend_notifier to avoid potential crash\ncaused by the race condition.(CVE-2023-53520)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_event: call disconnect callback before deleting conn\n\nIn hci_cs_disconnect, we do hci_conn_del even if disconnection failed.\n\nISO, L2CAP and SCO connections refer to the hci_conn without\nhci_conn_get, so disconn_cfm must be called so they can clean up their\nconn, otherwise use-after-free occurs.\n\nISO:\n==========================================================\niso_sock_connect:880: sk 00000000eabd6557\niso_connect_cis:356: 70:1a:b8:98:ff:a2 -\u0026gt; 28:3d:c2:4a:7e:da\n...\niso_conn_add:140: hcon 000000001696f1fd conn 00000000b6251073\nhci_dev_put:1487: hci0 orig refcnt 17\n__iso_chan_add:214: conn 00000000b6251073\niso_sock_clear_timer:117: sock 00000000eabd6557 state 3\n...\nhci_rx_work:4085: hci0 Event packet\nhci_event_packet:7601: hci0: event 0x0f\nhci_cmd_status_evt:4346: hci0: opcode 0x0406\nhci_cs_disconnect:2760: hci0: status 0x0c\nhci_sent_cmd_data:3107: hci0 opcode 0x0406\nhci_conn_del:1151: hci0 hcon 000000001696f1fd handle 2560\nhci_conn_unlink:1102: hci0: hcon 000000001696f1fd\nhci_conn_drop:1451: hcon 00000000d8521aaf orig refcnt 2\nhci_chan_list_flush:2780: hcon 000000001696f1fd\nhci_dev_put:1487: hci0 orig refcnt 21\nhci_dev_put:1487: hci0 orig refcnt 20\nhci_req_cmd_complete:3978: opcode 0x0406 status 0x0c\n... \u0026lt;no iso_* activity on sk/conn\u0026gt; ...\niso_sock_sendmsg:1098: sock 00000000dea5e2e0, sk 00000000eabd6557\nBUG: kernel NULL pointer dereference, address: 0000000000000668\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP PTI\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014\nRIP: 0010:iso_sock_sendmsg (net/bluetooth/iso.c:1112) bluetooth\n==========================================================\n\nL2CAP:\n==================================================================\nhci_cmd_status_evt:4359: hci0: opcode 0x0406\nhci_cs_disconnect:2760: hci0: status 0x0c\nhci_sent_cmd_data:3085: hci0 opcode 0x0406\nhci_conn_del:1151: hci0 hcon ffff88800c999000 handle 3585\nhci_conn_unlink:1102: hci0: hcon ffff88800c999000\nhci_chan_list_flush:2780: hcon ffff88800c999000\nhci_chan_del:2761: hci0 hcon ffff88800c999000 chan ffff888018ddd280\n...\nBUG: KASAN: slab-use-after-free in hci_send_acl+0x2d/0x540 [bluetooth]\nRead of size 8 at addr ffff888018ddd298 by task bluetoothd/1175\n\nCPU: 0 PID: 1175 Comm: bluetoothd Tainted: G E 6.4.0-rc4+ #2\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x5b/0x90\n print_report+0xcf/0x670\n ? __virt_addr_valid+0xf8/0x180\n ? hci_send_acl+0x2d/0x540 [bluetooth]\n kasan_report+0xa8/0xe0\n ? hci_send_acl+0x2d/0x540 [bluetooth]\n hci_send_acl+0x2d/0x540 [bluetooth]\n ? __pfx___lock_acquire+0x10/0x10\n l2cap_chan_send+0x1fd/0x1300 [bluetooth]\n ? l2cap_sock_sendmsg+0xf2/0x170 [bluetooth]\n ? __pfx_l2cap_chan_send+0x10/0x10 [bluetooth]\n ? lock_release+0x1d5/0x3c0\n ? mark_held_locks+0x1a/0x90\n l2cap_sock_sendmsg+0x100/0x170 [bluetooth]\n sock_write_iter+0x275/0x280\n ? __pfx_sock_write_iter+0x10/0x10\n ? __pfx___lock_acquire+0x10/0x10\n do_iter_readv_writev+0x176/0x220\n ? __pfx_do_iter_readv_writev+0x10/0x10\n ? find_held_lock+0x83/0xa0\n ? selinux_file_permission+0x13e/0x210\n do_iter_write+0xda/0x340\n vfs_writev+0x1b4/0x400\n ? __pfx_vfs_writev+0x10/0x10\n ? __seccomp_filter+0x112/0x750\n ? populate_seccomp_data+0x182/0x220\n ? __fget_light+0xdf/0x100\n ? do_writev+0x19d/0x210\n do_writev+0x19d/0x210\n ? __pfx_do_writev+0x10/0x10\n ? mark_held_locks+0x1a/0x90\n do_syscall_64+0x60/0x90\n ? lockdep_hardirqs_on_prepare+0x149/0x210\n ? do_syscall_64+0x6c/0x90\n ? lockdep_hardirqs_on_prepare+0x149/0x210\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\nRIP: 0033:0x7ff45cb23e64\nCode: 15 d1 1f 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d 9d a7 0d 00 00 74 13 b8 14 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89\nRSP: 002b:00007fff21ae09b8 EFLAGS: 00000202 ORIG_RAX: 0000000000000014\nRAX: ffffffffffffffda RBX: \n---truncated---(CVE-2023-53673)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: adc: rockchip_saradc: fix information leak in triggered buffer\n\nThe \u0026apos;data\u0026apos; local struct is used to push data to user space from a\ntriggered buffer, but it does not set values for inactive channels, as\nit only uses iio_for_each_active_channel() to assign new values.\n\nInitialize the struct to zero before using it to avoid pushing\nuninitialized information to userspace.(CVE-2024-57907)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: dummy: iio_simply_dummy_buffer: fix information leak in triggered buffer\n\nThe \u0026apos;data\u0026apos; array is allocated via kmalloc() and it is used to push data\nto user space from a triggered buffer, but it does not set values for\ninactive channels, as it only uses iio_for_each_active_channel()\nto assign new values.\n\nUse kzalloc for the memory allocation to avoid pushing uninitialized\ninformation to userspace.(CVE-2024-57911)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmemory: tegra20-emc: fix an OF node reference bug in tegra_emc_find_node_by_ram_code()\n\nAs of_find_node_by_name() release the reference of the argument device\nnode, tegra_emc_find_node_by_ram_code() releases some device nodes while\nstill in use, resulting in possible UAFs. According to the bindings and\nthe in-tree DTS files, the \u0026quot;emc-tables\u0026quot; node is always device\u0026apos;s child\nnode with the property \u0026quot;nvidia,use-ram-code\u0026quot;, and the \u0026quot;lpddr2\u0026quot; node is a\nchild of the \u0026quot;emc-tables\u0026quot; node. Thus utilize the\nfor_each_child_of_node() macro and of_get_child_by_name() instead of\nof_find_node_by_name() to simplify the code.\n\nThis bug was found by an experimental verification tool that I am\ndeveloping.\n\n[krzysztof: applied v1, adjust the commit msg to incorporate v2 parts](CVE-2024-58034)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: limit printed string from FW file\n\nThere\u0026apos;s no guarantee here that the file is always with a\nNUL-termination, so reading the string may read beyond the\nend of the TLV. If that\u0026apos;s the last TLV in the file, it can\nperhaps even read beyond the end of the file buffer.\n\nFix that by limiting the print format to the size of the\nbuffer we have.(CVE-2025-21905)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmemstick: rtsx_usb_ms: Fix slab-use-after-free in rtsx_usb_ms_drv_remove\n\nThis fixes the following crash:\n\n==================================================================\nBUG: KASAN: slab-use-after-free in rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\nRead of size 8 at addr ffff888136335380 by task kworker/6:0/140241\n\nCPU: 6 UID: 0 PID: 140241 Comm: kworker/6:0 Kdump: loaded Tainted: G E 6.14.0-rc6+ #1\nTainted: [E]=UNSIGNED_MODULE\nHardware name: LENOVO 30FNA1V7CW/1057, BIOS S0EKT54A 07/01/2024\nWorkqueue: events rtsx_usb_ms_poll_card [rtsx_usb_ms]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x51/0x70\n print_address_description.constprop.0+0x27/0x320\n ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\n print_report+0x3e/0x70\n kasan_report+0xab/0xe0\n ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\n rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\n ? __pfx_rtsx_usb_ms_poll_card+0x10/0x10 [rtsx_usb_ms]\n ? __pfx___schedule+0x10/0x10\n ? kick_pool+0x3b/0x270\n process_one_work+0x357/0x660\n worker_thread+0x390/0x4c0\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x190/0x1d0\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x2d/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 161446:\n kasan_save_stack+0x20/0x40\n kasan_save_track+0x10/0x30\n __kasan_kmalloc+0x7b/0x90\n __kmalloc_noprof+0x1a7/0x470\n memstick_alloc_host+0x1f/0xe0 [memstick]\n rtsx_usb_ms_drv_probe+0x47/0x320 [rtsx_usb_ms]\n platform_probe+0x60/0xe0\n call_driver_probe+0x35/0x120\n really_probe+0x123/0x410\n __driver_probe_device+0xc7/0x1e0\n driver_probe_device+0x49/0xf0\n __device_attach_driver+0xc6/0x160\n bus_for_each_drv+0xe4/0x160\n __device_attach+0x13a/0x2b0\n bus_probe_device+0xbd/0xd0\n device_add+0x4a5/0x760\n platform_device_add+0x189/0x370\n mfd_add_device+0x587/0x5e0\n mfd_add_devices+0xb1/0x130\n rtsx_usb_probe+0x28e/0x2e0 [rtsx_usb]\n usb_probe_interface+0x15c/0x460\n call_driver_probe+0x35/0x120\n really_probe+0x123/0x410\n __driver_probe_device+0xc7/0x1e0\n driver_probe_device+0x49/0xf0\n __device_attach_driver+0xc6/0x160\n bus_for_each_drv+0xe4/0x160\n __device_attach+0x13a/0x2b0\n rebind_marked_interfaces.isra.0+0xcc/0x110\n usb_reset_device+0x352/0x410\n usbdev_do_ioctl+0xe5c/0x1860\n usbdev_ioctl+0xa/0x20\n __x64_sys_ioctl+0xc5/0xf0\n do_syscall_64+0x59/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nFreed by task 161506:\n kasan_save_stack+0x20/0x40\n kasan_save_track+0x10/0x30\n kasan_save_free_info+0x36/0x60\n __kasan_slab_free+0x34/0x50\n kfree+0x1fd/0x3b0\n device_release+0x56/0xf0\n kobject_cleanup+0x73/0x1c0\n rtsx_usb_ms_drv_remove+0x13d/0x220 [rtsx_usb_ms]\n platform_remove+0x2f/0x50\n device_release_driver_internal+0x24b/0x2e0\n bus_remove_device+0x124/0x1d0\n device_del+0x239/0x530\n platform_device_del.part.0+0x19/0xe0\n platform_device_unregister+0x1c/0x40\n mfd_remove_devices_fn+0x167/0x170\n device_for_each_child_reverse+0xc9/0x130\n mfd_remove_devices+0x6e/0xa0\n rtsx_usb_disconnect+0x2e/0xd0 [rtsx_usb]\n usb_unbind_interface+0xf3/0x3f0\n device_release_driver_internal+0x24b/0x2e0\n proc_disconnect_claim+0x13d/0x220\n usbdev_do_ioctl+0xb5e/0x1860\n usbdev_ioctl+0xa/0x20\n __x64_sys_ioctl+0xc5/0xf0\n do_syscall_64+0x59/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nLast potentially related work creation:\n kasan_save_stack+0x20/0x40\n kasan_record_aux_stack+0x85/0x90\n insert_work+0x29/0x100\n __queue_work+0x34a/0x540\n call_timer_fn+0x2a/0x160\n expire_timers+0x5f/0x1f0\n __run_timer_base.part.0+0x1b6/0x1e0\n run_timer_softirq+0x8b/0xe0\n handle_softirqs+0xf9/0x360\n __irq_exit_rcu+0x114/0x130\n sysvec_apic_timer_interrupt+0x72/0x90\n asm_sysvec_apic_timer_interrupt+0x16/0x20\n\nSecond to last potentially related work creation:\n kasan_save_stack+0x20/0x40\n kasan_record_aux_stack+0x85/0x90\n insert_work+0x29/0x100\n __queue_work+0x34a/0x540\n call_timer_fn+0x2a/0x160\n expire_timers+0x5f/0x1f0\n __run_timer_base.part.0+0x1b6/0x1e0\n run_timer_softirq+0x8b/0xe0\n handle_softirqs+0xf9/0x\n---truncated---(CVE-2025-22020)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: xhci: Apply the link chain quirk on NEC isoc endpoints\n\nTwo clearly different specimens of NEC uPD720200 (one with start/stop\nbug, one without) were seen to cause IOMMU faults after some Missed\nService Errors. Faulting address is immediately after a transfer ring\nsegment and patched dynamic debug messages revealed that the MSE was\nreceived when waiting for a TD near the end of that segment:\n\n[ 1.041954] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0\n[ 1.042120] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09000 flags=0x0000]\n[ 1.042146] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09040 flags=0x0000]\n\nIt gets even funnier if the next page is a ring segment accessible to\nthe HC. Below, it reports MSE in segment at ff1e8000, plows through a\nzero-filled page at ff1e9000 and starts reporting events for TRBs in\npage at ff1ea000 every microframe, instead of jumping to seg ff1e6000.\n\n[ 7.041671] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0\n[ 7.041999] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0\n[ 7.042011] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint\n[ 7.042028] xhci_hcd: All TDs skipped for slot 1 ep 2. Clear skip flag.\n[ 7.042134] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint\n[ 7.042138] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31\n[ 7.042144] xhci_hcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820\n[ 7.042259] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint\n[ 7.042262] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31\n[ 7.042266] xhci_hcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820\n\nAt some point completion events change from Isoch Buffer Overrun to\nShort Packet and the HC finally finds cycle bit mismatch in ff1ec000.\n\n[ 7.098130] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13\n[ 7.098132] xhci_hcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820\n[ 7.098254] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13\n[ 7.098256] xhci_hcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820\n[ 7.098379] xhci_hcd: Overrun event on slot 1 ep 2\n\nIt\u0026apos;s possible that data from the isochronous device were written to\nrandom buffers of pending TDs on other endpoints (either IN or OUT),\nother devices or even other HCs in the same IOMMU domain.\n\nLastly, an error from a different USB device on another HC. Was it\ncaused by the above? I don\u0026apos;t know, but it may have been. The disk\nwas working without any other issues and generated PCIe traffic to\nstarve the NEC of upstream BW and trigger those MSEs. The two HCs\nshared one x1 slot by means of a commercial \u0026quot;PCIe splitter\u0026quot; board.\n\n[ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhci_hcd\n[ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s\n[ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00\n[ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0\n\nFortunately, it appears that this ridiculous bug is avoided by setting\nthe chain bit of Link TRBs on isochronous rings. Other ancient HCs are\nknown which also expect the bit to be set and they ignore Link TRBs if\nit\u0026apos;s not. Reportedly, 0.95 spec guaranteed that the bit is set.\n\nThe bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reports\ntens of MSEs per second and runs into the bug within seconds. Chaining\nLink TRBs allows the same workload to run for many minutes, many times.\n\nNo ne\n---truncated---(CVE-2025-22022)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix overflow in dacloffset bounds check\n\nThe dacloffset field was originally typed as int and used in an\nunchecked addition, which could overflow and bypass the existing\nbounds check in both smb_check_perm_dacl() and smb_inherit_dacl().\n\nThis could result in out-of-bounds memory access and a kernel crash\nwhen dereferencing the DACL pointer.\n\nThis patch converts dacloffset to unsigned int and uses\ncheck_add_overflow() to validate access to the DACL.(CVE-2025-22039)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpoint\n\nIf vhost_scsi_set_endpoint is called multiple times without a\nvhost_scsi_clear_endpoint between them, we can hit multiple bugs\nfound by Haoran Zhang:\n\n1. Use-after-free when no tpgs are found:\n\nThis fixes a use after free that occurs when vhost_scsi_set_endpoint is\ncalled more than once and calls after the first call do not find any\ntpgs to add to the vs_tpg. When vhost_scsi_set_endpoint first finds\ntpgs to add to the vs_tpg array match=true, so we will do:\n\nvhost_vq_set_backend(vq, vs_tpg);\n...\n\nkfree(vs-\u0026gt;vs_tpg);\nvs-\u0026gt;vs_tpg = vs_tpg;\n\nIf vhost_scsi_set_endpoint is called again and no tpgs are found\nmatch=false so we skip the vhost_vq_set_backend call leaving the\npointer to the vs_tpg we then free via:\n\nkfree(vs-\u0026gt;vs_tpg);\nvs-\u0026gt;vs_tpg = vs_tpg;\n\nIf a scsi request is then sent we do:\n\nvhost_scsi_handle_vq -\u0026gt; vhost_scsi_get_req -\u0026gt; vhost_vq_get_backend\n\nwhich sees the vs_tpg we just did a kfree on.\n\n2. Tpg dir removal hang:\n\nThis patch fixes an issue where we cannot remove a LIO/target layer\ntpg (and structs above it like the target) dir due to the refcount\ndropping to -1.\n\nThe problem is that if vhost_scsi_set_endpoint detects a tpg is already\nin the vs-\u0026gt;vs_tpg array or if the tpg has been removed so\ntarget_depend_item fails, the undepend goto handler will do\ntarget_undepend_item on all tpgs in the vs_tpg array dropping their\nrefcount to 0. At this time vs_tpg contains both the tpgs we have added\nin the current vhost_scsi_set_endpoint call as well as tpgs we added in\nprevious calls which are also in vs-\u0026gt;vs_tpg.\n\nLater, when vhost_scsi_clear_endpoint runs it will do\ntarget_undepend_item on all the tpgs in the vs-\u0026gt;vs_tpg which will drop\ntheir refcount to -1. Userspace will then not be able to remove the tpg\nand will hang when it tries to do rmdir on the tpg dir.\n\n3. Tpg leak:\n\nThis fixes a bug where we can leak tpgs and cause them to be\nun-removable because the target name is overwritten when\nvhost_scsi_set_endpoint is called multiple times but with different\ntarget names.\n\nThe bug occurs if a user has called VHOST_SCSI_SET_ENDPOINT and setup\na vhost-scsi device to target/tpg mapping, then calls\nVHOST_SCSI_SET_ENDPOINT again with a new target name that has tpgs we\nhaven\u0026apos;t seen before (target1 has tpg1 but target2 has tpg2). When this\nhappens we don\u0026apos;t teardown the old target tpg mapping and just overwrite\nthe target name and the vs-\u0026gt;vs_tpg array. Later when we do\nvhost_scsi_clear_endpoint, we are passed in either target1 or target2\u0026apos;s\nname and we will only match that target\u0026apos;s tpgs when we loop over the\nvs-\u0026gt;vs_tpg. We will then return from the function without doing\ntarget_undepend_item on the tpgs.\n\nBecause of all these bugs, it looks like being able to call\nvhost_scsi_set_endpoint multiple times was never supported. The major\nuser, QEMU, already has checks to prevent this use case. So to fix the\nissues, this patch prevents vhost_scsi_set_endpoint from being called\nif it\u0026apos;s already successfully added tpgs. To add, remove or change the\ntpg config or target name, you must do a vhost_scsi_clear_endpoint\nfirst.(CVE-2025-22083)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix off-by-one error in do_split\n\nSyzkaller detected a use-after-free issue in ext4_insert_dentry that was\ncaused by out-of-bounds access due to incorrect splitting in do_split.\n\nBUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109\nWrite of size 251 at addr ffff888074572f14 by task syz-executor335/5847\n\nCPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:488\n kasan_report+0x143/0x180 mm/kasan/report.c:601\n kasan_check_range+0x282/0x290 mm/kasan/generic.c:189\n __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106\n ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109\n add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154\n make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351\n ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455\n ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796\n ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431\n vfs_symlink+0x137/0x2e0 fs/namei.c:4615\n do_symlinkat+0x222/0x3a0 fs/namei.c:4641\n __do_sys_symlink fs/namei.c:4662 [inline]\n __se_sys_symlink fs/namei.c:4660 [inline]\n __x64_sys_symlink+0x7a/0x90 fs/namei.c:4660\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n \u0026lt;/TASK\u0026gt;\n\nThe following loop is located right above \u0026apos;if\u0026apos; statement.\n\nfor (i = count-1; i \u0026gt;= 0; i--) {\n\t/* is more than half of this entry in 2nd half of the block? */\n\tif (size + map[i].size/2 \u0026gt; blocksize/2)\n\t\tbreak;\n\tsize += map[i].size;\n\tmove++;\n}\n\n\u0026apos;i\u0026apos; in this case could go down to -1, in which case sum of active entries\nwouldn\u0026apos;t exceed half the block size, but previous behaviour would also do\nsplit in half if sum would exceed at the very last block, which in case of\nhaving too many long name files in a single block could lead to\nout-of-bounds access and following use-after-free.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-23150)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: venus: hfi: add check to handle incorrect queue size\n\nqsize represents size of shared queued between driver and video\nfirmware. Firmware can modify this value to an invalid large value. In\nsuch situation, empty_space will be bigger than the space actually\navailable. Since new_wr_idx is not checked, so the following code will\nresult in an OOB write.\n...\nqsize = qhdr-\u0026gt;q_size\n\nif (wr_idx \u0026gt;= rd_idx)\n empty_space = qsize - (wr_idx - rd_idx)\n....\nif (new_wr_idx \u0026lt; qsize) {\n memcpy(wr_ptr, packet, dwords \u0026lt;\u0026lt; 2) --\u0026gt; OOB write\n\nAdd check to ensure qsize is within the allocated size while\nreading and writing packets into the queue.(CVE-2025-23158)\n\nIn the Linux kernel, the following vulnerability has been resolved:net: ppp: Add bound checking for skb data on ppp_sync_txmungEnsure we have enough data in linear buffer from skb before accessinginitial bytes. This prevents potential out-of-bounds accesseswhen processing short packets.When ppp_sync_txmung receives an incoming package with an emptypayload:(remote) gef\u27a4 p *(struct pppoe_hdr *) (skb-\u0026gt;head + skb-\u0026gt;network_header)$18 = { type = 0x1, ver = 0x1, code = 0x0, sid = 0x2, length = 0x0, tag = 0xffff8880371cdb96}from the skb struct (trimmed) tail = 0x16, end = 0x140, head = 0xffff88803346f400 4 , data = 0xffff88803346f416 : 377 , truesize = 0x380, len = 0x0, data_len = 0x0, mac_len = 0xe, hdr_len = 0x0,it is not safe to access data[2].[(CVE-2025-37749)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix OOB read when checking dotdot dir\n\nMounting a corrupted filesystem with directory which contains \u0026apos;.\u0026apos; dir\nentry with rec_len == block size results in out-of-bounds read (later\non, when the corrupted directory is removed).\n\next4_empty_dir() assumes every ext4 directory contains at least \u0026apos;.\u0026apos;\nand \u0026apos;..\u0026apos; as directory entries in the first data block. It first loads\nthe \u0026apos;.\u0026apos; dir entry, performs sanity checks by calling ext4_check_dir_entry()\nand then uses its rec_len member to compute the location of \u0026apos;..\u0026apos; dir\nentry (in ext4_next_entry). It assumes the \u0026apos;..\u0026apos; dir entry fits into the\nsame data block.\n\nIf the rec_len of \u0026apos;.\u0026apos; is precisely one block (4KB), it slips through the\nsanity checks (it is considered the last directory entry in the data\nblock) and leaves \u0026quot;struct ext4_dir_entry_2 *de\u0026quot; point exactly past the\nmemory slot allocated to the data block. The following call to\next4_check_dir_entry() on new value of de then dereferences this pointer\nwhich results in out-of-bounds mem access.\n\nFix this by extending __ext4_check_dir_entry() to check for \u0026apos;.\u0026apos; dir\nentries that reach the end of data block. Make sure to ignore the phony\ndir entries for checksum (by checking name_len for non-zero).\n\nNote: This is reported by KASAN as use-after-free in case another\nstructure was recently freed from the slot past the bound, but it is\nreally an OOB read.\n\nThis issue was found by syzkaller tool.\n\nCall Trace:\n[ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710\n[ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375\n[ 38.595158]\n[ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1\n[ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n[ 38.595304] Call Trace:\n[ 38.595308] \u0026lt;TASK\u0026gt;\n[ 38.595311] dump_stack_lvl+0xa7/0xd0\n[ 38.595325] print_address_description.constprop.0+0x2c/0x3f0\n[ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595349] print_report+0xaa/0x250\n[ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595368] ? kasan_addr_to_slab+0x9/0x90\n[ 38.595378] kasan_report+0xab/0xe0\n[ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595400] __ext4_check_dir_entry+0x67e/0x710\n[ 38.595410] ext4_empty_dir+0x465/0x990\n[ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10\n[ 38.595432] ext4_rmdir.part.0+0x29a/0xd10\n[ 38.595441] ? __dquot_initialize+0x2a7/0xbf0\n[ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10\n[ 38.595464] ? __pfx___dquot_initialize+0x10/0x10\n[ 38.595478] ? down_write+0xdb/0x140\n[ 38.595487] ? __pfx_down_write+0x10/0x10\n[ 38.595497] ext4_rmdir+0xee/0x140\n[ 38.595506] vfs_rmdir+0x209/0x670\n[ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190\n[ 38.595529] do_rmdir+0x363/0x3c0\n[ 38.595537] ? __pfx_do_rmdir+0x10/0x10\n[ 38.595544] ? strncpy_from_user+0x1ff/0x2e0\n[ 38.595561] __x64_sys_unlinkat+0xf0/0x130\n[ 38.595570] do_syscall_64+0x5b/0x180\n[ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-37785)\n\nIn the Linux kernel, the following vulnerability has been resolved:net: openvswitch: fix nested key length validation in the set() actionIt s not safe to access nla_len(ovs_key) if the data is smaller thanthe netlink header. Check that the attribute is OK first.(CVE-2025-37789)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid\n\nThere is a string parsing logic error which can lead to an overflow of hid\nor uid buffers. Comparing ACPIID_LEN against a total string length doesn\u0026apos;t\ntake into account the lengths of individual hid and uid buffers so the\ncheck is insufficient in some cases. For example if the length of hid\nstring is 4 and the length of the uid string is 260, the length of str\nwill be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer\nwhich size is 256.\n\nThe same applies to the hid string with length 13 and uid string with\nlength 250.\n\nCheck the length of hid and uid strings separately to prevent\nbuffer overflow.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37927)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAX\n\nOtherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof()\nwhen resizing hashtable because __GFP_NOWARN is unset.\n\nSimilar to:\n\n b541ba7d1f5a (\u0026quot;netfilter: conntrack: clamp maximum hashtable size to INT_MAX\u0026quot;)(CVE-2025-38201)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix WARN() in get_bpf_raw_tp_regs\n\nsyzkaller reported an issue:\n\nWARNING: CPU: 3 PID: 5971 at kernel/trace/bpf_trace.c:1861 get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861\nModules linked in:\nCPU: 3 UID: 0 PID: 5971 Comm: syz-executor205 Not tainted 6.15.0-rc5-syzkaller-00038-g707df3375124 #0 PREEMPT(full)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nRIP: 0010:get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861\nRSP: 0018:ffffc90003636fa8 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: 0000000000000003 RCX: ffffffff81c6bc4c\nRDX: ffff888032efc880 RSI: ffffffff81c6bc83 RDI: 0000000000000005\nRBP: ffff88806a730860 R08: 0000000000000005 R09: 0000000000000003\nR10: 0000000000000004 R11: 0000000000000000 R12: 0000000000000004\nR13: 0000000000000001 R14: ffffc90003637008 R15: 0000000000000900\nFS: 0000000000000000(0000) GS:ffff8880d6cdf000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f7baee09130 CR3: 0000000029f5a000 CR4: 0000000000352ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1934 [inline]\n bpf_get_stack_raw_tp+0x24/0x160 kernel/trace/bpf_trace.c:1931\n bpf_prog_ec3b2eefa702d8d3+0x43/0x47\n bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline]\n __bpf_prog_run include/linux/filter.h:718 [inline]\n bpf_prog_run include/linux/filter.h:725 [inline]\n __bpf_trace_run kernel/trace/bpf_trace.c:2363 [inline]\n bpf_trace_run3+0x23f/0x5a0 kernel/trace/bpf_trace.c:2405\n __bpf_trace_mmap_lock_acquire_returned+0xfc/0x140 include/trace/events/mmap_lock.h:47\n __traceiter_mmap_lock_acquire_returned+0x79/0xc0 include/trace/events/mmap_lock.h:47\n __do_trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline]\n trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline]\n __mmap_lock_do_trace_acquire_returned+0x138/0x1f0 mm/mmap_lock.c:35\n __mmap_lock_trace_acquire_returned include/linux/mmap_lock.h:36 [inline]\n mmap_read_trylock include/linux/mmap_lock.h:204 [inline]\n stack_map_get_build_id_offset+0x535/0x6f0 kernel/bpf/stackmap.c:157\n __bpf_get_stack+0x307/0xa10 kernel/bpf/stackmap.c:483\n ____bpf_get_stack kernel/bpf/stackmap.c:499 [inline]\n bpf_get_stack+0x32/0x40 kernel/bpf/stackmap.c:496\n ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1941 [inline]\n bpf_get_stack_raw_tp+0x124/0x160 kernel/trace/bpf_trace.c:1931\n bpf_prog_ec3b2eefa702d8d3+0x43/0x47\n\nTracepoint like trace_mmap_lock_acquire_returned may cause nested call\nas the corner case show above, which will be resolved with more general\nmethod in the future. As a result, WARN_ON_ONCE will be triggered. As\nAlexei suggested, remove the WARN_ON_ONCE first.(CVE-2025-38285)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: Always pass notifications when child class becomes empty\n\nCertain classful qdiscs may invoke their classes\u0026apos; dequeue handler on an\nenqueue operation. This may unexpectedly empty the child qdisc and thus\nmake an in-flight class passive via qlen_notify(). Most qdiscs do not\nexpect such behaviour at this point in time and may re-activate the\nclass eventually anyways which will lead to a use-after-free.\n\nThe referenced fix commit attempted to fix this behavior for the HFSC\ncase by moving the backlog accounting around, though this turned out to\nbe incomplete since the parent\u0026apos;s parent may run into the issue too.\nThe following reproducer demonstrates this use-after-free:\n\n tc qdisc add dev lo root handle 1: drr\n tc filter add dev lo parent 1: basic classid 1:1\n tc class add dev lo parent 1: classid 1:1 drr\n tc qdisc add dev lo parent 1:1 handle 2: hfsc def 1\n tc class add dev lo parent 2: classid 2:1 hfsc rt m1 8 d 1 m2 0\n tc qdisc add dev lo parent 2:1 handle 3: netem\n tc qdisc add dev lo parent 3:1 handle 4: blackhole\n\n echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888\n tc class delete dev lo classid 1:1\n echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888\n\nSince backlog accounting issues leading to a use-after-frees on stale\nclass pointers is a recurring pattern at this point, this patch takes\na different approach. Instead of trying to fix the accounting, the patch\nensures that qdisc_tree_reduce_backlog always calls qlen_notify when\nthe child qdisc is empty. This solves the problem because deletion of\nqdiscs always involves a call to qdisc_reset() and / or\nqdisc_purge_queue() which ultimately resets its qlen to 0 thus causing\nthe following qdisc_tree_reduce_backlog() to report to the parent. Note\nthat this may call qlen_notify on passive classes multiple times. This\nis not a problem after the recent patch series that made all the\nclassful qdiscs qlen_notify() handlers idempotent.(CVE-2025-38350)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix use-after-free in cifs_oplock_break\n\nA race condition can occur in cifs_oplock_break() leading to a\nuse-after-free of the cinode structure when unmounting:\n\n cifs_oplock_break()\n _cifsFileInfo_put(cfile)\n cifsFileInfo_put_final()\n cifs_sb_deactive()\n [last ref, start releasing sb]\n kill_sb()\n kill_anon_super()\n generic_shutdown_super()\n evict_inodes()\n dispose_list()\n evict()\n destroy_inode()\n call_rcu(\u0026amp;inode-\u0026gt;i_rcu, i_callback)\n spin_lock(\u0026amp;cinode-\u0026gt;open_file_lock) \u0026lt;- OK\n [later] i_callback()\n cifs_free_inode()\n kmem_cache_free(cinode)\n spin_unlock(\u0026amp;cinode-\u0026gt;open_file_lock) \u0026lt;- UAF\n cifs_done_oplock_break(cinode) \u0026lt;- UAF\n\nThe issue occurs when umount has already released its reference to the\nsuperblock. When _cifsFileInfo_put() calls cifs_sb_deactive(), this\nreleases the last reference, triggering the immediate cleanup of all\ninodes under RCU. However, cifs_oplock_break() continues to access the\ncinode after this point, resulting in use-after-free.\n\nFix this by holding an extra reference to the superblock during the\nentire oplock break operation. This ensures that the superblock and\nits inodes remain valid until the oplock break completes.(CVE-2025-38527)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/packet: fix a race in packet_set_ring() and packet_notifier()\n\nWhen packet_set_ring() releases po-\u0026gt;bind_lock, another thread can\nrun packet_notifier() and process an NETDEV_UP event.\n\nThis race and the fix are both similar to that of commit 15fe076edea7\n(\u0026quot;net/packet: fix a race in packet_bind() and packet_notifier()\u0026quot;).\n\nThere too the packet_notifier NETDEV_UP event managed to run while a\npo-\u0026gt;bind_lock critical section had to be temporarily released. And\nthe fix was similarly to temporarily set po-\u0026gt;num to zero to keep\nthe socket unhooked until the lock is retaken.\n\nThe po-\u0026gt;bind_lock in packet_set_ring and packet_notifier precede the\nintroduction of git history.(CVE-2025-38617)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nice: Fix a null pointer dereference in ice_copy_and_init_pkg()\n\nAdd check for the return value of devm_kmemdup()\nto prevent potential null pointer dereference.(CVE-2025-38664)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: core: Check for rtd == NULL in snd_soc_remove_pcm_runtime()\n\nsnd_soc_remove_pcm_runtime() might be called with rtd == NULL which will\nleads to null pointer dereference.\nThis was reproduced with topology loading and marking a link as ignore\ndue to missing hardware component on the system.\nOn module removal the soc_tplg_remove_link() would call\nsnd_soc_remove_pcm_runtime() with rtd == NULL since the link was ignored,\nno runtime was created.(CVE-2025-38706)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: Validate UAC3 power domain descriptors, too\n\nUAC3 power domain descriptors need to be verified with its variable\nbLength for avoiding the unexpected OOB accesses by malicious\nfirmware, too.(CVE-2025-38729)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix NPD when refreshing an FDB entry with a nexthop object\n\nVXLAN FDB entries can point to either a remote destination or an FDB\nnexthop group. The latter is usually used in EVPN deployments where\nlearning is disabled.\n\nHowever, when learning is enabled, an incoming packet might try to\nrefresh an FDB entry that points to an FDB nexthop group and therefore\ndoes not have a remote. Such packets should be dropped, but they are\nonly dropped after dereferencing the non-existent remote, resulting in a\nNPD [1] which can be reproduced using [2].\n\nFix by dropping such packets earlier. Remove the misleading comment from\nfirst_remote_rcu().\n\n[1]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n[...]\nCPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014\nRIP: 0010:vxlan_snoop+0x98/0x1e0\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n vxlan_encap_bypass+0x209/0x240\n encap_bypass_if_local+0xb1/0x100\n vxlan_xmit_one+0x1375/0x17e0\n vxlan_xmit+0x6b4/0x15f0\n dev_hard_start_xmit+0x5d/0x1c0\n __dev_queue_xmit+0x246/0xfd0\n packet_sendmsg+0x113a/0x1850\n __sock_sendmsg+0x38/0x70\n __sys_sendto+0x126/0x180\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n[2]\n #!/bin/bash\n\n ip address add 192.0.2.1/32 dev lo\n ip address add 192.0.2.2/32 dev lo\n\n ip nexthop add id 1 via 192.0.2.3 fdb\n ip nexthop add id 10 group 1 fdb\n\n ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass\n ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning\n\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020\n bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10\n\n mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q(CVE-2025-39851)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: arm64: Prevent access to vCPU events before init\n\nAnother day, another syzkaller bug. KVM erroneously allows userspace to\npend vCPU events for a vCPU that hasn\u0026apos;t been initialized yet, leading to\nKVM interpreting a bunch of uninitialized garbage for routing /\ninjecting the exception.\n\nIn one case the injection code and the hyp disagree on whether the vCPU\nhas a 32bit EL1 and put the vCPU into an illegal mode for AArch64,\ntripping the BUG() in exception_target_el() during the next injection:\n\n kernel BUG at arch/arm64/kvm/inject_fault.c:40!\n Internal error: Oops - BUG: 00000000f2000800 [#1] SMP\n CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT\n Hardware name: linux,dummy-virt (DT)\n pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n pc : exception_target_el+0x88/0x8c\n lr : pend_serror_exception+0x18/0x13c\n sp : ffff800082f03a10\n x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000\n x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000\n x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004\n x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000\n x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0\n x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000\n x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000\n x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000\n x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000\n x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20\n Call trace:\n exception_target_el+0x88/0x8c (P)\n kvm_inject_serror_esr+0x40/0x3b4\n __kvm_arm_vcpu_set_events+0xf0/0x100\n kvm_arch_vcpu_ioctl+0x180/0x9d4\n kvm_vcpu_ioctl+0x60c/0x9f4\n __arm64_sys_ioctl+0xac/0x104\n invoke_syscall+0x48/0x110\n el0_svc_common.constprop.0+0x40/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x34/0xf0\n el0t_64_sync_handler+0xa0/0xe4\n el0t_64_sync+0x198/0x19c\n Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000)\n\nReject the ioctls outright as no sane VMM would call these before\nKVM_ARM_VCPU_INIT anyway. Even if it did the exception would\u0026apos;ve been\nthrown away by the eventual reset of the vCPU\u0026apos;s state.(CVE-2025-40102)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmc: Use __sk_dst_get() and dst_dev_rcu() in in smc_clc_prfx_set().\n\nsmc_clc_prfx_set() is called during connect() and not under RCU\nnor RTNL.\n\nUsing sk_dst_get(sk)-\u0026gt;dev could trigger UAF.\n\nLet\u0026apos;s use __sk_dst_get() and dev_dst_rcu() under rcu_read_lock()\nafter kernel_getsockname().\n\nNote that the returned value of smc_clc_prfx_set() is not used\nin the caller.\n\nWhile at it, we change the 1st arg of smc_clc_prfx_set[46]_rcu()\nnot to touch dst there.(CVE-2025-40139)",
"id": "OESA-2025-2801",
"modified": "2026-08-06T11:09:55Z",
"published": "2025-12-12T11:09:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2801"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53091"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53282"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53491"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53520"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53673"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57907"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57911"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58034"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21905"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22020"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22022"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22039"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22083"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23150"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23158"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37749"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37785"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37789"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37927"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38201"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38285"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38350"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38527"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38617"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38664"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38706"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38729"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39851"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40102"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40139"
}
],
"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-2023-53091",
"CVE-2023-53282",
"CVE-2023-53491",
"CVE-2023-53520",
"CVE-2023-53673",
"CVE-2024-57907",
"CVE-2024-57911",
"CVE-2024-58034",
"CVE-2025-21905",
"CVE-2025-22020",
"CVE-2025-22022",
"CVE-2025-22039",
"CVE-2025-22083",
"CVE-2025-23150",
"CVE-2025-23158",
"CVE-2025-37749",
"CVE-2025-37785",
"CVE-2025-37789",
"CVE-2025-37927",
"CVE-2025-38201",
"CVE-2025-38285",
"CVE-2025-38350",
"CVE-2025-38527",
"CVE-2025-38617",
"CVE-2025-38664",
"CVE-2025-38706",
"CVE-2025-38729",
"CVE-2025-39851",
"CVE-2025-40102",
"CVE-2025-40139"
]
}
RHSA-2026:1194
Vulnerability from csaf_redhat - Published: 2026-01-26 14:32 - Updated: 2026-08-04 14:07A flaw was found in the Linux kernel's openvswitch virtual environment. A local attacker with low privileges could exploit improper data and key length validation in the `set()` action. This could lead to a denial of service, making the system unresponsive, and potentially result in limited information disclosure.
RHSA-2026:1236
Vulnerability from csaf_redhat - Published: 2026-01-26 16:39 - Updated: 2026-08-04 14:07A flaw was found in the Linux kernel's openvswitch virtual environment. A local attacker with low privileges could exploit improper data and key length validation in the `set()` action. This could lead to a denial of service, making the system unresponsive, and potentially result in limited information disclosure.
RHSA-2026:1441
Vulnerability from csaf_redhat - Published: 2026-01-28 00:38 - Updated: 2026-08-21 20:08A flaw was found in the Linux kernel's openvswitch virtual environment. A local attacker with low privileges could exploit improper data and key length validation in the `set()` action. This could lead to a denial of service, making the system unresponsive, and potentially result in limited information disclosure.
RHSA-2026:1443
Vulnerability from csaf_redhat - Published: 2026-01-28 00:26 - Updated: 2026-08-21 20:08A flaw was found in the Linux kernel's openvswitch virtual environment. A local attacker with low privileges could exploit improper data and key length validation in the `set()` action. This could lead to a denial of service, making the system unresponsive, and potentially result in limited information disclosure.
RHSA-2026:1444
Vulnerability from csaf_redhat - Published: 2026-01-28 00:57 - Updated: 2026-08-04 19:23A flaw was found in the Linux kernel's openvswitch virtual environment. A local attacker with low privileges could exploit improper data and key length validation in the `set()` action. This could lead to a denial of service, making the system unresponsive, and potentially result in limited information disclosure.
RHSA-2026:1494
Vulnerability from csaf_redhat - Published: 2026-01-28 15:14 - Updated: 2026-08-21 20:08A flaw was found in the Linux kernel's openvswitch virtual environment. A local attacker with low privileges could exploit improper data and key length validation in the `set()` action. This could lead to a denial of service, making the system unresponsive, and potentially result in limited information disclosure.
RHSA-2026:1495
Vulnerability from csaf_redhat - Published: 2026-01-28 15:08 - Updated: 2026-08-21 20:08A flaw was found in the Linux kernel's openvswitch virtual environment. A local attacker with low privileges could exploit improper data and key length validation in the `set()` action. This could lead to a denial of service, making the system unresponsive, and potentially result in limited information disclosure.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
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.